Date: Wed, 15 Jan 1997 10:06:16 -0600 (CST) From: jpt@msc.edu (Joseph Thomas) To: se@freebsd.org (Stefan Esser) Cc: jin@george.lbl.gov, erich@lodgenet.com, hackers@freebsd.org Subject: Re: Q for loadable network driver Message-ID: <199701151606.KAA04405@ww.msc.edu> In-Reply-To: <Mutt.19961218152248.se@x14.mi.uni-koeln.de> from "Stefan Esser" at Dec 18, 96 03:22:48 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > On Dec 16, jin@george.lbl.gov (Jin Guojun[ITG]) wrote: > > Another question is that is necessary to link the newly loaded driver to > > the kernel control block -- > > /sys/pci.c:155:static struct pcicb *pcicb; > > ------------------------------------------------------------- > > pci/pci.c: unmodified: line 704 -- > > /* > > ** allocate bus descriptor for bus behind the bridge > > */ > > link = &pcicb->pcicb_down; > > while (*link && (*link)->pcicb_bus < secondary) > > link = &(*link)->pcicb_next; > > > > this = malloc (sizeof (*this), M_DEVBUF, M_WAITOK); > > > > ... ... > > > > /* > > ** Link it in chain. > > */ > > *link=this; > > pci/pci.c: unmodified: line 819 -- > > ----------------------------------------------------------------- > > Without an interface to get the PCI control block address -- &pcicb -- it is > > hardly to link the new information into the kernel PCI chain. > > Also, is the segment above (pci/pci.c line 704 - 819) necessary for loading > > a loadable device driver? > > I've been thinking about PCI LKMs, and my proposed > solution would work this way: > > - Have a user land command retrieve information about > PCI devices that got no driver assigned (easy, use > ioctl() on /dev/pci after I apply a simple patch :) > > - This user land program will then scan for a file > with the correct driver. This will most probably be > done by having a PCI LKM config file under /etc, > which contains the LKM name that corresponds to > some PCI vendor+device ID (or the subvendorid). > Something along the lines of: > > 0x00011000 pci_ncr.o > 0x000f1000 pci_ncr.o > 0x802910ec pci_ed.o > > Then a modload is performed, which will add the > driver to the list of known PCI drivers. > > I think the device driver should just be loaded, > and a PCI bus rescan be initiated, which will find > the new driver, and will attach all devices it is > able to support. (This is already prepared for in > the current PCI code.) > > So, all you need (IMHO) is: > > - The patch to pci_ioctl(), which puts the information > whether there was a driver for some device into the > pciconf struct. > > - A function to call from the LKM to register the new > driver. The PCI code will test drivers on a linked > list (and prefer them to compiled in code) for this > to become effective. > > - A function that initiates a PCI bus rescan. Possibly > combined with the previous one, but I would in fact > prefer to have a separate load, unload and rescan > function ... > (Or would having rescan implied by load, and stopping > the driver before unload be better ??? Possible ...) > > What do you think about these changes ? > > The result will be, that your PCI LKM is called with the > corresponding PCI tag. The driver must receive the &pcibus > to be able to call back into the PCI code, and this may > either be by making pcibus a global variable again, or by > making it an additional parameter of the attach function. > > Would this help ? > > Regards, STefan > Humm, (Not real articulate - I haven't thought out how this could all be coded, but...) We have a suite of loadable drivers which support an ATM research platform. They're available for limited release supporting SunOS 4.1.x and the FORE SBA200/SBA200E adapters. Our current task has been porting this suite to FreeBSD using the FORE PCA200E PCI card and thus we're "experienced" the lack of support for PCI LKMs. Not that I'm offering to implement this (yet), but why not think along the lines of SunOS and the SBus? SunOS uses an indetify() routine in the driver which receives an ascii device identifier (from the SBus device PROM) and the driver says "yes - I want it" or "No - it's somebody elses device". If say an identify() entry point were non-NULL, FreeBSD could call the entry for either: every device in the PCI table (claimed and unclaimed) or just those devices not assigned. This leaves the configuration upto the device driver and doesn't require a user to run around pointing to where drivers might be and what tag's/ID's they're assigned to. My gut instinct is to cringe really bad when someone suggests user level configuration of what ought only be kernel level info (ie. the PCI bus). Comments? -- Joseph Thomas E/Mail: jpt@msc.edu Minnesota Supercomputer Center, Inc. jpt@magic.net 1200 Washington Ave So. Tel: +1 612 337 3558 Minneapolis, MN 55415-1227 FAX: +1 612 337 3400 You cannot see what I see because you see what you see. You cannot know what I know because you know what you know. "Mostly Harmless" - Douglas Adams
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701151606.KAA04405>