From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amit Gud Subject: Re: file as a directory Date: Tue, 23 Nov 2004 11:50:15 +0530 Message-ID: <2c59f003041122222038834d7e@mail.gmail.com> References: <2c59f00304112205546349e88e@mail.gmail.com> <41A1FFFC.70507@hist.no> Reply-To: Amit Gud Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <41A1FFFC.70507@hist.no> List-Id: Content-Type: text/plain; charset="us-ascii" To: Helge Hafting Cc: linux-kernel@vger.kernel.org, reiserfs-list@namesys.com On Mon, 22 Nov 2004 16:04:28 +0100, Helge Hafting wrote: > You won't get .tar or .tar.gz support in the VFS, for a few simple reasons: > 1. .tar and .tar.gz are complicated formats, and are therefore better > left to userland. Agreed that .tar.gz is a complicated format, but zlib is already in the kernel. It _should_ simplify inflate and deflate of files. And as compared to .gz format, .tar is much simpler, I guess. > > It is hard to make a guaranteed bug-free decompressor that > is efficient and works with a finite amount of memory. The kernel > needs all that - userland doesn't. I think, finite amount of memory is the concern of worry, not the rest ... if we could rely on zlib. > 2. Both .tar and .gz file formats may improve with time. Getting a new > version of tar og gunzip is easy enough - getting another compression > algorithm into the kernel won't be that easy. Doesn't zlib in the kernel gets updated as the formats change? If not, .tar formats would be worth trying first as proof of concept. AG -- May the source be with you.