On Mon, 2007-02-05 at 08:32 -0800, Linus Torvalds wrote:
It may not shock you to find that I repeat it because I disagree.
For the benefit of some, that's useful. Others still want to be able to
turn off entire subsystems when they don't compile or when they want to
quickly build a minimal kernel. It's become very hard to do that though.
I agree that the tools should let them do that easily. It doesn't
necessarily follow that we should use 'select' for that purpose.
This I agree with. And it's something which the _tools_ have been
capable of for a long time. You don't need 'select'.
The problem is that the widespread and inconsistent use of 'select' for
Aunt Tillie's benefit causes problems for a _different_ set of people.
To use Ingo's example -- if I want to turn off CONFIG_I2C because it
doesn't build or I want it modular to hack on it, I want to be able to
just _do_ that.
I don't want to find that it's forced to 'Y' because I also happen to be
building support for some esoteric peripheral that I've never heard of.
I want that that peripheral to be turned _off_ when I turn I2C off. I
don't want to have to spend hours grepping _all_ over the tree to find
out what's forcing I2C on again. When it was just dependencies, it was
easy enough to find -- it was right there in the Kconfig file in one
place. Now it's a lot harder.
And I'm sure you aren't seriously suggesting that we should take it all
the way and that, for example, all SCSI host drivers should 'select
SCSI' rather than merely depending on SCSI? If I configure a kernel I
don't _want_ to be asked individually about every leaf option -- I want
to be able to turn stuff off in an orderly fashion; in a tree as Ingo
suggests.
--
dwmw2
-
