Date: Sun, 30 Mar 1997 11:57:05 -0800 From: John Polstra <jdp@polstra.com> To: dfr@nlsystems.com Cc: current@freebsd.org Subject: Re: A new Kernel Module System Message-ID: <199703301957.LAA05078@austin.polstra.com> In-Reply-To: <Pine.BSF.3.95q.970330101633.1828A-100000@kipper.nlsystems.com> References: <Pine.BSF.3.95q.970330101633.1828A-100000@kipper.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The new module system you described sounds good. I'd just like to mention a small aspect of it that matters to me. Any dynamic linking and/or run-time symbol resolution should be structured in a way that will make it as neutral as possible to the object file format. In other words, please don't introduce any new obstacles to moving away from a.out toward ELF or something else. Surprisingly, the current LKM implementation is pretty good in that regard. That's a result of its using the system loader "ld" to do much of the hard work, thereby keeping many of the object file details out of the kernel. I don't recommend that approach for your new system -- it's really kind of a kludge to run "ld" from modload, IMHO. But it would be good to isolate the file format dependencies at a fairly low level. (I stop just short of asking for a loadable module-loader super-module ... :-) One specific request: Any run-time references to symbols should be expressed *as they would appear in a C program*, to wit: Reference a C function "foo" as "foo", not as the a.out-specific "_foo". Any adding of underscores or other transformations should be isolated in the lowest, object format specific layers. I'd be more than happy to help with this aspect of the new module system, though I suspect you already have a firm grip on the issues. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703301957.LAA05078>