mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Shuah Khan <skhan@linuxfoundation.org>
To: Jeff Layton <jlayton@kernel.org>, Jori Koolstra <jkoolstra@xs4all.nl>
Cc: Christian Brauner <brauner@kernel.org>,
	Khalid Aziz <khalid@kernel.org>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Jan Kara <jack@suse.cz>, Taotao Chen <chentaotao@didiglobal.com>,
	NeilBrown <neil@brown.name>,
	linux-kernel@vger.kernel.org,
	syzbot+4e49728ec1cbaf3b91d2@syzkaller.appspotmail.com,
	Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH] Add error handling to minix filesystem similar to ext4
Date: Thu, 30 Oct 2025 09:44:40 -0600	[thread overview]
Message-ID: <dceefe7e-4cd3-464d-b5b4-f80c02b4331d@linuxfoundation.org> (raw)
In-Reply-To: <1ed30710481dd6739e6e9b4bd6f57c7c9d7e7de3.camel@kernel.org>

On 10/30/25 09:12, Jeff Layton wrote:
> On Thu, 2025-10-30 at 15:09 +0100, Jori Koolstra wrote:
>>>
>>> I don't see a licensing issue. It's BSD licensed. Also, this is a
>>> userland code, so we wouldn't need to worry about that too much.
>>>
>>
>> Oh, my bad. I thought Minix (the OS) had some licensing incompatibilities
>> with Linux, and this repo takes code from Minix. But that may be long in
>> the past.
>>
> 
> Minix is BSD licensed too. That's not completely incompatible with the
> GPL, but IANAL.
> 
>>>
>>> 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!
>>
>> Would an in-tree but out of kernel implementation be an idea? Like how
>> kselftest is integrated in the code, even though most of that also takes
>> place in userland. That would guarantee a level of support, at least for
>> the time being. I could take the code, verify it, and write some tests
>> for in selftest.
>>
> 
> That's not a bad idea. We already have some userland code in the kernel
> tree (the tools/ directory comes to mind). A directory with replacement
> FUSE drivers for in-kernel filesystems could be a reasonable thing to
> add. Anything we keep in-tree will need to be GPL-compatible though.

Jori, if you want to continue working on userland slotions and working
to initiate deprecating, working - please do.> 
>> And there is still the issue of what we do for the syzbot bugs until a
>> more permanent solution is achieved.
>>
> 
> Yeah, that's a different issue.  Most likely we'll need to fix those in
> the near term. Replacing minix.ko with a FUSE fs will take time
> (years), even once we have a new driver in hand.
Does this mean Jori can work on fixing these while replacing minix.ko
with fuse progresses?

> 
> We'll need to mark the old driver deprecated and then wait a few
> releases before we can rip it out.
Jori could work on patches for deprecating perhaps?

> 
>> Anyway, this probably goes over my head as a clueless beginner. Just
>> trying to see where I can help. Thanks a lot Jeff for you answers, I
>> appreciate it.
>>
> 
> You're welcome. We all start out as beginners!

+1

thanks,
-- Shuah


  reply	other threads:[~2025-10-30 15:44 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 [this message]
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
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=dceefe7e-4cd3-464d-b5b4-f80c02b4331d@linuxfoundation.org \
    --to=skhan@linuxfoundation.org \
    --cc=brauner@kernel.org \
    --cc=chentaotao@didiglobal.com \
    --cc=jack@suse.cz \
    --cc=jkoolstra@xs4all.nl \
    --cc=jlayton@kernel.org \
    --cc=khalid@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --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®