lkml.org 
[lkml]   [2009]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] Squashfs pull request for 2.6.29
On Sat, 10 Jan 2009, Ingo Molnar wrote:
> * Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > More importantly, the filesystem driver has to be able to read older
> > filesystem instances. This is a userspace-visible binary interface! A
> > really complex one.
> >
> > If for some reason we wish to change the on-disk format then that could
> > be done now. But once the code is merged, such changes could only be
> > done in a back-compatible way.
>
> IMHO what makes squashfs special is that:
>
> 1) it's read-only: i.e. we dont actually _generate_ this data structure.
> It comes from the outside.

This is not 100% true: the squashfs layout _has_ been changed in V4, in
response to review comments from the Linux kernel community on V3.3/V3.4.

> 2) it's a the "cat is already out of the bag" situation.
> It's in the field, it's used.

AFAIK, all existing users use pre-V4. Let's hope this is going to change soon.

Apart from the use for backups (old ones have to be read using e.g. unsquashfs
now), I think this is OK: in most situations (embedded, Live CDs), the kernel
and the file system image are generated together (this is what e.g. OpenWRT
does).

> Generally when a filesystem driver comes to us, its lowlevel format is
> pretty much a done deal already - it's out in the wild and we should say
> 'no' only as an exception mechanism for clearly unacceptable crap.
>
> Instead of trying to flex our muscle and steer the big red firetruck way
> after the fire has been put out already - by others.
>
> Saying 'no' at this stage comes at a great and largely unnecessary cost to
> everyone involved. I believe we force ourselves into the R&D flow at an
> inappropriately late stage - while at the same time we are unreceptive to
> early adopter projects who'd like to avoid that. We cannot have the cake
> and eat it too.
>
> At least IMHO.
>
> ( What could _perhaps_ change the picture a bit IMO is drivers/staging/ i
> think - we could take a far more active role in certain types of
> projects that have been done out of tree typically, with no formal
> promise for compatibility - or something like that. )

So if staging would have existed +one year ago, we should probably have
included squashfs 3.3 at that time, and just have moved it to fs/ once the V4
layout was finished?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


\
 
 \ /
  Last update: 2009-01-11 10:33    [W:1.305 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site