> Two answers here - economics and code stability. This is a filesystem
> which has been worked on by people being payed to do so by a corporation,
> therefore there is a budget (long since blown). It was simpler and hence
> cheaper to wrap XFS in a conversion layer than to rework the code down
> into the bowels of the filesystem. Then the stability part of it, we
> started with a working filesystem, from an engineering standpoint it
> made more sense to keep as much of the existing code base intact as
> possible - the less surgery performed the better in terms of keeping
> things running, and making it easy to take enhancements and fixes made
> in the Irix base into the Linux code (we don't do it the other way around).
True, but there's a cost of maintaining the source and reducing the
size of said source by order of magnitude will help to reduce _that_.
The argument would make sense if you were treating everything under
your compatibility layer as a black box, but I sincerely hope that
it's not the case.
> > o checks already peformed by the VFS all over the place
> > (just take a look at xfs_rename.c!)
>
> I think I will answer this one more slowly and in response to Al Viro's
> email. But that economics/stability thing comes into it again.
Looking forward to that... Just documenting the exclusion requirements
of CXFS would help. Big way. As it is, you are bordering on the "adding
undocumented API for proprietory module" and while I've got no problems
with the last part (I don't suffer from stallmanellosis), I really don't
like the first one. Nobody's asking to give up the guts of CXFS, but
having its exclusion requirements documented is a different story.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/