From owner-freebsd-current Tue Apr 1 10:58:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA20431 for current-outgoing; Tue, 1 Apr 1997 10:58:28 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA20426 for ; Tue, 1 Apr 1997 10:58:25 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11746; Tue, 1 Apr 1997 11:41:56 -0700 From: Terry Lambert Message-Id: <199704011841.LAA11746@phaeton.artisoft.com> Subject: Re: A new Kernel Module System To: jdp@polstra.com (John Polstra) Date: Tue, 1 Apr 1997 11:41:56 -0700 (MST) Cc: dfr@nlsystems.com, phk@critter.dk.tfs.com, current@FreeBSD.ORG In-Reply-To: <199704011627.IAA01496@austin.polstra.com> from "John Polstra" at Apr 1, 97 08:27:02 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 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. > > I don't think you can get a runtime symbol table, unless you're building > a shared object, i.e., using PIC. You'll have to use the "normal" > symbol table. That shouldn't be a problem as far as I can see. The real need is for a vtable-based list of entry points which can be resolved against a list of symbols, and which has a known offset and sorted contents so that it's robust against interface changes. Then when it's mapped, the call is always relative to the mapping address, and no symbol resolution is needed. This presumes that the interface is pure virtual ...ie: the data is local to the library, and the program data is not directly referenced by the library (used to be a problem with termcap). The library vtables need specific entry points for "process attach", "process detach", "thread attach", and "thread detach" that are globally invariant, to allow for construction in the processes data address space instead of the libraries, and to allow for per process or per thread static data replication (probably copy on write, otherwise). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.