Date: Sun, 15 Oct 1995 12:48:47 +0000 From: Matt Thomas <matt@lkg.dec.com> To: se@zpr.uni-koeln.de (Stefan Esser) Cc: hackers@freebsd.org Subject: Re: IPX now available Message-ID: <199510151248.MAA02291@whydos.lkg.dec.com> In-Reply-To: Your message of "Sat, 14 Oct 1995 01:20:37 %2B0100." <199510140020.AA18009@Sysiphos>
next in thread | previous in thread | raw e-mail | index | archive | help
In <199510140020.AA18009@Sysiphos> , you wrote:
> On Oct 13, 18:16, Matt Thomas wrote:
> } Subject: Re: IPX now available
>
> } For PCI, I'm beginning in favor of having the driver call a pci_match
> } routine to find instances of itself instead of the currently "passive"
> } method. The passive method just doesn't lend itself to LKM. One other
>
> Hmm, I don't quite understand the advantage of the driver doing a "match"
> in the context of LKMs ...
It's more of a reversal of functions. In a static kernel where everything
is known up-front, call the PCI configuration call the devices makes
significant sense. However, when the world is dynamic the autoconfig
code now becomes passive and the LKMs are the active components.
Indeed, one very real way to look at this would be to use the DATA_SET
capabilities that currently exist to store a vector of configuration/
initialization entries. So when the kernel is linked, all the
initializers for devices, file systems, protocols, etc. are present in
this data set. The system will define a set of synchronization points and
ordering points within each sync point. So when the kernel initializes, it
sorts these configuration entries and calls them one by one in order.
This results in a number of benifits. The first is that the exact same
modules can be used for both static-linked kernel and dynamically loaded
kernel. Another benifit is that you can develop and debug almost all
the mechanisms needed for a truly dynamic kernel using the existing static
kernel framework.
[For the kernel described above, it might be useful if ld supported a new
MAGIC type image. Such that whenever a new module is loaded, its code
and data and bss are contiguous and never overlap with another module.
This would allow the memory used by a module to be recovered if it
determined that it is not needed.]
--
In this instance, let's say the PCI support LKM get loaded, it walks the
PCI bus/device tree and sets up it's data structures. Then it returns
back to the kernel initializer.
Now comes a PCI device, it calls pci_match to find the first unassigned
device that matches its earch criterea.
device_cookie = NULL;
while (device_cookie = pci_devmatch(device_cookie,
my_match_function)) != NULL)
pci_devattach(device_cookie, my_attach_function);
Indeed, there could be a convenience routine that does the above.
pci_devconfigure(my_match_function, my_attach_function);
It's implicit is that all drivers be all to configure any number of devices.
> PCI device LKMs ought to be named according to their vendor and device IDs.
> E.g. the NCR driver might be looked up under "/lkm/pci_v1000d0001.o" which
> is a link to /lkm/ncr_scsi.o" or the DEC 21040 under "/lkm/pci_v1011d0002.o"
> which might be a link to "/lkm/if_de.o" ...
I strongly disagree. In my view, a LKM controls its own fate. The kernel
(or other LKMs on which this LKM depends) merely provided services which it
can use. Indeed, as far as the system is concerned there should be no
difference between a FS LKM or a device LKM or protocol LKM or a syscall LKM.
Once the LKM's configuration entry point has been called, the LKM is in
control.
> } reason I favor it is so that I could have a "generic" DC21x4X module
> } and then have various board/chip specific LKMs. The de driver is getting
> } fairly large and I'd like a method to trim out the unneeded code.
>
> PCI 2.1 extends the vendor and device ID concept. It is now possible to
> have a board vendor/device ID independent from the chip's ID.
True, the subsystem ID will be useful but that doesn't help with all the
current devices which don't have that.
> This opens a generic way to load a board specific driver, instead of only
> a chip specific one ...
For those boards that will support it...
Matt Thomas Internet: matt@lkg.dec.com
3am Software Foundry WWW URL: <currently homeless>
Westford, MA Disclaimer: Digital disavows all knowledge
of this message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510151248.MAA02291>