> I think XFS could try hard to archive the first item, even if it
> loses some functionaly that needs to be pulled in through extra patches,
> but given the current SGI policy/development model I don't think b)
> is / will be a goal. It's up to Al and Linus to decide whether b) is
> important or not, but I strongly doubt they will take an XFS patch with
> all the mainline invasion the current version has.
I think outside XFS changes should be definitely done if it makes XFS
cleaner and is a improvement of the rest of the kernel too.
I also don't think it'll be a big problem to integrate such changes
(even independent of XFS) when they are submitted separately and
explained to the relevant maintainers. To give one example the current
hack used in XFS to manage NFS readahead windows is rather ugly. It would
be much cleaner to change nfsd instead to cache file descriptors
and remove the ugly/bad/broken racache there. Such a change would
help XFS and clean up the kernel and be an obvious improvement for
everybody and I think it would be rather easy to integrate it.
Trying hard in XFS to not change code outside fs/xfs is imho a waste
of time. Just for outside changes it is probably best and most painless
to submit them as soon as possible when they are done, not defer them to
the great "xfs merging". This way XFS will eventually just fit
naturally in.
-Andi
|