[EMAIL PROTECTED] 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.
--
dwmw2
-
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/
