Re: [MAINTAINERS/KERNEL SUMMIT] Trust and maintenance of file systems

[Matthew Wilcox <willy@infradead.org>]

On Wed, Sep 06, 2023 at 09:06:21AM +1000, Dave Chinner wrote:
> > Part 2: unmaintained file systems
> > 
> > A lot of our file system drivers are either de facto or formally
> > unmaintained.  If we want to move the kernel forward by finishing
> > API transitions (new mount API, buffer_head removal for the I/O path,
> > ->writepage removal, etc) these file systems need to change as well
> > and need some kind of testing.  The easiest way forward would be
> > to remove everything that is not fully maintained, but that would
> > remove a lot of useful features.
> 
> Linus has explicitly NACKed that approach.
> 
> https://lore.kernel.org/linux-fsdevel/CAHk-=wg7DSNsHY6tWc=WLeqDBYtXges_12fFk1c+-No+fZ0xYQ@mail.gmail.com/
> 
> Which is a problem, because historically we've taken code into
> the kernel without requiring a maintainer, or the people who
> maintained the code have moved on, yet we don't have a policy for
> removing code that is slowly bit-rotting to uselessness.
> 
> > E.g. the hfsplus driver is unmaintained despite collecting odd fixes.
> > It collects odd fixes because it is really useful for interoperating
> > with MacOS and it would be a pity to remove it.  At the same time
> > it is impossible to test changes to hfsplus sanely as there is no
> > mkfs.hfsplus or fsck.hfsplus available for Linux.  We used to have
> > one that was ported from the open source Darwin code drops, and
> > I managed to get xfstests to run on hfsplus with them, but this
> > old version doesn't compile on any modern Linux distribution and
> > new versions of the code aren't trivially portable to Linux.
> > 
> > Do we have volunteers with old enough distros that we can list as
> > testers for this code?  Do we have any other way to proceed?
> >
> > If we don't, are we just going to untested API changes to these
> > code bases, or keep the old APIs around forever?
> 
> We do slowly remove device drivers and platforms as the hardware,
> developers and users disappear. We do also just change driver APIs
> in device drivers for hardware that no-one is actually able to test.
> The assumption is that if it gets broken during API changes,
> someone who needs it to work will fix it and send patches.
> 
> That seems to be the historical model for removing unused/obsolete
> code from the kernel, so why should we treat unmaintained/obsolete
> filesystems any differently?  i.e. Just change the API, mark it
> CONFIG_BROKEN until someone comes along and starts fixing it...

Umm.  If I change ->write_begin and ->write_end to take a folio,
convert only the filesystems I can test via Luis' kdevops and mark the
rest as CONFIG_BROKEN, I can guarantee you that Linus will reject that
pull request.

I really feel we're between a rock and a hard place with our unmaintained
filesystems.  They have users who care passionately, but not the ability
to maintain them.