Messages in this thread |  | | Date | Sun, 20 May 2001 23:33:34 -0400 (EDT) | From | Nicolas Pitre <> | Subject | Re: Background to the argument about CML2 design philosophy |
| |
On Sun, 20 May 2001, Eric S. Raymond wrote:
> 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.
Simple: That extreme perversion represent a kernel that wouldn't compile. You can't have NFS support if you didn't select networking support, etc. Such is the recognized basics.
Next, you can ask the question if you would have to modify the ruleset to add a new driver to be able to use a feature. Exemple: will you need to write a new driver for a special IDE interface card and add it in the ruleset before you could use IDE cdrom support on the MVME147 SBC? If you have to edit it anyway then it shouldn't be much pain to remove the unconditionnal removal of IDE support for that target.
For all other combinations where a slight possibility might make you doubt then the choice should remain at least in expert mode.
People might also want to remove support for subsystems on a specific target even if the device comes soldered on it, just because they won't use it anyway and they want to optimize their kernel size for better memory usage.
IMHO your design goal now is mainly about finding a way to describe rule derivation related to the selected expertise mode, and only enforce the strictly impossible combinations for expert mode, just like CML1 is doing while removing obvious derivations for novice users.
Now you protest with:
> That pushes the third button. 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.
Eric: with this I think you know what everybody here is wishing for, and you just perfectly stated your design constraint in achieving it. You can't avoid the "all semi-possible combination allowed" mode. So let's switch to the implementation discussion instead.
Nicolas
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |