Linux kbuild/kconfig development
 help / color / mirror / Atom feed
From: Julian Braha <julianbraha@gmail.com>
To: Xi Ruoyao <xry111@xry111.site>, linux-kbuild@vger.kernel.org
Cc: Nathan Chancellor <nathan@kernel.org>,
	Nicolas Schier <nsc@kernel.org>, Hyunchul Lee <hyc.lee@gmail.com>,
	Mingcong Bai <jeffbai@aosc.io>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: Ironic visualization in menuconfig for NTFS_FS vs NTFS3_FS
Date: Tue, 16 Jun 2026 15:22:10 +0100	[thread overview]
Message-ID: <b3c2fecb-0aa3-4ab0-b7a1-c8b9985e028b@gmail.com> (raw)
In-Reply-To: <cbe95c15d2760f6fce8eaf207c969ce8fd3703aa.camel@xry111.site>

Hi Xi,

On 6/16/26 10:24, Xi Ruoyao wrote:
> Hi,
> 
> In the Kconfig for NTFS3 we now have:
> 
> config NTFS3_FS
>     tristate "NTFS Read-Write file system support"
>     depends on !NTFS_FS || m
> 
> It basically means some sort of conflict between NTFS_FS and NTFS3_FS. 
> But then menuconfig is apparently puzzled to believe NTFS3_FS "depends
> on" NTFS_FS, and put NTFS3_FS as a subentry of NTFS_FS:
> 
>   │ │    <M> NTFS file system support                                     │ │  
>   │ │    [ ]   NTFS debugging support (NEW)                               │ │  
>   │ │    [ ]   NTFS POSIX Access Control Lists (NEW)                      │ │  
>   │ │    <M>   NTFS Read-Write file system support                        │ │  
>   │ │    [ ]     64 bits per NTFS clusters                                │ │  
>   │ │    [*]     activate support of external compressions lzx/xpress     │ │  
>   │ │    [ ]     NTFS POSIX Access Control Lists                          │  

This looks like a bug in menuconfig's behavior, as from
Documentation/kbuild/kconfig-language.rst:
"If a menu entry somehow depends on the previous entry, it can be made a
submenu of it."

And since Kconfig treats 'source' similarly to C's '#include' (the text
of the file effectively just gets copy-pasted in), it's like the config
options in fs/ntfs3/Kconfig immediately follow the options in
fs/ntfs/Kconfig since the sources are back-to-back.

You can test this by simply adding some other, unrelated config option
between the two 'source' entries that doesn't depend on NTFS_FS or
!NTFS_FS.

So, anyway, it seems to be simply ignoring the '!', and just treating it
as a dependency.
And you can test this by removing that dependency on !NTFS_FS, which
causes menuconfig to stop rendering it as part of the menu.

I think your workaround is okay (there are other similar 'NO_' config
options in the kernel), but it would be better to fix this menuconfig
bug.

- Julian Braha

      reply	other threads:[~2026-06-16 14:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16  9:24 Ironic visualization in menuconfig for NTFS_FS vs NTFS3_FS Xi Ruoyao
2026-06-16 14:22 ` Julian Braha [this message]

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=b3c2fecb-0aa3-4ab0-b7a1-c8b9985e028b@gmail.com \
    --to=julianbraha@gmail.com \
    --cc=hyc.lee@gmail.com \
    --cc=jeffbai@aosc.io \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=nsc@kernel.org \
    --cc=xry111@xry111.site \
    /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