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
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 options that
are not used anyw
10 matches
Mail list logo