Date: Fri, 3 May 1996 13:54:29 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: wollman@lcs.mit.edu (Garrett Wollman) Cc: bde@zeta.org.au, freebsd-current@FreeBSD.org Subject: Re: LKMs Message-ID: <199605032054.NAA14784@phaeton.artisoft.com> In-Reply-To: <9605031436.AA11159@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at May 3, 96 10:36:43 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > This leads to my next topic :-). There shouldn't be any such files because > > they don't work as lkm's. For lkm's there should be a single entry point > > that registers all the necessary objects and functions: > > Which is easy enough to accomplish since you know what sorts of sets > are constructed in the kernel and by what kinds of modules. You then > link a module-class-specific initialization routine which knows how to > initialize the appropriate sets. This is precisely what is does now > with VFS LKMs, only it is done with preprocessor magic. Now that we > have symbol-hiding, there is no reason why this could not be done > without the preprocessor magic, which would bring us closer to Terry's > sort of scenario where we can take an opaque object module and either > link it into the kernel, or link with a little glue module to form an > LKM. Actually, I want to hide the glue in the loader, on the theory that it will be the same for all the modules, if done correctly. This means an initialization/deinitialization/status reference in the single entry point, and calling the entry point on module load per the init_main.c calling of the entry point on link. This should mean that a naked .o file should work for eiter static or dynamic linking. Now if we get segment identifiers in kernel space... we can throw away statically linked modules after we decide they're not applicable to the current hardware (ie: math emulator, controller driver for controllers not in the current hardware setup, or fallback drivers to provide base level functionality, once they've been replaced). 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?199605032054.NAA14784>