linux-kernel - Re: [RFC 0/7] [RFC] cramfs: fake write support

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]

Message-ID: <4844A63B.2090509@lougher.demon.co.uk>
Date:	Tue, 03 Jun 2008 03:02:35 +0100
From:	Phillip Lougher <phillip@...gher.demon.co.uk>
To:	Erez Zadok <ezk@...sunysb.edu>
CC:	Arnd Bergmann <arnd@...db.de>, Jamie Lokier <jamie@...reable.org>,
	David Newall <davidn@...idnewall.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	hch@....de
Subject: Re: [RFC 0/7] [RFC] cramfs: fake write support

Erez Zadok wrote:
> In message <200806020951.26868.arnd@...db.de>, Arnd Bergmann writes:
>> On Monday 02 June 2008, Erez Zadok wrote:
> 
>>> Arnd, I favor a more generic approach, one that will work with the vast
>>> majority of file systems that people use w/ unioning, preferably all of
>>> them. � Supporting copy-on-write in cramfs will only help a small subset of
>>> users. � Yes, it might be simple, but I fear it won't be useful enough to
>>> convince existing users of unioning to switch over. � And I don't think we
>>> should add CoW support in every file system -- the complexity will be much
>>> more than using unionfs or some other VFS-based solution.
>> My idea was to have it in cramfs, squashfs and iso9660 at most, I agree
> [...]
> 
> Ah, ok.  Doing those 3 will get better coverage for existing users.  The
> question may come to how much code complexity does it add to each, and
> whether some common code can be excised into generic helpers?
> 

Yes, that's what I'm interested in.  From my reading of the patches, the 
general approach and a lot of the code should be directly useable in a 
fake-writable Squashfs.  The first step (a very big first step) is to 
get readonly Squashfs mainlined, which is what I'm working on at the 
moment.  After that I'll be very interested in looking at fake-write 
support and factoring any common code into generic helpers.

Phillip
--
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/