Linus Torvalds wrote:
On Wed, 7 Feb 2007, David Woodhouse wrote:
It isn't that far off, and we could improve it if we wanted to. In
_general_ it's quite good already.
I agree that it's close to hierarchical. But it's literally the exceptions
that get you.
Let me mention (again) USB_STORAGE and ATA.
They are not "under" SCSI. Making them do that would be insane.
But yes, you can do hierarchies by adding "pseudo-variables": as
mentioned several times, we could actually split CONFIG_SCSI into two
separate ones: CONFIG_SCSI that selects the core infrastructure, and
CONFIG_SCSI_DRIVER that actually controls the "hierarchical visibility".
Then CONFIG_SCSI_DRIVER (and USB_STORAGE, and SATA) would just do a simple
'select SCSI'. It would _not_ be hierarchical, and it would very much use
that same old "select", but it would possibly be a cleanup at least in the
sense that now CONFIG_SCSI wouldn't be used two different ways (one to
hide most SCSI drivers, and one to enable the core SCSI infrastructure
code).
It would work quite nicely in the graphical tools, although you've
thrown me a little by wanting it in the hacker's tool 'oldconfig' too.
You obviously care more about turning stuff _on_ with 'make oldconfig'
while other people who've spoken up seem to care more, as I do, about
turning stuff _off_ that way. If I want my hand held, I'm happy enough
to use the graphical tools.
I tend to just edit the .config file, and run "make oldconfig". And I know
I'm not the only one, because I've talked to others who do the same.
And yes, then it's almost always correct to "turn things on as needed to
make everything work out right", while turning things off would be
actively wrong.
That seems odd to me. I usually use edit + oldconfig to disable a
symbol. Maybe to enable a symbol occasionally. But the symbols
that I want to enable usually aren't listed in .config at all,
so I end up using another config tool to enable them.
E.g., a sound driver when SOUND is completely disabled.
--
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
