* James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
you are handling it well then :) I tend to be amongst the first ones to
notice select trouble (randconfig is quite sensitive to it) and by far
the leading area of failure "in practice" is video drivers and sound
modules. Networking is an occasional blip on the radar (but that's
really just due to its sheer natural size and complexity) and i dont
remember any deep SCSI trouble there ever.
pie-in-the-sky: a fundamentally simpler Kconfig space would be nice,
with strict hierarchies and where enabling a lower component
automatically selects all the upper components as well. The Kconfig
language should detect loops in hierarchies. (it already does so in a
number of situations)
i.e. we should only describe what depends on what - and the rest would
be figured out automatically. In that sense "select" should be a _user
action_ that would never pop up in the language at all - and the
"selection" would all trickle through automatically via the 'depends on'
links without having to mention it in the Kconfig language.
whenever due to a selection that a user made something becomes
unavailable, the kconfig tool/GUI should warn about that with an extra
confirmation step. I.e. it should all really be analogous to normal
user-space package management which has its own dependency resolution
process.
Ingo
--
