[lkml]   [2001]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Background to the argument about CML2 design philosophy
Date said:
> Having now briefly looked at the language constructs first-hand, I
> can see two ways to go about this:

> 1) Have a HACKER symbol which unsuppresses the "unusual" options, and
> suppresses the "generalised" ones

> 2) Have a HACKERS submenu system which contains all the derivations
> that could *possibly* be un-defaulted, and allow our intrepid hacker
> to explicitly force each to a value or leave unset.

I prefer the former, which is how it's already implemented in CML1.

But the discussion of this is entirely unrelated to the discussion of CML2,
and changes along these lines must not be forced into the kernel with the
CML2 patch.

If ESR is going to sneak policy changes into the kernel with the CML2
mechanism patch, I'm sure we all have patches we'd like him to add to it
too, because we don't want to have to justify them on their own. :)


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