On Fri, 9 Jun 2006, Matthew Wilcox wrote:
>
> One of the costs (and I'm not disagreeing with your main point;
> I think forking ext3 to ext4 at this point is reasonable), is that
> bugfixes applied to one don't necessarily get applied to the other.
I agree. However, that tends to be less of an issue of you fork off a
stable base (which isn't always the case). Forking off something that is
being stil actively developed is a different matter entirely. I don't
think ext3 is in that situation, really.
Also, one of the issues is when there are big VFS layer changes, which
affect all filesystems. Then, a lot of people will think that it's easier
to fix up one unified filesystem than it is to fix up five separate ones,
and the fact is, that's often _not_ the case.
The unified filesystem potentially has so much crud and crap and other
issues that it ends up being much more work to understand and fix it up
than it would have been to do the same thing for five different
filesystems that didn't play a lot of games and have complex
"if this flag is set, do this code, otherwise do that code, and this
whole directory reading code btw has a static CONFIG_EXT3_INDEX thing,
so you won't even know if you caught all the interface changes when you
get a clean compile"
So I'm not a huge believer in "shared code is good code". I believe shared
code is good only if it has no conditionals.
Ie the VFS-layer kind of code that acts the SAME for everybody is the good
kind of sharing. The kind where you call into different routines that will
do different things depending on a flag (which may not even be obvious to
the caller) is usually the _bad_ kind of sharing, because that's the kind
of code that ends up working for one user and not working for another, and
trying to make it work for both may be fundamentally hard.
The
if (sb->option.extent)
.. do one thing ..
else
.. do another ..
kind of thing is exactly what leads to problems later. Even if it allows
sharing of 90% of the code (the caller of the function), it leads to
problems exactly because of things that end up not quite working because
people only tested one code-path, and it broke the other case in some
really subtle way.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
