mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Måns Rullgård" <mru@kth.se>
To: linux-kernel@vger.kernel.org
Subject: Re: RFC: executable archive
Date: Tue, 20 Apr 2004 14:28:24 +0200	[thread overview]
Message-ID: <yw1xy8oq3kbb.fsf@kth.se> (raw)
In-Reply-To: <1082462304.27255.76.camel@pc-16.office.scali.no>

Terje Eggestad <terje.eggestad@scali.com> writes:

> Hello everybody
>
> I wanted to share and idea (and I'm sure I going to get booh'ed of the
> list but...) with you all. 
>
> One thing have annoyed me for a long time while writing perl progs, and
> that it not possible to "link" it, in that programs must span multiple
> files to be manageable as they grow. I'm sure we all agree that only
> trivial programs can be coded in a single source file. 
> The annoyment stems from the fact that a single "executable" must be
> distributed as multiple files. 
> A problem with perl, that Larry Wall should have though of right?
>
> Same problem with python (i'm just learning), and a collection of .class
> files for java. 
> The problem is compounded that all decent scripting languages allow
> compiled modules in the shaped of a shared object, which make it really
> hard on the developers of the scripting engine to make single exec. 
>
> What would solve it is have an executable archive, in where you put the
> top level script, subscripts, shared objects, and any other file it may
> need. 
>
> It would be nice to have a general solution to the problem. 
>
> My first though would be to make a stub, and put the ar file in the data
> area of the process, something akind to self extracting zip files on
> dos/windoze.
> A couple of problems: 
> a) you can't "mount" the ar file to make it visible to the process as a
> part of it's file system view. ( Atleast not without intercepting a
> whole lot of libc calls) 
> b) unpacking it somewhere would clobber up your fs as it would not be
> cleaned up after a program crash or machine crash. 
>
> Ideally I'd like to see the files in the ar as in the cwd, but that
> would make a namespace collision possible.   
>
> The second though would be to do it in the kernel, which would go
> something like this:
>
> - let the exec() handler in the kernel recognize the exec-ar, just like
> it recognizes the #! magic. 
> - use the loopback mount device to mount the ar (read only) under
> /proc/self/archive  
> (- it would be nice to do something to the env's like adding
> /proc/self/archive to PATH, LD:LIBRARY_PATH, of honor a file like
> /proc/self/env to modify the envs)
> - now exec the file /proc/self/archive/main

Apart from the /proc manipulations, all of the above could be
accomplished using binfmt_misc and a suitable wrapper program.

-- 
Måns Rullgård
mru@kth.se


  reply	other threads:[~2004-04-20 12:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-20 11:58 Terje Eggestad
2004-04-20 12:28 ` Måns Rullgård [this message]
2004-04-22 19:47 ` Pavel Machek

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=yw1xy8oq3kbb.fsf@kth.se \
    --to=mru@kth.se \
    --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

all inboxes | Powered by JetHome®