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
No namespace collision.
No clean up problems
AND a general solution, not tied up to perl, python, java, or anything
else, as well as supporting ANY kind of file type in the executable.
And of course overloading the kernel with more crap :-)
ANy insights?
Just a "bad idea" without any reasoning goes straight to /dev/trolling
TJ
--
Terje Eggestad
Senior Software Engineer
dir. +47 22 62 89 61
mob. +47 975 31 57
fax. +47 22 62 89 51
[email protected]
Scali - http://www.scali.com
High Performance Clustering
Terje Eggestad <[email protected]> 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
[email protected]
Hi!
> Same problem with python (i'm just learning), and a collection of .class
> files for java.
For java its called .jar.
> 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)
See uservfs.sf.net.
But intercepting those system calls would be better, portable to macOsX etc...
Or simply link those interpretters with uservfs; its going to be
usefull for other stuff, too.
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms