[lkml]   [2001]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Background to the argument about CML2 design philosophy
Date said:
> I'm nervous that if we go down this path we will end up with a
> thicket of modes and a combinatorial explosion in ruleset complexity,
> leading immediately to a user configuration experience that is more
> complex than necessary, and eventually to an unmaintainable mess in
> the rulesfiles.

Having too many such modes would be a horrible mess, I agree.

> In order to prevent that happening, I would like to have some
> recognized criterion for configuration cases that are so perverse that
> it is a net loss to accept the additional complexity of handling them
> within the configurator.

> A lot of people (including, apparently, you) are saying there are no
> such cases. I wonder if you'll change your minds when you have to
> handle the overhead yourselves?

Of course there are such cases. The criterion is that the code does not
compile or if it did, it could never be expected to work - like SCSI drivers
without SCSI generic, or PCI devices without CONFIG_PCI.

This is the major criterion which has defined the dependencies already in
the config files.

You want to add a new mode which hides some of the more esoteric options.
That's fine. So do so, and then we have two modes. It's still not an
unmaintainable mess.

If having even two modes is going to be too troublesome, then keep the one
we have. You can try to simplify it later by encouraging individual
maintainers to hide stuff behind CONFIG_*_ADVANCED options. But keep that
strictly separate from the CML2 discussion.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [W:0.141 / U:4.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site