># > [W]hile there's no reason that *all* architectures shouldn't benefit
># > from this neat hack, it does require putting gzip in the kernel.
># 
># That was my first thought too.
># 
># Now I'm not so sure.  Couldn't ld.so or ld.elf_so or whatever it's
># called these days handle forking gunzip?  Or Am I Missing Something
># (tm)?
>
>:-)
>
>The problem lies in that most of the executables compiled for the miniroot
>are *static*.
>
>And even if ld.so or whatever did that, that's still kind of a lose:
>What if gunzip is gzipped? :-)

nah...it's more fundamental than that.  if you gzip a binary, the part
of it that identifies it as "shared" is also gzipped.  the kernel
would have to *at least* gunzip that, and if it's gonna go that far,
it might as well gunzip the rest.  on demand.

>I think the guts of gunzip need to be built into the exec module, callable
>from the exec module or built in to ld.so*.

i'd expect a "options EXEC_GZIP" bit, but freebsd has it as
"pseudo-device gzip".  then again...what do i know?  :)

hmm...and it would also be "neat" if it (the program) could get
gunzip'ed and *then* passed off to an interpreter...or some emulation
(eg, linux, a.out, etc).

(...wondering about having gzip'ed perl scripts that call a gzip'ed
linux binary of perl as the interpreter...just as an exercise... :)

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."