From owner-freebsd-hackers Mon Mar 13 16:05:38 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA02296 for hackers-outgoing; Mon, 13 Mar 1995 16:05:38 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA02290; Mon, 13 Mar 1995 16:05:37 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id QAA01137; Mon, 13 Mar 1995 16:05:35 -0800 From: Poul-Henning Kamp Message-Id: <199503140005.QAA01137@ref.tfs.com> Subject: Re: install compressed binary patch To: kargl@troutmask.apl.washington.edu (Steven G Kargl) Date: Mon, 13 Mar 1995 16:05:34 -0800 (PST) Cc: phk@freefall.cdrom.com, freebsd-hackers@freefall.cdrom.com In-Reply-To: <199503132346.PAA15798@troutmask.apl.washington.edu> from "Steven G Kargl" at Mar 13, 95 03:46:36 pm Content-Type: text Content-Length: 1373 Sender: hackers-owner@FreeBSD.org Precedence: bulk > 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...)