From owner-freebsd-current Mon Apr 22 19:03:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA14815 for current-outgoing; Mon, 22 Apr 1996 19:03:55 -0700 (PDT) Received: from xi.dorm.umd.edu (root@xi.dorm.umd.edu [129.2.152.45]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA14803 for ; Mon, 22 Apr 1996 19:03:52 -0700 (PDT) Received: from localhost (smpatel@localhost [127.0.0.1]) by xi.dorm.umd.edu (8.7.5/8.6.12) with SMTP id WAA01003; Mon, 22 Apr 1996 22:03:41 -0400 (EDT) Date: Mon, 22 Apr 1996 22:03:41 -0400 (EDT) From: Sujal Patel X-Sender: smpatel@xi.dorm.umd.edu To: John Polstra cc: current@freebsd.org Subject: Re: possible 4th option? [Re: kern/1102] In-Reply-To: <199604230135.SAA03252@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 22 Apr 1996, John Polstra wrote: > They're not unused -- they're _reserved_. If you stick anything other > than 0 in them, you're technically no longer producing a valid ELF file. > The analogous objection applies also to other ELF header fields such as > e_type, e_machine, and e_flags. > > This may seem like a minor nit, but it's not. Suppose somebody else, > say Sun, also decides to identify their executables using the extra > bytes of the e_ident tag. Suppose their choice of values collides with > yours. Too bad, you're out of luck. You are absolutely correct here. Unless it's in the standard, it's a hack. > I'm going to try to add this kind of identification to our FreeBSD ELF > executables, and fix the kernel to recognize them. (Unfortunately, as > usual, the binutils code maze is doing its best to make this difficult > for me.) I'd like to coordinate this with the Linux people, if they're > interested. If you can coordinate with the Linux people, then I think this would be worthwhile; otherwise we may be the only ones using this technique. I still think that we will need a method for the user to specify EXACTLY what type of binary we're dealing with (for those "slip through the crack" cases). I think that a variation of my original patch (moving all environment parsing to libc), would work very well for this. Sujal