[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ci6wvlqqh6jkdmnz5obfjx3moy67cik3354apiihifh4gtgx2t@zh4fk7zevbpx>
Date: Thu, 30 Oct 2025 18:22:20 +0100
From: Jan Kara <jack@...e.cz>
To: Jeff Layton <jlayton@...nel.org>
Cc: Jori Koolstra <jkoolstra@...all.nl>, Jan Kara <jack@...e.cz>, 
	Christian Brauner <brauner@...nel.org>, "skhan@...uxfoundation.org" <skhan@...uxfoundation.org>, 
	Khalid Aziz <khalid@...nel.org>, Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, 
	Taotao Chen <chentaotao@...iglobal.com>, NeilBrown <neil@...wn.name>, linux-kernel@...r.kernel.org, 
	syzbot+4e49728ec1cbaf3b91d2@...kaller.appspotmail.com, "Darrick J. Wong" <djwong@...nel.org>
Subject: Re: [PATCH] Add error handling to minix filesystem similar to ext4
On Thu 30-10-25 09:43:26, Jeff Layton wrote:
> On Thu, 2025-10-30 at 14:31 +0100, Jori Koolstra wrote:
> > One question I would have about this is that if we move minix, for
> > instance, out of the kernel code, how can we be sure that it is
> > maintained. What if some Github repo suddenly disappears? Like I said,
> > I would be fine with helping maintain minix, otherwise what should be
> > the course of action from here? What demands do we place on a userland
> > replacement for minix before I submit a patch to deprecate and remove
> > the code?
> > 
> 
> These are great questions that I don't think we have an answer for just
> yet.
> 
> In practice, FUSE interfaces are quite stable, and the minixfs format
> also doesn't change a lot. Much like minixfs in the kernel, I wouldn't
> expect that it would require a lot of maintenance itself over the long
> haul (but everything requires _some_). It might need some to keep up
> with broader OS changes, but that's not usually too burdensome.
> 
> You're quite right though that userland replacements will need to meet
> some criteria before we can rip out the in-kernel versions. This might
> be a good discussion topic for next year's LSF/MM!
Usually the requirement is feature parity - meaning if the kernel can read
/ write filesystem with some set of features, then the other drivers should
support that as well. Also passing the same set of fstests is a good
indication the replacement is sound. Darrick did quite some work with
making fstests work better for FUSE filesystems recently if I remember
correctly.
								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists
 
