Date: Wed, 30 Apr 1997 11:52:59 -0700 From: Julian Elischer <julian@whistle.com> To: Bruce Evans <bde@zeta.org.au> Cc: avalon@coombs.anu.edu.au, msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: Unloading LKMs (was Re: A Desparate Plea for Help...) Message-ID: <3367950B.15FB7483@whistle.com> References: <199704301402.AAA27241@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > > >2.2 builds the devsw tables at link time using linker sets, and as > >such the devsw arrays are now arrays of pointers to devsw structures. > >This is a huge plus, in that one no longer has to mung the stuff in > >conf.c in order to add a new driver. > > Actually, it builds tables of functions at link time using linker > sets. The functions are then used early at runtime to build the > devsw tables. This implementation was expedient 17 months ago and > bad 16 months ago. wellll, the eventual aim is to have an init function that is called the same regardless of whether the driver is preloaded or loaded at run-time. I think we should consider pre-loaded modules as modules that are identical to LKM modules, but that the loading is automatic and already done at boot time and that all that remains to be done is the execution of the init function. (for which SYSINIT works admirably) it is possible that a separate linker set might have some advantages, but SYSINIT exists and works well. > > >Bruce's argument is that drivers should do their own management of > >devsw entries. I'm inclined to disagree, especially as there is no > >API for doing this; you are expected to grovel directly. > > The drivers either have to build tables of pointers to devsw's > for some higher layer to use, or register the pointers directly. > Doing it directly > is more flexible although it takes a few bytes more space at runtime. > There are (BAD) interface functions bdevsw_add(), cdevsw_add() and > bdevsw_add_generic(). > The (BAD as you call them) interfaces are pre-existing from 2.1 (as Darren noted) and were modified to be as compatible as before with the pre-existing LKM scheme with which they were original bundled. I didn't want to change the LKM system so I didn't change the way they worked, but if someone were to change the LKM scheme then they could be changed to suit. (though the drivers would all have to be changed as well) > Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3367950B.15FB7483>