From owner-freebsd-current Thu Jul 31 13:26:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA01309 for current-outgoing; Thu, 31 Jul 1997 13:26:29 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA01299 for ; Thu, 31 Jul 1997 13:26:26 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA07684; Thu, 31 Jul 1997 13:22:21 -0700 From: Terry Lambert Message-Id: <199707312022.NAA07684@phaeton.artisoft.com> Subject: Re: core group topics To: dg@root.com Date: Thu, 31 Jul 1997 13:22:20 -0700 (MST) Cc: phk@dk.tfs.com, jkh@time.cdrom.com, chuckr@Glue.umd.edu, freebsd-current@freefall.FreeBSD.org In-Reply-To: <199707311142.EAA28471@implode.root.com> from "David Greenman" at Jul 31, 97 04:42:32 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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >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.