On Fri, Jun 28, 2019 at 10:45:42AM +1000, Dave Chinner wrote: > On Tue, Jun 25, 2019 at 12:10:20PM +0200, Christoph Hellwig wrote: > > On Tue, Jun 25, 2019 at 09:43:04AM +1000, Dave Chinner wrote: > > > I'm a little concerned this is going to limit what we can do > > > with the XFS IO path because now we can't change this code without > > > considering the direct impact on other filesystems. The QA burden of > > > changing the XFS writeback code goes through the roof with this > > > change (i.e. we can break multiple filesystems, not just XFS). > > > > Going through the roof is a little exaggerated. > > You've already mentioned two new users you want to add. I don't even > have zone capable hardware here to test one of the users you are > indicating will use this code, and I suspect that very few people > do. That's a non-trivial increase in testing requirements for > filesystem developers and distro QA departments who will want to > change and/or validate this code path. A side topic here: Looking towards the future of prosects here with regards to helping QA and developers with more confidence in API changes (kunit is one prospect we're evaluating)... If... we could somehow... codify what XFS *requires* from the API precisely... would that help alleviate concerns or bring confidence in the prospect of sharing code? Or is it simply an *impossibility* to address these concerns in question by codifying tests for the promised API? Ie, are the concerns something which could be addressed with strict testing on adherence to an API, or are the concerns *unknown* side dependencies which could not possibly be codified? As an example of the extent possible to codify API promise (although I beleive it was unintentional at first), see: http://lkml.kernel.org/r/20190626021744.GU19023@xxxxxxxxxxxxxxxxxxx Luis
