From owner-freebsd-current Sun Mar 30 11:57:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA09115 for current-outgoing; Sun, 30 Mar 1997 11:57:13 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA09110 for ; Sun, 30 Mar 1997 11:57:10 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id LAA05078; Sun, 30 Mar 1997 11:57:06 -0800 (PST) Message-Id: <199703301957.LAA05078@austin.polstra.com> To: dfr@nlsystems.com Subject: Re: A new Kernel Module System Newsgroups: polstra.freebsd.current In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Date: Sun, 30 Mar 1997 11:57:05 -0800 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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