Date: Thu, 31 Jul 1997 13:22:20 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dg@root.com Cc: phk@dk.tfs.com, jkh@time.cdrom.com, chuckr@Glue.umd.edu, freebsd-current@freefall.FreeBSD.org Subject: Re: core group topics Message-ID: <199707312022.NAA07684@phaeton.artisoft.com> In-Reply-To: <199707311142.EAA28471@implode.root.com> from "David Greenman" at Jul 31, 97 04:42:32 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >Are we getting the kernel & userland mixed up here ? I belive there > >is strong agreement for ELF for the kernel... > > There is? I don't recall discussing that at all, and if we do eventually go > the ELF way, I think the kernel would be one of the last areas we'd want to > convert since it further complicates our cramped bootblocks. This is only true if you maintain support for booting non-ELF kernels; I view this as more of a transition issue than anything else. > The only issue I have against ELF is that I'm concerned that the overhead > for processing the much more sophisticated header at exec time might have a > serious impact on exec performance (something I'm particularly sensitive to > since I wrote the a.out exec code for FreeBSD). This is a bvery good point. But I think the benefits outweigh the costs. In particualr, the kernel could map the ld.so instead of making the crt0.o do it; this would buy back some of the overhead right away, if it stayed mapped in the cloned porcess address space from the fork to the exec. The same is actually true of the libc.so and other shared libraries, albiet a bit of an arbitrary mapping stretch (ie: pick a high address and map down). Specifically, I'd only place libc in this boat, seeing as how few programs can exist without system calls of one kind or another. 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?199707312022.NAA07684>