Re: [PATCH] docs: add guidelines for submitting new filesystems

[Jaegeuk Kim <jaegeuk@kernel.org>]

On 04/18, Amir Goldstein wrote:
> On Fri, Apr 17, 2026 at 7:20 PM Jaegeuk Kim <jaegeuk@kernel.org> wrote:
> >
> > On 04/17, Matthew Wilcox wrote:
> > >
> ...
> > > I kind of want a section on "no weird ioctls".  Anything you want to
> > > implement beyond ioctls already implemented by other filesystems,
> > > you need to bring to linux-fsdevel as a separate proposal from "please
> > > merge my filesystem".  Almost anything implemented by f2fs is a good
> > > example here.
> >
> > I disagree to this. As a filesystem developer, I belive ioctl provides a way
> > to tune the filesystem-specific features which are not supported by all the
> > other filesystems.
> >
> 
> Jaegeuk,
> 
> Note that, despite Matthew's unhidden opinion about "weird ioctls",
> the proposed clause does not say that they are not allowed.
> 
> The section refers to the way to submit a new filesystem for review
> and requests that special ioctls will be clearly submitted separately.
> Here is how I have added it in my work branch:
> 
>  - Structure the submission logically.  It is neither acceptable to send one
>    large patch containing the entire filesystem, nor is a replay of the full
>    development history helpful to reviewers.  Instead, split the series by
>    topic -- for example: superblock and mount handling, inode operations,
>    directory operations, address space operations, and so on -- so that each
>    patch is reviewable in isolation.
> 
>  - Separate any filesystem-specific ioctls into their own patches with
>    dedicated justification.  Interfaces beyond those already common across
>    other filesystems will receive additional scrutiny because they are hard
>    to maintain and may conflict with future generic interfaces.
> 
>  - Expect thorough review.  Filesystem code interacts deeply with the VFS,
>    memory management, and block layers, so reviewers will examine the code
>    carefully.  Address all review feedback and be prepared for multiple
>    revision cycles.

Thanks, those are all reasonable to me, as I did quite similarly in 2012,
https://lwn.net/Articles/518718/.

Some useful tips before submission might be helpful:
1) find a company sponsorship for long-term maintenance support
2) present key differentiating features to filesystem/kernel leads (e.g., Ted)
3) check any patent/copyright violation
4) share the results of xfstests/fsstress/power-off recovery test/code coverage

Thanks,

> 
> Thanks,
> Amir.