Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Jun 1999 10:29:40 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        Chuck Robey <chuckr@picnic.mat.net>
Cc:        "Brian F. Feldman" <green@unixhelp.org>, Jean-Marc Zucconi <jmz@FreeBSD.org>, hoek@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: Re2: cvs commit: src/sys/kern imgact_gzip.c 
Message-ID:  <19990622022940.9D1AB75@overcee.netplex.com.au>
In-Reply-To: Your message of "Mon, 21 Jun 1999 21:51:44 -0400." <Pine.BSF.4.10.9906212151240.393-100000@picnic.mat.net> 

next in thread | previous in thread | raw e-mail | index | archive | help
Chuck Robey wrote:
> On Mon, 21 Jun 1999, Brian F. Feldman wrote:
> 
> > Actually, would it be too hard to implement gzip as a stacking VFS layer?
> > That way, you really could just pass a gzip-backed vnode to the elf
> > interpreter...
> 
> That would be if stacking worked here, wouldn't it?

The other problem is that gzip decodes in a stream and it's impractical (or
expensive) to pull out a block at a time from the decompressed output..
The only practical way to do it is to decompress to memory in full and then
use that for the upper layer.  That will cost memory though so it would
have to be pageable (ie: anon/swap backed).  The result would be the same
as if imgact_gzip managed it - and would avoid the stacking problems too.

Still, I can see the appeal of having gzip support in a stackable layer,
but IMHO, the convenience of being able to read foo.gz by doing a 'more
foo' isn't worth the nightmares that this would unleash.  Imagine the
implications of 'vi foo'.  This transparency would have to be read-only or
the kernel would have to be prepared to recompress the entire file each
time somebody changes a byte near the beginning..  And then there's the
coherency problem of having the same data "visible" in both normal and .gz
format..

Cheers,
-Peter



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990622022940.9D1AB75>