Date: Tue, 1 Apr 1997 11:41:56 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jdp@polstra.com (John Polstra) Cc: dfr@nlsystems.com, phk@critter.dk.tfs.com, current@FreeBSD.ORG Subject: Re: A new Kernel Module System Message-ID: <199704011841.LAA11746@phaeton.artisoft.com> In-Reply-To: <199704011627.IAA01496@austin.polstra.com> from "John Polstra" at Apr 1, 97 08:27:02 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704011841.LAA11746>