Re: file as a directory

From: Amit Gud
Date: Wed Nov 24 2004 - 06:09:10 EST


On Wed, 24 Nov 2004 11:32:13 +0100, Helge Hafting <helge.hafting@xxxxxxx> wrote:
> Amit Gud wrote:
>
>
>
> >On Mon, 22 Nov 2004 16:04:28 +0100, Helge Hafting <helge.hafting@xxxxxxx> 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.
> >
> This is not so easy, as you have to audit the new version for
> correctness. It is not the end of the world if tar or gzip
> occationally crashes on some corner case. The kernel
> must not do that though.
>

Yes, thats what I said in my last post...if the archive looks improper
forget it.

> And then there is the much more complicated issues when
> writing into such an archive. You skipped that part, or
> are you looking for a read-only solution only?
>

I'm coming up with something soon, along with the proof of
concept....to wrap up all scenarios....need some time ;)

AG
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/