mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Ryan C. Gordon" <icculus@icculus.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 1/2] binfmt_elf: FatELF support in the binary loader.
Date: Tue, 20 Oct 2009 00:43:09 -0400 (EDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.0910200034500.18342@andre.icculuslan> (raw)
In-Reply-To: <4ADD005A.4000401@goop.org>


> The idea seem interesting, but does it need to be ELF-specific?  What
> about making the executable a simple archive file format (possibly just
> an "ar" archive?) which contains other executables.  The archive file
> format would be implemented as its own binfmt, and the internal
> executables could be arbitrary other executables.  The outer loader
> would just try execing each executable until one works (or it runs out).

I'm not sure the added flexibility is worth the extra complications. 
FatELF solves a specific problem: merging multiple ELF targets into one 
file, the most compelling use-case being to glue x86_64 and i686 binaries 
together.

What you're describing would definitely be the route I'd have chosen if, 
say, a.out files were still in widespread use and actively competed with 
ELF for mindshare.

> That is, what you have here, but without hacking up binfmt_elf more.

I like to think of it as art, like a chef carving a fine piece of meat. :)

--ryan.


  reply	other threads:[~2009-10-20  4:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-19 14:39 Ryan C. Gordon
2009-10-20  0:12 ` Jeremy Fitzhardinge
2009-10-20  4:43   ` Ryan C. Gordon [this message]
2009-10-23 22:16     ` Jeremy Fitzhardinge
2009-10-24  0:25       ` Ryan C. Gordon
2009-10-21  8:08 ` Ryan C. Gordon
2009-10-22  7:31 ` Nicholas Miell
2009-10-22  9:22   ` Ryan C. Gordon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.00.0910200034500.18342@andre.icculuslan \
    --to=icculus@icculus.org \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome