Date: Mon, 6 Jan 1997 15:23:19 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: julian@whistle.com (Julian Elischer) Cc: erich@lodgenet.com, hackers@freebsd.org Subject: Re: device driver initialization Message-ID: <199701062223.PAA12770@phaeton.artisoft.com> In-Reply-To: <32CD529D.167EB0E7@whistle.com> from "Julian Elischer" at Jan 3, 97 10:40:29 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > It looks like most of the ISA drivers now days have a frag like: > > > > SYSINIT(foo,SI_SUB_DRIVERS,SI_ORDER_MIDDLE+CDEV_MAJOR,foo_drvinit,NULL) [ ... ] > > Is there any reason that this can't be absorbed in the attach function, > > somewhere around where the devfs stuff is done? What's the reason for > > adding yet another entry point during re-boot. Isn't probe/attach enough? > > The addition of a devsw entry is done ONCE PER DRIVER > > the probe/attach is done ONCE PER INSTANCE > > so the usages are slightly different. > > other than that, yes it could be done.... > remember also that the eventual aim is to make drivers LKMable > in which case the SYSINIT part would be done by the LKM installation. > > It was easier to add this to every driver in a 'boilerplate' manner > (in fact I used a combination of scripts and manual editing > to add it), than to add more specialist code to each attach routine.. In addition, it is likely that a future version of the symbol agregation code for LKM's will seperate preagregated data from post-agregated data in the kernel following the link. To put this in English: o You have an object module for a driver o You link it statically, it's a static driver o You load it as an LKM, it's an LKM driver o The object code is identical in both cases This would let third parties distribute boot-critical drivers for various controllers. For instance, some poor schuck could sign NDA with Adaptec and supply a binary-only 3940 RAID-II driver so that the rest of us didn't have to sign NDA or have source to link his code in. If the 3940 was our boot device, we could build a kernel with it preloaded (assuming we don't load all our disk drivers as LKM's using VM86-based INT 13 drivers for boot by that time anyway). Same issues apply to ethernet drivers, and so on, which might want to be statically linked into the default kernel, but dynamically loaded by netboot (for example). In effect, we want to destroy the distinction between LKM's and regular drivers. For weenies who need that "extra burst of speed" that you supposedly get with non-PIC'ed objects, they can recompile from sources. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701062223.PAA12770>