When I first looked at the filesystem code as a kernel-hacking newbie
about a year code I was struck by the fact that the headers of every
filesystem are included in fs.h, seemingly just for the purpose of
finding out the size of the filesystem-specific superblock and inode
info.
The longer I work with this code the more I feel that the simple need
to calculate two union sizes is keeping the whole vfs from being properly
factored. According to my simple-minded way of looking at things, the
vfs ought be compileable without depending on *any* of the files
belonging to specific filesystems.
The current inverted arrangement forces all kinds of awkward tricks in the
header files - noteably having to define special symbols to keep headers
from being compiled more than once. The order of header compilation winds
up being much less than obvious. Vfs is forced to know about every
filesystem in the linux world and can't be compiled without compiling
the headers of all of them, nor can any of the included filesystems be
compiled safely without recompiling vfs. In other words, vfs isn't yet
fully "virtual": it's tied by just two slender threads to filesystem
specifics.
This factoring problem can be fixed quite easily and elegantly I think.
My question is: does anybody besides me see this as something that needs
fixing? Is there some reason I don't know about for vfs to see the
headers of every filesystem, and is there a philosophical reason for
things staying the way they are?
-- Daniel- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:27 EST