Re: Ironic visualization in menuconfig for NTFS_FS vs NTFS3_FS
Julian Braha <[email protected]>
| Newsgroups | gmane.linux.file-systems,gmane.linux.kbuild.devel,gmane.linux.kernel |
|---|---|
| Message-ID | <[email protected]> |
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