[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
On 20 May 2001 16:47:00 -0400, 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.
> 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?

I feel that there should *never ever* be a legit situation that the
configuration tool does not allow. Not ever. Two reasons:

First, I tend to trust the config tools (perhaps too much). If they
tell me x implies y, or x implies not y, I will believe it. I won't
think "hm, the code must be wrong, let me hand edit the config" (which
is something I don't want to have to do, anyhow).

Second, I like having a lean kernel. Here is an example (I realize this
probably won't ever manifest into a real rule): INTEL_I815 implies
INTEL_RNG, DRM_I810, INTEL_AGP, I810_TCO, PCI, etc etc. -- I don't want
the RNG or TCO watchdog. I don't use the on-board graphics. Nor, if my
i815 model supported it, the sound. There are people who want to
customize their kernel (hell, everyone at this level of the game).
There are people, like David, who have custom setups. We need to
support this, without hacking the config (especially if I have to rehack
it after every make oldconfig!).

I like your design to abstract away low levels features to a more
general design. This makes it easier for the novice, and more intuitive
for everyone. But not at the expense of limiting possible cases.

Robert M. Love

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.115 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site