From owner-freebsd-current Tue Apr 1 00:31:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA18913 for current-outgoing; Tue, 1 Apr 1997 00:31:59 -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 AAA18905 for ; Tue, 1 Apr 1997 00:31:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nlsystems.com (8.8.5/8.8.5) with SMTP id JAA00327; Tue, 1 Apr 1997 09:31:02 +0100 (BST) Date: Tue, 1 Apr 1997 09:31:02 +0100 (BST) From: Doug Rabson To: John Polstra cc: phk@critter.dk.tfs.com, current@FreeBSD.ORG Subject: Re: A new Kernel Module System In-Reply-To: <199704010326.TAA24955@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 Mon, 31 Mar 1997, John Polstra wrote: > On a different but related subject ... Maybe nobody's confused about > this, but just in case: The kernel modules (new LKMs) do not have > to be PIC. They can just as well be plain object files, and they > probably should be. PIC is only needed when the same object is > going to be mapped simultaneously into several different processes > at potentially different addresses. PIC doesn't eliminate the need > for relocation; it just isolates all the position-dependent > information in the data segment. Since each kernel module will be > mapped at most once into the kernel, there's no need to make it PIC. > It should probably not be PIC, because of the substantial > performance penalty that PIC adds. Exactly what I was thinking. PIC has no benefits for the kernel. The only thing I would need from the a.out shlib format is the relocations and runtime symbol table. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891