Eric> John Stoffel <firstname.lastname@example.org>:
>> Which is a real PITA because now I have to edit my .config file to
Eric> The correct fix for this PITA is for Linus not to ship a broken
While I can sympathize with this comment, I still feel that CML2 needs
to be more robust and handle corner cases like this more gracefully.
Eric> I hear you. The problem is that "what's wrong" is not as
Eric> well-defined as one might like. In this case the error could be
Eric> in the setting of X86, SMP, or RTC. CML2 has no way to know
Eric> which of these is mis-set, so it can't know which one to pop
It should then highlight *all* of the potential problem config
setting(s) and let the user deal. But they should never be forced to
hand edit their config file because a dependency is broken somewhere.
CML2 should enforce the *writing* of compliant files, but should deal
gracefully with non-compliant ones. Within reason of course.
Eric> USB and SCSI are both enabled/disabled in the system buses menu.
Eric> The apparent confusion
Then they should be pushed down a level to be under those buses. They
don't belong on the top level.
More correctly, *any* configuration setting on an upper level should
not depend on a lower level setting. I know, this is probably not
possible for a variety of reasons, but I feel pretty strongly that we
should try to keep common options near/next to each other.
I can see where this would be a problem, using just SCSI as an
example, since you could have ISA, PCI or some other system bus SCSI
controller(s) on the system. So where do you allow users to choose
whether to enable SCSI or not? At the top level? Only under the
"System Busses" menu item?
On the other hand, I really do like the search feature for config
stuff, it seems pretty powerful.
John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
email@example.com - http://www.lucent.com - 978-952-7548
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 30 2001 - 21:00:25 EST