Date: Mon, 13 Mar 1995 16:05:34 -0800 (PST) From: Poul-Henning Kamp <phk@ref.tfs.com> To: kargl@troutmask.apl.washington.edu (Steven G Kargl) Cc: phk@freefall.cdrom.com, freebsd-hackers@freefall.cdrom.com Subject: Re: install compressed binary patch Message-ID: <199503140005.QAA01137@ref.tfs.com> In-Reply-To: <199503132346.PAA15798@troutmask.apl.washington.edu> from "Steven G Kargl" at Mar 13, 95 03:46:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Poul, Hackers,
>
> I have added a `-z' option to install. It will tell install to
> execute gzip to compress a binary and create a sym link. I have
> tested my addition, and it appears to work correctly. This might
> be useful for a `make world' on a machine with limited disk space.
> You obviously do not want to blindly compress all binaries during
> a `make world':-)
>
> Of course, your kernel must be compiled to run gzipped binaries.
Hi Steven,
Thanks for the patch.
Two things,
1. The patch. You shouldn't need to fork a process to make the
symlink, but then again, you shouldn't need the symlink in the
first place ?
2. I'm not sure it makes much sense to do it in the first place.
Let me explain what I mean. On any machine capable of doing a make world,
you should not need to used gzip bin's on a large scale.
Wouldn't you gain more diskspace if you told cc(1) about ".gz" files for
instance ? source compress better than binary I'd expect...
Now THERE'S a project:
Take a copy of the "nullfs", and call it "gzipfs", and it's perfectly OK
if it can only mount read-only.
The only difference from nullfs should be that if the file
when read contains a "gzip" header, you uncompress it on the fly...
The "inflate" code is already in the kernel...
Poul-Henning,
(trying to lure another innocent victim into kernel-hacking...)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503140005.QAA01137>