linux-ext4 - Re: [patch 07/12] rfc: 2fsprogs update

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] [day] [month] [year] [list]

Date:	Wed, 27 Sep 2006 10:38:00 -0400
From:	Theodore Tso <tytso@....edu>
To:	Alexandre Ratchov <alexandre.ratchov@...l.net>
Cc:	linux-ext4@...r.kernel.org,
	Jean-Pierre Dion <jean-pierre.dion@...l.net>
Subject: Re: [patch 07/12] rfc: 2fsprogs update

On Wed, Sep 27, 2006 at 03:36:42PM +0200, Alexandre Ratchov wrote:
> Perhaps it's not obvious, but thats my approach to get all of the
> conversions right without rewriting everything from scratch ;-). I'm still
> open to other approches.

Yes, and I appreciate that concern.  However, given that we need to
support an extents-based iterator anyway, and given that we need to
break the bitmap code anyway so that it gets away from using inline
functions and can __eventually__ support multiple back-end
implementation, we will end up needing to breaking and reimplementing
the interfaces anyway....  and for the other bits of code, simply
defining a new interface and changing blk_t to blk64_t isn't that hard
and isn't want I would call "rewriting".   

The other thing I would mention is that my plan for the extent
iterator is that if the inode uses indirect blocks, what the extent
iterator would do is call the block iterator function, and then
coalesce the results into extents and call the extent callback
function.  So the question of when to use __u32 pointers wouldn't
arise, since we would use the existing code to iterate through the
indirect blocks.  Easy!

Similarly, what I would do for the block_iterator is *if* the inode is
extent based, and *if* the filesystem is less than 2**32 blocks, then
the block iterator would call the extent_iterator, and then translate
the extents into blocks and call the block iterator's callback
function multiple times.  This would be a backwards compatibility
scaffolding, until other portions of the library were converted over
use the extent iterator directly.

So in this fashion it's possible to minimize the amount of code that
we need to maintain in parallel; each functionality is only
implemented in one place, and yet the result still has as much
backwards compatibility as possible.

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html