On Mon, 12 Mar 2001, Keith Owens wrote:
> On Mon, 12 Mar 2001 03:53:07 -0500,
> "Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> >But if we're going to push Linus and the kernel crew to switch to
> >CML2, then why invite the political tsuris of trying to get a large
> >patch into 2.4 now? Maybe I'
> The derived config variables should be in a separate name space,
> whether config is CML1 or CML2. This patch does it for CML1.
Why ?
The only tool that needs to seperate them is the config check script and that
has enough information to deduce them
-
To unsubscribe from this list: send the
> Not only do I think that CONFIG_xxx_DERIVED needlessly extends the name
> of derived vars, but your patch does not belong in a stable series.
> Derived CONFIG_xxx vars are likely to be referenced in source. Changing
> those vars in the middle of a stable series pointlessly breaks external
> so
On Mon, 12 Mar 2001, Keith Owens wrote:
> In 2.4.2-ac18 there are 130 CONFIG options that are always derived from
> other options, the user has no control over them. It is useful for the
> kernel build process to know which variables are derived and which
> variables the user can control.
If it'
On Mon, Mar 12, 2001 at 06:03:22PM +1100, Keith Owens wrote:
> In 2.4.2-ac18 there are 130 CONFIG options that are always derived from
> other options, the user has no control over them. It is useful for the
> kernel build process to know which variables are derived and which
> variables the user
On Mon, 12 Mar 2001 03:53:07 -0500,
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
>But if we're going to push Linus and the kernel crew to switch to
>CML2, then why invite the political tsuris of trying to get a large
>patch into 2.4 now? Maybe I'm missing something here, but this doesn't
>seem n
Peter Samuelson <[EMAIL PROTECTED]>:
> > In 2.4.2-ac18 there are 130 CONFIG options that are always derived
> > from other options, the user has no control over them.
>
> I've thought about these before ... but never got around to doing
> anything about them. I agree they should have a separate
[kaos]
> In 2.4.2-ac18 there are 130 CONFIG options that are always derived
> from other options, the user has no control over them.
I've thought about these before ... but never got around to doing
anything about them. I agree they should have a separate namespace.
However, I would vote the f
Keith Owens wrote:
>
> In 2.4.2-ac18 there are 130 CONFIG options that are always derived from
> other options, the user has no control over them. It is useful for the
> kernel build process to know which variables are derived and which
> variables the user can control. There are also 6 CONFIG
9 matches
Mail list logo
