From owner-freebsd-current Mon Mar 31 13:15:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA10980 for current-outgoing; Mon, 31 Mar 1997 13:15:45 -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 NAA10973 for ; Mon, 31 Mar 1997 13:15:37 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA10110; Mon, 31 Mar 1997 13:59:25 -0700 From: Terry Lambert Message-Id: <199703312059.NAA10110@phaeton.artisoft.com> Subject: Re: A new Kernel Module System To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Date: Mon, 31 Mar 1997 13:59:25 -0700 (MST) Cc: wollman@khavrinen.lcs.mit.edu, terry@lambert.org, freebsd-current@FreeBSD.ORG In-Reply-To: <27686.859838573@critter> from "Poul-Henning Kamp" at Mar 31, 97 10:02:53 pm 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 > Question: If we stick the linker in the kernel, doesn't it mean that > we could use it for shlibs too ? Probably. I've felt for a long time now that the intent of the memory hole at the start of the executable in the ELF SVR4 EABI was to allow the mapping of the ld.so into the process address space without there being code in crt0.o to actually do the work. > Basically the dl* functions could be made syscalls couldn't they ? Or section (3) wrappers for mmap. I don't know how you would deal with the issue of dlsym(), but you'd want to do it in such a way that it didn't matter if the vtable reference was ELF, COFF, a.out, or whatever. That may imply a system call for kernel decoding the format specific symbol information. The big hairy question mark there is how to handle library static data and per thread replication, etc.. I'd like to see it instanced per link instead of crammed into the image as static data. That would resolve a number of my LGPL misgivings about dynamic linking. I don't know how you would make the compiler generate the slower PIC references to the data in that case, and NOT do it in all cases. > That would be way faster than mmap'ing ld.so all the time... Unless the kernel did the mapping and the ld.so was (effectively) a piece of the execution class loader, as a result. The difference, I suppose, is where the r/o mappings for the linker code originated, and whether they were in the process address space, or whether you had to cross a real protection domain to get them. I'd almost prefer they stay in the process address space (trading startup speed in favor of runtime speed). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.