From owner-freebsd-current Mon Mar 31 01:28:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA00648 for current-outgoing; Mon, 31 Mar 1997 01:28:31 -0800 (PST) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA00634 for ; Mon, 31 Mar 1997 01:28:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nlsystems.com (8.8.5/8.8.5) with SMTP id KAA27641; Mon, 31 Mar 1997 10:28:22 +0100 (BST) Date: Mon, 31 Mar 1997 10:28:22 +0100 (BST) From: Doug Rabson To: John Polstra cc: current@freebsd.org Subject: Re: A new Kernel Module System In-Reply-To: <199703301957.LAA05078@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 30 Mar 1997, John Polstra wrote: > 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 will make sure that any object file dependancies are carefully segregated in the kernel linker. It should be possible to support both a.out and elf in the same linker. Probably a.out first.. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891