Date: Thu, 31 Aug 1995 17:49:29 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, wollman@lcs.mit.edu, freebsd-current@FreeBSD.org, jhay@mikom.csir.co.za Subject: Re: pseudo device lkm's broken Message-ID: <199509010049.RAA23766@phaeton.artisoft.com> In-Reply-To: <199508312149.HAA10464@godzilla.zeta.org.au> from "Bruce Evans" at Sep 1, 95 07:49:33 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> This can probably be fixed by adding a dummy ((caddr_t)NULL) arg to > >> init() in the lkm PSEUDO_SET(). The correct fix is probably to > >> get rid of the deprecated kernel PSEUDO_SET() and remove all the > >> dummy args. Even for boot-time sysinits, the args are almost > >> always dummies. > > >Deprecated by whom? Certainly not me... > > By Terry. <sys/kernel.h> now says "To be deprecated after LKM is > updated". > > I committed the fix. Let me explain this before this pisses people off. There are a *lot* of reasons for moving the whole kernel toward a linker_set based model, and this will necessitate rolling in a lot of what is currently handled by way of linker_sets into a unifiable data description of the kernel onjects present in a kernel instance. I expanded Garrett's initial work with linker_set structures to encompass all of system initialization rather than just some aspects of it. The proper way to deal with this in LKM will be to take the object for the LKM and generate a post-processed linker_set reference so that it doesn't vary the object module between loadable and statically linkable forms. This assumes agregations of a set into a single set by ld -r and a change to the load image format for LKM's. What this boils down to is a "foo.o" that can be loaded as a module or thrown into the list of binary modules to be linked into the kernel. To implement this requires either a mod to ld, or, more preferrably, a post-processing mechanism for the module object; you'd typically want to deal with a module in the kernel in terms of export and import lists in any case, so that you can build a dependency graph that doesn't depend on link order, at the same time hiding the module symbols that should not be depended upon by a clean use of the module's exported interface. The net effect is almost 0 on devices that use the devfs export interface to register themselves as drivers and for file systems that use the vfs_init mechanism to register themselves. In point of fact, all static device and file system initialization should "go away", to be replaced by self-registration vi SYSINIT(). It's really irrelevant for a lodable module as to whether the SYSINIT() exported entry point is called by a loop in init_main.c or as a side effect of the LKM load, so long as it is called. One end goal is the elimination of all option #ifdef's in the kernel (at least the ones not associated with debugging). An option entry in the config file will come to mean "generate the objects necessary to make an obect of this name if it does not already exist, then generate the object using ld -r, then include that object in the list of objects you put together to get a kernel". Yes, this is a pardigm shift. It means that drivers and file systems and anything else that is expected to be loadable or linkable as an option to the kernel build must have a single entry/multiple consumer interface with callback registration. Anything that places itself in a list of like objects is effectively using callback registration right now, though optioned devices currently do this "registration" statically using #ifdef's all over the code. For most things, this means little change over the current source tree as it stands. 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?199509010049.RAA23766>