>
>
> On Thu, 20 Sep 2001, Steve Lord wrote:
>
> > 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_.
Well there is not an order of magnitude in it, and it then leaves SGI
in the situation of having two even more divergent versions of XFS
than we have now. I do realise there are two conflicting goals in all of
this.
>
> 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.
Well, not everything, but the vast majority of the xfs code has not
had to change at all, we have a different buffer cache interface,
and the read/write path is different, and the inode creation/teardown
interface needed surgery to work with linux inodes, oh and endian
conversion. But apart from that ......
>
> > > 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.
Working on the locking first, the tricky part is how locks interact with
the transaction mechanism.
Steve
-
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/
This archive was generated by hypermail 2b29 : Sun Sep 23 2001 - 21:00:43 EST