linux-kernel - Re: [GIT PULL] Squashfs pull request for 2.6.29

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 11 Jan 2009 10:30:37 +0100 (CET)
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Jörn Engel <joern@...fs.org>,
	David Brown <lkml@...idb.org>,
	Phil Oester <kernel@...uxace.com>,
	Kay Sievers <kay.sievers@...y.org>,
	Phillip Lougher <phillip@...gher.demon.co.uk>,
	Christoph Hellwig <hch@...radead.org>,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [GIT PULL] Squashfs pull request for 2.6.29

On Sat, 10 Jan 2009, Ingo Molnar wrote:
> * Andrew Morton <akpm@...ux-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@...ux-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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/