Re: toolchain/50051: config(1) can no longer deselect filesystems properly

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

The following reply was made to PR toolchain/50051; it has been noted by GNATS.

From: Masao Uebayashi <uebayasi%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: toolchain/50051: config(1) can no longer deselect filesystems properly
Date: Sun, 22 Nov 2015 21:49:17 +0900

 This seems to have been fixed by one of pgoyette@'s changes.
 
 On Thu, Jul 16, 2015 at 5:30 PM,  <dholland%netbsd.org@localhost> wrote:
 >>Number:         50051
 >>Category:       toolchain
 >>Synopsis:       config(1) can no longer deselect filesystems properly
 >>Confidential:   no
 >>Severity:       critical
 >>Priority:       high
 >>Responsible:    toolchain-manager
 >>State:          open
 >>Class:          sw-bug
 >>Submitter-Id:   net
 >>Arrival-Date:   Thu Jul 16 08:30:00 +0000 2015
 >>Originator:     David A. Holland
 >>Release:        NetBSD 7.99.20 (20150716)
 >>Organization:
 >>Environment:
 > System: NetBSD homeworld.netbsd.org 6.1_STABLE NetBSD 6.1_STABLE (NBMAIL) #0: Sun Dec 7 15:42:53 UTC 2014 spz%franklin.NetBSD.org@localhost:/home/netbsd/6/amd64/obj/sys/arch/amd64/compile/NBMAIL amd64
 > Architecture: x86_64
 > Machine: amd64
 >>Description:
 >
 > Commenting out "file-system FFS" does not produce the same
 > configuration as writing "file-system FFS" then "no file-system FFS".
 >
 > In particular, in the latter case 'ufs' is still selected by config
 > and some (but not all) of sys/ufs/ufs/*.c is built; this then causes
 > link failure. (The link failure is itself a bug, but this config issue
 > is substantially more important.)
 >
 > The problem seems to be that 'no file-system' is no longer a complete
 > inverse operation. With sufficient -d flags (the -d flag is
 > undocumented, which is also a bug), observe:
 >
 >    nbconfig -d -d -d -d GENERIC
 >      :
 >    GENERIC:150: debug: fs selected `FFS'
 >    GENERIC:150: debug: attr selected `uvm'
 >    GENERIC:150: debug: attr selected `machdep'
 >    GENERIC:150: debug: attr selected `kern'
 >    GENERIC:150: debug: attr selected `vfs'
 >    GENERIC:150: debug: attr selected `ufs'
 >    GENERIC:150: debug: attr selected `uvm'
 >    GENERIC:150: debug: attr selected `machdep'
 >    GENERIC:150: debug: attr selected `kern'
 >    GENERIC:150: debug: attr selected `vfs'
 >    GENERIC:150: debug: attr selected `ffs'
 >    GENERIC:151: debug: deselecting fs `FFS'
 >    GENERIC:151: debug: opt `FFS' deselected
 >    GENERIC:151: debug: opt `ffs' deselected
 >      :
 >
 > Note that these are not inverses and in particular ufs is left behind.
 > (All those other things are left behind too but they're going to be
 > getting included anyway so they aren't noticeable...)
 >
 > It is not clear when this bug was introduced; last fall's config
 > changes seem the most likely culprit. The lfs/ufs split, finished in
 > June 2013, is an absolute upper bound because at the time I was very
 > careful about being able to build kernels that had no ufs*.o files in
 > them, or even any ufs_* symbols.
 >
 > If the problem doesn't affect -7, it almost certainly implicates last
 > fall's config changes. However, I'm still checking this as I don't
 > have a -7 tools built right now.
 >
 >>How-To-Repeat:
 >
 > To see this in its full glory, comment out FFS, MFS, and EXT2FS from
 > the amd64 GENERIC, run config, and do 'grep ufs Makefile' in the build
 > dir.
 >
 > Then repeat with MFS and EXT2FS still commented out and instead of
 > commenting out FFS, add 'no file-system FFS' right after the
 > 'file-system FFS' line. Run config, repeat the grep, watch four files
 > from sys/ufs/ufs appear. (Then build the resulting config and watch it
 > fail on ufs_truncate.)
 >
 >>Fix:
 >
 > Not sure.
 >