lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ