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
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'm missing
> 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
>
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
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
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
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
[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
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
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
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, 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's
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
source
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
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
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
20 matches
Mail list logo
