On Sat, 10 Jun 2006, Kyle Moffett wrote:
>
> Why not: "extX_ops.do_something_useful();", then have fs/ext/ext{2,3,4}_ops.c
I think that kind of setup is hugely preferable to conditionals in the
code, if only because it tends to force people to do the abstractions
right, and make the code sequences independent.
I just don't think it's necessarily very realistic - it's _hard_ to
refactor code well. It also doesn't buy you hardly anything at all, since
the people who are interested in ext2 are usually not very interested in
sharing code with ext3. The filesystems simply aren't that similar, apart
from the layout.
ext2 is half the size of ext3, and that's ignoring JBD entirely.
That constant growth, btw, is one reason why splitting off legacy
filesystems is often a good idea. What do you want to bet that the 2000+
line difference RIGHT NOW in ext3/ext4 will grow in the future? Splitting
things off means that people who don't care about the new features can
just stay with a stable base and also avoid the bloat. Exactly the way you
can stay with ext2 on an old machine, and avoid the bloat of ext3.
There's also nothign that says that legacy filesystems cannot be
simplified. For example, it's perfectly realistic to say that ext3 (as a
legacy filesystem) doesn't support resizing, and simply ripping that part
out of it. The people who don't want the bloat will be happy. The people
who want the feature can move to ext4.
See? Splitting development is what allows you to make choices that you
simply otherwise don't _have_.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
