From owner-freebsd-hackers Sun Oct 15 09:41:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA01371 for hackers-outgoing; Sun, 15 Oct 1995 09:41:16 -0700 Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA01365 for ; Sun, 15 Oct 1995 09:41:13 -0700 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA12916; Sun, 15 Oct 1995 09:39:26 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA08366; Sun, 15 Oct 1995 12:39:24 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id MAA02291; Sun, 15 Oct 1995 12:48:48 GMT Message-Id: <199510151248.MAA02291@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: se@zpr.uni-koeln.de (Stefan Esser) Cc: hackers@freebsd.org Subject: Re: IPX now available In-Reply-To: Your message of "Sat, 14 Oct 1995 01:20:37 +0100." <199510140020.AA18009@Sysiphos> X-Mailer: exmh version 1.5omega 10/6/94 Date: Sun, 15 Oct 1995 12:48:47 +0000 From: Matt Thomas Sender: owner-hackers@freebsd.org Precedence: bulk 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: Westford, MA Disclaimer: Digital disavows all knowledge of this message