News for hackers. Stuff that matters.
Re:The Hairy State of Linux Filesystems by blasdel on Wednesday February 11, 2009 @07:33PM (#477804)
His argurment is completely bogus -- they're less slim because they share common code? Did he even look at the symbols he's complaining about?

The only filesystem I have built as a module on my machine is the brand-new btrfs, it has 223 unresolved symbols, and guess what? They're all basic, neccessary shit that should obviously be shared: mallocs, libc functions, concurrency primitives, block IO, inode management, VFS api, generic datastructures, zlib, etc.

This is more simplicity, not less, and an example of something that fustrates interlopers about the Linux kernel development culture -- your module does not make it into vanilla unless you're working at the same level as your siblings. If you have a systemic improvement to make, you make it to a lower layer, you don't get to keep your own toys.

This way all the filesystems are improved by the innovations of one -- it took years for the production-ready XFS code released by SGI to make it into Linus's tree because it effectively implemented its own VFS tools. Eventually all its improvements were merged into the VFS layer, the refactored XFS was merged in, and all users got a performance boost.

There are no comments on this comment yet.