mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: Jori Koolstra <jkoolstra@xs4all.nl>,
	Christian Brauner <brauner@kernel.org>,
	 "skhan@linuxfoundation.org"	 <skhan@linuxfoundation.org>,
	Khalid Aziz <khalid@kernel.org>,
	Tetsuo Handa	 <penguin-kernel@i-love.sakura.ne.jp>,
	Taotao Chen <chentaotao@didiglobal.com>,
	 NeilBrown <neil@brown.name>,
	linux-kernel@vger.kernel.org,
	 syzbot+4e49728ec1cbaf3b91d2@syzkaller.appspotmail.com,
	"Darrick J. Wong"	 <djwong@kernel.org>
Subject: Re: [PATCH] Add error handling to minix filesystem similar to ext4
Date: Thu, 30 Oct 2025 14:00:16 -0400	[thread overview]
Message-ID: <f053d2a1c3eba92d390d13859b40203388e86bac.camel@kernel.org> (raw)
In-Reply-To: <ci6wvlqqh6jkdmnz5obfjx3moy67cik3354apiihifh4gtgx2t@zh4fk7zevbpx>

On Thu, 2025-10-30 at 18:22 +0100, Jan Kara wrote:
> 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.
> 

Right. We probably need to codify that into a checklist in
Documentation/ somewhere.

- feature parity (at least mostly, might can omit obscure things on
some crufty old filesystems)

- passes fstests (at least as well as the in-kernel driver)

- entry in a list of deprecated filesystems and where the tree is
hosted if they aren't hosted in the kernel tree

There are probably all sorts of other things I'm not thinking of too.
-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2025-10-30 18:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-28 20:58 Jori Koolstra
2025-10-30 10:59 ` Jan Kara
2025-10-30 11:18   ` Tetsuo Handa
2025-10-30 11:35     ` Jan Kara
2025-10-30 12:22   ` Jori Koolstra
2025-10-30 12:59     ` Jeff Layton
2025-10-30 13:31       ` Jori Koolstra
2025-10-30 13:43         ` Jeff Layton
2025-10-30 14:09           ` Jori Koolstra
2025-10-30 15:12             ` Jeff Layton
2025-10-30 15:44               ` Shuah Khan
2025-10-30 17:12                 ` Jan Kara
2025-10-30 17:40                 ` Jeff Layton
2025-10-30 17:18               ` Jan Kara
2025-10-30 23:42                 ` Jori Koolstra
2025-10-30 17:22           ` Jan Kara
2025-10-30 18:00             ` Jeff Layton [this message]
2025-10-30 15:38         ` Shuah Khan
2025-10-30 17:01     ` Jan Kara
2025-10-30 23:16       ` Jori Koolstra
2025-10-31 15:38         ` Jan Kara
2025-11-01 20:27 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f053d2a1c3eba92d390d13859b40203388e86bac.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=brauner@kernel.org \
    --cc=chentaotao@didiglobal.com \
    --cc=djwong@kernel.org \
    --cc=jack@suse.cz \
    --cc=jkoolstra@xs4all.nl \
    --cc=khalid@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=skhan@linuxfoundation.org \
    --cc=syzbot+4e49728ec1cbaf3b91d2@syzkaller.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®