necessary information to create the pseudo-device instance. Pseudo-device
device's will reference this cfdata, just as normal devices reference
their corresponding cfdata.
Welcome to 2.99.10.
loadable drivers and user controlled attach/detach of devices.
An outline was given in
http://mail-index.NetBSD.org/tech-kern/2004/08/11/0000.html
To cite the relevant parts:
-Add a "child detached" and a "rescan" method (both optional)
to the device driver. (This is added to the "cfattach" for now
because this is under the driver writer's control. Logically
it belongs more to the "cfdriver", but this is automatically
generated now.)
The "child detached" is called by the autoconf framework
during config_detach(), after the child's ca_detach()
function was called but before the device data structure
is freed.
The "rescan" is called explicitely, either after a driver LKM
was loaded, or on user request (see the "control device" below).
-Add a field to the device instance where the "locators" (in
terms of the autoconf framework), which describe the actual
location of the device relatively to the parent bus, can be
stored. This can be used by the "child detached" function
for easier bookkeeping (no need to lookup by device instance
pointer). (An idea for the future is to use this for generation
of optimized kernel config files - like DEC's "doconfig".)
-Pass the locators tuple describing a device's location to
various autoconf functions to support the previous. And since
locators do only make sense in relation to an "interface
attribute", pass this as well.
-Add helper functions to add/remove supplemental "cfdata"
arrays. Needed for driver LKMs.
There is some code duplication which will hopefully resolved
when all "submatch"-style functions are changed to accept the
locator argument.
Some more cleanup can take place when config(8) issues more
information about locators, in particular the length and default
values. To be done later.
used in an ad hoc way by a couple of eval board ports, so might as well
tidy it up a little and add some formality. (And, yes, I need to use it
in another eval board port.)
message machinery.
Quiet boots look like this (inspired by BSD/OS):
.
.
Found tlp0 at pci0
.
.
Found wd0 at wdc0
.
.
Silent boots look like this:
.
.
Detecting hardware...<twiddle>done.
.
.
NOTE: This requires cooperation on the part of all device drivers,
changes to which have not yet been checked in.
now carries the name of the attachment (e.g. "tlp_pci" or "audio"),
and cfattach structures are registered at boot time on a per-driver
basis. The cfdriver and cfattach pointers are cached in the device
structure when attached.
devices have been discovered. All finalizer routines are iteratively
invoked until all of them report that they have done no work.
Use this hook to fix a latent bug in RAIDframe autoconfiguration of
RAID sets exposed by the rework of SCSI device discovery.
a vector of indices into the cfdata table to specify potential parents,
record the interface attributes that devices have and add a new "parent
spec" structure which lists the iattr, as well as optionally listing
specific parent device instances.
See:
http://mail-index.netbsd.org/tech-kern/2002/09/25/0014.html
...for a detailed description.
While here, const poison some things, as suggested by Matt Thomas.
developed by Christopher G. Demetriou for the NetBSD Project.") with
a generic NetBSD one ("This product includes software developed for the
NetBSD Project. See http://www.netbsd.org/ for information about NetBSD.")
so that this same set of terms can be used by others if they so desire.
(Eventually i'll be converting more/all of my code.)
until all device driver discovery threads have had a chance to do their
work. This in turn blocks initproc's exec of init(8) until root is
mounted and process start times and CWD info has been fixed up.
Addresses kern/9247.
if you com* at pcmcia?, and com3 and com4 as pcmcia cards, and removed
and reinserted the card that was com3, it would become com5. if you then
removed and reinserted com4, it would become com6. etc.) Now, instead
of incrementing FSTATE_STAR configuration entries for a driver when
a cloning instance is attached, leave it alone, and scan the device softc
array (starting at the first cloning unit number) for units which are
available for use. This wastes a tiny bit of time (can require a linear
scan of the softc table for the device), but device attachment should be
relatively infrequent and the number of units of each type of device
is never particularly large anyway.
- Call configure() after setting up proc0.
- Call initclocks() from configure(), after cpu_configure(). Once the
clocks are running, clear `cold'. Then run interrupt-driven
autoconfiguration.
thorpej