Pekka Enberg writes:
> I think the fact that it is highly architecture specific is relevant. I
> have no way of testing spufs changes except on cell, no? And if I am
> developing on a cell, I probably will notice it in arch/ all the same.
> So I don't quite buy your the maintenace argument.
Think about someone changing the VFS layer interface and fixing up all
the filesystems to accommodate that change. That person is doing some
of your work for you, so you want to make it easy for him/her to find
your filesystem. That's the sort of thing I was referring to as
maintenance.
As for changes on the cell-specific side, the people doing those
changes will know where to find it, so it isn't a problem having it in
fs/.
Having it in fs/ also means that it is more likely that people
familiar with VFS internals will look through your code and comment on
it. I know that can be painful in the short term, but in the long
term it will lead to better code.
Paul.
-
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]
