Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Jochen Striepe]

Hi,

On 12 Apr 2001, Steven Cole <[EMAIL PROTECTED]> wrote:
> 
> Excuse me, but this seems to be something of a red herring.  I've got
> a crowd of Pentium-90 and 100 machines at work, and they get new kernels
> occasionally, but I haven't built a kernel using that class of machine
> in 5 years or so.  I build new kernels using a dual 733 PIII.  Just for
> "fun", I built a kernel using a uniprocessor 266 PII a few months ago, but
> I have much better things to do with my time.

I have an AMD K6/2-400. But I do know _many_ people who do own slower
Hardware, and run Linux on it. They do not want and cannot afford to buy
the newest shiny box. And, they have better things to do with their time
as well. Please note, I live in a country where people are not _poor_.
Just think of others some time, not only of yourself. 


So long,

Jochen Striepe.

-- 
"He was so narrow minded he could see through a keyhole with both
eyes ..."


 PGP signature

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Steven Cole]

On Thursday 12 April 2001 10:51, Horst von Brand wrote:
> Steven Cole <[EMAIL PROTECTED]> said:
>
> [...]
>
> > It would seem to me that if someone is using an older and slower machine
> > to build a kernel, they are probably doing this somewhat infrequently,
> > and the longer build process, although more painful for those few users,
> > should be endurable if it is indeed infrequent.
>
> Please stop a moment and _think_.
>
> There are people out there that have got a P/90 or less, or just a Sun IPX,
> no network access (or slow phone lines at high prices). That _you_ have a
> dual P3/733 doesn't help them one bit, now does it.

Actually, I did think, and then thought a little more.  Here is a snippet
of what I posted earlier:

>Upon further reflection, the added several second stall will probably be
>a thorn in many people's sides, as it comes while the user is impatiently
>waiting for it to launch.  I don't use StarOffice because it takes 12-15
>seconds to start up and that just seems too long.
>
>So any efforts to reduce the stall will probably have a leveraged
>effect which is much greater than might otherwise seem at first glance.

Sorry, I guess its all too easy to get spoiled quickly with new hardware.
And I'm one of those with slow phone lines.

Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Horst von Brand]

Steven Cole <[EMAIL PROTECTED]> said:

[...]

> It would seem to me that if someone is using an older and slower machine
> to build a kernel, they are probably doing this somewhat infrequently,
> and the longer build process, although more painful for those few users,
> should be endurable if it is indeed infrequent.

Please stop a moment and _think_.

There are people out there that have got a P/90 or less, or just a Sun IPX,
no network access (or slow phone lines at high prices). That _you_ have a
dual P3/733 doesn't help them one bit, now does it.
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Dave Jones]

On Thu, 12 Apr 2001, Steven Cole wrote:

> Excuse me, but this seems to be something of a red herring.
> ...
>  Adding seconds or tens of seconds at this time on 2001 hardware will
> seem very moot by the time 2.5/2.6 is at the point 2.4.x is now.

Adding tens of seconds per build is not acceptable when you're building
a lot of kernels each day.

The beginning of this thread showed a 15 second stall on an Athlon 800,
vs a 1 second startup for the old system. The point now is that
Eric _is_ working on improving the performance. (Which was probably
in another post you missed).

> If you haven't seen my posts here before, I just joined this list last night.

Find a list archive, read the beginning of the thread.

regards,

Dave.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Steven Cole]

On Thursday 12 April 2001 06:07, Dave Jones wrote:
> On Wed, 11 Apr 2001 [EMAIL PROTECTED] wrote:
> > Unfortunately, I'm fairly sure that finishing gcml would take long
> > enough to render the point moot, because by the time it was done the
> > average Linux machine would have sped up enough for the Python
> > implementation not to be laggy anymore :-).
>
> 'Average' Linux machine is irrelevant. I still have a Sparc IPX
> I occasionally use. I know people using still using 486's as they
> can't afford anything better. Hell, even some of my P5 class machines
> are starting to show their age, but they're still in daily use.
> To say "Screw them, upgrade" is not an option IMO.

Excuse me, but this seems to be something of a red herring.  I've got
a crowd of Pentium-90 and 100 machines at work, and they get new kernels
occasionally, but I haven't built a kernel using that class of machine
in 5 years or so.  I build new kernels using a dual 733 PIII.  Just for
"fun", I built a kernel using a uniprocessor 266 PII a few months ago, but
I have much better things to do with my time.

It would seem to me that if someone is using an older and slower machine
to build a kernel, they are probably doing this somewhat infrequently,
and the longer build process, although more painful for those few users,
should be endurable if it is indeed infrequent.

Keep in mind that making a kernel on a current machine has gone from 
a couple of hours (1992) to two minutes (2001).  Adding seconds or tens 
of seconds at this time on 2001 hardware will seem very moot by the 
time 2.5/2.6 is at the point 2.4.x is now.

If you haven't seen my posts here before, I just joined this list last night.

Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Dave Jones]

On Wed, 11 Apr 2001 [EMAIL PROTECTED] wrote:

> Unfortunately, I'm fairly sure that finishing gcml would take long
> enough to render the point moot, because by the time it was done the
> average Linux machine would have sped up enough for the Python
> implementation not to be laggy anymore :-).

'Average' Linux machine is irrelevant. I still have a Sparc IPX
I occasionally use. I know people using still using 486's as they
can't afford anything better. Hell, even some of my P5 class machines
are starting to show their age, but they're still in daily use.
To say "Screw them, upgrade" is not an option IMO.

> I'm pretty sure that tuning the Python implementation (coming up with
> faster algorithms, perhaps by reorganizing the data structures to do
> more precomputation) will be a more effective use of my time.

Well if you can make this run faster, this would kill my main
complaint with CML2.  I'll try out an updated version sometime.

regards,

Davej.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[esr]

Albert D. Cahalan <[EMAIL PROTECTED]>:
> > * All three interfaces do progressive disclosure -- the user only sees
> >   questions he/she needs to answer (no more hundreds of greyed-out menu
> >   entries for irrelevant drivers!).
> 
> Well, that sucks. The greyed-out menu entries were the only good
> thing about xconfig. Such entries provide a clue that you need
> to enable something else to get the feature you desire. Otherwise
> you might figure that the feature is missing, or that you have
> overlooked it.

You can have this back if you want by clicking the "Unsuppress" item in
one of the pulldowns.

But since the theorem prover automatically turns on such prerequisites for
you, you're very unlikely to need it.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

The kind of charity you can force out of people nourishes about as much as
the kind of love you can buy --- and spreads even nastier diseases.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Alan Cox]

> But, as a separate issue, the CML2 design *could* be reworked to support
> a multiple-apex tree, if there were any advantage to doing so.  I don't
> see one.  Do you?

Enough to justify the work - no
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Jamie Lokier]

Albert D. Cahalan wrote:
> > * All three interfaces do progressive disclosure -- the user only sees
> >   questions he/she needs to answer (no more hundreds of greyed-out menu
> >   entries for irrelevant drivers!).
> 
> Well, that sucks. The greyed-out menu entries were the only good
> thing about xconfig. Such entries provide a clue that you need
> to enable something else to get the feature you desire. Otherwise
> you might figure that the feature is missing, or that you have
> overlooked it.

I agree.  I use menuconfig and it's pretty good, but sometimes I miss
the ability to go through all the available options and decide, one by
one, whether I want to enable the option.

Of course if I do not enable some PCI NIC driver, I do not need to see
special options for that driver.  That's good.  On the other hand, if I
am looking to enable RED, I won't realise that I need to enable
traffic shaping first to discover the RED option.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Giacomo Catenazzi]

"Albert D. Cahalan" wrote:
> 
> > * All three interfaces do progressive disclosure -- the user only sees
> >   questions he/she needs to answer (no more hundreds of greyed-out menu
> >   entries for irrelevant drivers!).
> 
> Well, that sucks. The greyed-out menu entries were the only good
> thing about xconfig.

You are one of the few people that use xconfig... Thus xconfig
is not
so worse as people tell me.

> Such entries provide a clue that you need
> to enable something else to get the feature you desire. Otherwise
> you might figure that the feature is missing, or that you have
> overlooked it.

There is an option (check the menu) to show all entries
(grayed)
and now there is also in make menuconfig this option ('S'
command)

On my extensive test, now all the features of the older tools
are
included. But the important feature to read the old .config
file, but
this feature will be included in the next version (check the
previous
esr's mails)


giacomo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Albert D. Cahalan]

> * All three interfaces do progressive disclosure -- the user only sees
>   questions he/she needs to answer (no more hundreds of greyed-out menu
>   entries for irrelevant drivers!).

Well, that sucks. The greyed-out menu entries were the only good
thing about xconfig. Such entries provide a clue that you need
to enable something else to get the feature you desire. Otherwise
you might figure that the feature is missing, or that you have
overlooked it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Albert D. Cahalan]

 * All three interfaces do progressive disclosure -- the user only sees
   questions he/she needs to answer (no more hundreds of greyed-out menu
   entries for irrelevant drivers!).

Well, that sucks. The greyed-out menu entries were the only good
thing about xconfig. Such entries provide a clue that you need
to enable something else to get the feature you desire. Otherwise
you might figure that the feature is missing, or that you have
overlooked it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Giacomo Catenazzi]

"Albert D. Cahalan" wrote:
 
  * All three interfaces do progressive disclosure -- the user only sees
questions he/she needs to answer (no more hundreds of greyed-out menu
entries for irrelevant drivers!).
 
 Well, that sucks. The greyed-out menu entries were the only good
 thing about xconfig.

You are one of the few people that use xconfig... Thus xconfig
is not
so worse as people tell me.

 Such entries provide a clue that you need
 to enable something else to get the feature you desire. Otherwise
 you might figure that the feature is missing, or that you have
 overlooked it.

There is an option (check the menu) to show all entries
(grayed)
and now there is also in make menuconfig this option ('S'
command)

On my extensive test, now all the features of the older tools
are
included. But the important feature to read the old .config
file, but
this feature will be included in the next version (check the
previous
esr's mails)


giacomo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Jamie Lokier]

Albert D. Cahalan wrote:
  * All three interfaces do progressive disclosure -- the user only sees
questions he/she needs to answer (no more hundreds of greyed-out menu
entries for irrelevant drivers!).
 
 Well, that sucks. The greyed-out menu entries were the only good
 thing about xconfig. Such entries provide a clue that you need
 to enable something else to get the feature you desire. Otherwise
 you might figure that the feature is missing, or that you have
 overlooked it.

I agree.  I use menuconfig and it's pretty good, but sometimes I miss
the ability to go through all the available options and decide, one by
one, whether I want to enable the option.

Of course if I do not enable some PCI NIC driver, I do not need to see
special options for that driver.  That's good.  On the other hand, if I
am looking to enable RED, I won't realise that I need to enable
traffic shaping first to discover the RED option.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Alan Cox]

 But, as a separate issue, the CML2 design *could* be reworked to support
 a multiple-apex tree, if there were any advantage to doing so.  I don't
 see one.  Do you?

Enough to justify the work - no
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[esr]

Albert D. Cahalan [EMAIL PROTECTED]:
  * All three interfaces do progressive disclosure -- the user only sees
questions he/she needs to answer (no more hundreds of greyed-out menu
entries for irrelevant drivers!).
 
 Well, that sucks. The greyed-out menu entries were the only good
 thing about xconfig. Such entries provide a clue that you need
 to enable something else to get the feature you desire. Otherwise
 you might figure that the feature is missing, or that you have
 overlooked it.

You can have this back if you want by clicking the "Unsuppress" item in
one of the pulldowns.

But since the theorem prover automatically turns on such prerequisites for
you, you're very unlikely to need it.
-- 
a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a

The kind of charity you can force out of people nourishes about as much as
the kind of love you can buy --- and spreads even nastier diseases.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Dave Jones]

On Wed, 11 Apr 2001 [EMAIL PROTECTED] wrote:

 Unfortunately, I'm fairly sure that finishing gcml would take long
 enough to render the point moot, because by the time it was done the
 average Linux machine would have sped up enough for the Python
 implementation not to be laggy anymore :-).

'Average' Linux machine is irrelevant. I still have a Sparc IPX
I occasionally use. I know people using still using 486's as they
can't afford anything better. Hell, even some of my P5 class machines
are starting to show their age, but they're still in daily use.
To say "Screw them, upgrade" is not an option IMO.

 I'm pretty sure that tuning the Python implementation (coming up with
 faster algorithms, perhaps by reorganizing the data structures to do
 more precomputation) will be a more effective use of my time.

Well if you can make this run faster, this would kill my main
complaint with CML2.  I'll try out an updated version sometime.

regards,

Davej.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Steven Cole]

On Thursday 12 April 2001 06:07, Dave Jones wrote:
 On Wed, 11 Apr 2001 [EMAIL PROTECTED] wrote:
  Unfortunately, I'm fairly sure that finishing gcml would take long
  enough to render the point moot, because by the time it was done the
  average Linux machine would have sped up enough for the Python
  implementation not to be laggy anymore :-).

 'Average' Linux machine is irrelevant. I still have a Sparc IPX
 I occasionally use. I know people using still using 486's as they
 can't afford anything better. Hell, even some of my P5 class machines
 are starting to show their age, but they're still in daily use.
 To say "Screw them, upgrade" is not an option IMO.

Excuse me, but this seems to be something of a red herring.  I've got
a crowd of Pentium-90 and 100 machines at work, and they get new kernels
occasionally, but I haven't built a kernel using that class of machine
in 5 years or so.  I build new kernels using a dual 733 PIII.  Just for
"fun", I built a kernel using a uniprocessor 266 PII a few months ago, but
I have much better things to do with my time.

It would seem to me that if someone is using an older and slower machine
to build a kernel, they are probably doing this somewhat infrequently,
and the longer build process, although more painful for those few users,
should be endurable if it is indeed infrequent.

Keep in mind that making a kernel on a current machine has gone from 
a couple of hours (1992) to two minutes (2001).  Adding seconds or tens 
of seconds at this time on 2001 hardware will seem very moot by the 
time 2.5/2.6 is at the point 2.4.x is now.

If you haven't seen my posts here before, I just joined this list last night.

Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Dave Jones]

On Thu, 12 Apr 2001, Steven Cole wrote:

 Excuse me, but this seems to be something of a red herring.
 ...
  Adding seconds or tens of seconds at this time on 2001 hardware will
 seem very moot by the time 2.5/2.6 is at the point 2.4.x is now.

Adding tens of seconds per build is not acceptable when you're building
a lot of kernels each day.

The beginning of this thread showed a 15 second stall on an Athlon 800,
vs a 1 second startup for the old system. The point now is that
Eric _is_ working on improving the performance. (Which was probably
in another post you missed).

 If you haven't seen my posts here before, I just joined this list last night.

Find a list archive, read the beginning of the thread.

regards,

Dave.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Horst von Brand]

Steven Cole [EMAIL PROTECTED] said:

[...]

 It would seem to me that if someone is using an older and slower machine
 to build a kernel, they are probably doing this somewhat infrequently,
 and the longer build process, although more painful for those few users,
 should be endurable if it is indeed infrequent.

Please stop a moment and _think_.

There are people out there that have got a P/90 or less, or just a Sun IPX,
no network access (or slow phone lines at high prices). That _you_ have a
dual P3/733 doesn't help them one bit, now does it.
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Steven Cole]

On Thursday 12 April 2001 10:51, Horst von Brand wrote:
 Steven Cole [EMAIL PROTECTED] said:

 [...]

  It would seem to me that if someone is using an older and slower machine
  to build a kernel, they are probably doing this somewhat infrequently,
  and the longer build process, although more painful for those few users,
  should be endurable if it is indeed infrequent.

 Please stop a moment and _think_.

 There are people out there that have got a P/90 or less, or just a Sun IPX,
 no network access (or slow phone lines at high prices). That _you_ have a
 dual P3/733 doesn't help them one bit, now does it.

Actually, I did think, and then thought a little more.  Here is a snippet
of what I posted earlier:

Upon further reflection, the added several second stall will probably be
a thorn in many people's sides, as it comes while the user is impatiently
waiting for it to launch.  I don't use StarOffice because it takes 12-15
seconds to start up and that just seems too long.

So any efforts to reduce the stall will probably have a leveraged
effect which is much greater than might otherwise seem at first glance.

Sorry, I guess its all too easy to get spoiled quickly with new hardware.
And I'm one of those with slow phone lines.

Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Jochen Striepe]

Hi,

On 12 Apr 2001, Steven Cole [EMAIL PROTECTED] wrote:
 
 Excuse me, but this seems to be something of a red herring.  I've got
 a crowd of Pentium-90 and 100 machines at work, and they get new kernels
 occasionally, but I haven't built a kernel using that class of machine
 in 5 years or so.  I build new kernels using a dual 733 PIII.  Just for
 "fun", I built a kernel using a uniprocessor 266 PII a few months ago, but
 I have much better things to do with my time.

I have an AMD K6/2-400. But I do know _many_ people who do own slower
Hardware, and run Linux on it. They do not want and cannot afford to buy
the newest shiny box. And, they have better things to do with their time
as well. Please note, I live in a country where people are not _poor_.
Just think of others some time, not only of yourself. 


So long,

Jochen Striepe.

-- 
"He was so narrow minded he could see through a keyhole with both
eyes ..."


 PGP signature

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[esr]

Aaron Lehmann <[EMAIL PROTECTED]>:
> Maybe you could kill two birds with one stone by calling 1.0.0 the
> prototype and rewriting it in C.

If I were to become absolutely convinced that I can't get acceptable speed
out of Python, I might do that.  There's a gcml project that tracked the CML2
compiler up to about 0.72 level that might make a decent starting point.

Unfortunately, I'm fairly sure that finishing gcml would take long
enough to render the point moot, because by the time it was done the
average Linux machine would have sped up enough for the Python
implementation not to be laggy anymore :-).

No joke -- *you* try writing a theorem-prover in a language with only
fixed-extent data types.  Go on.  Try it.  I think you will (as Mark
Twain put it about the consequences of teasing a cat) acquire a
valuable education, the facts of which will never grow dim or
doubtful.

I'm pretty sure that tuning the Python implementation (coming up with
faster algorithms, perhaps by reorganizing the data structures to do
more precomputation) will be a more effective use of my time.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

"One of the ordinary modes, by which tyrants accomplish their purposes
without resistance, is, by disarming the people, and making it an
offense to keep arms."
-- Constitutional scholar and Supreme Court Justice Joseph Story, 1840
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Aaron Lehmann]

On Wed, Apr 11, 2001 at 05:46:09PM -0400, [EMAIL PROTECTED] wrote:
> The speed problem now is in the configurator itself.
> One of my post-1.0.0 challenges is to profile and tune the configurator
> code to within an inch of its life.

Maybe you could kill two birds with one stone by calling 1.0.0 the
prototype and rewriting it in C. Not only would this improve speed
(algorithmic improvements would also be welcome...), but it would
remove the pythonic obstacle to its adoption as a standard. Many,
including me, oppose writing the standard configurator in Python. I
don't have Python installed and I'm not going to install yet another
scripting language just because ESR likes it. Yes, we know about
freeze support, but aren't convinced that it will do well at this. It
seems that a native C configurator will be both faster and more
portable (accross distributions and mindsets) than something requiring
a recent version of SuperEasyInterpretedProgrammingLanguage 2.0.

I know that you're reluctant to make the port, but you don't need to
be too shy to ask for help. Few people on this list are afraid of C.
If you're too lazy to implement CML2 in a standard, popular, robust
language, heck, tell us, and we may be able to help you out.

Sorry for the anti-Python flamage. I'm sure that it has its uses. I,
however, don't view it as appropriate for configuration of an integral
component of a GNU/Linux system. I want to make the view clear to aid
Linus with his descision and to encourage a C port of CML2, which
languages aside looks like a good format and concept BTW.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[esr]

Jeff Garzik <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote:
> > But, as a separate issue, the CML2 design *could* be reworked to support
> > a multiple-apex tree, if there were any advantage to doing so.  I don't
> > see one.  Do you?
> 
> Yes, because the current system is directed not by a central file, but
> by an architecture-specific config.in.  Compartmentalized Config.in
> files are easy to include and even easier to exclude selectively.  It's
> pretty pointless for S/390 arch to parse a ton of driver config entries
> it will never present to the user; that wastes memory and slows down the
> configuration system.

The low-level answer is that the configurator doesn't pay the
parse-time cost; the CML2 compiler does all that and presents the
configurator with a rulebase object that is not large enough for the
incremental I/O or memory cost of the "useless" information to be
significant.  (I'm not handwaving here, I've actually profiled this;
the rulebase object for 2.4.3 is only 342K on disk and less than that
in core.)

BTW, CML2 only has a "central file" in a rather trivial sense.  Here's
what the code to include the port-specific rules looks like:

source "arch/i386/rules.cml"
source "arch/alpha/rules.cml"
source "arch/sparc/rules.cml"
source "arch/mips/rules.cml"
source "arch/ppc/rules.cml"
source "arch/m68k/rules.cml"
source "arch/arm/rules.cml"
source "arch/sh/rules.cml"
source "arch/ia64/rules.cml"
source "arch/parisc/rules.cml"
source "arch/s390/rules.cml"
source "arch/cris/rules.cml"

The real issue isn't that they're "centralized", it's that they're 
siblings under a top-level architecture menu (which most users won't
see because normal invocations of the configurator supply that answer
from the command line, just as in CML1).  Which brings me neatly 
to my next point...

The higher-level answer is that you're confusing an implementation
issue with a design issue.  Beware of such premature optimization, for
as the hierophant Knuth hath revealed unto us, it is the root of all
evil.  To persuade me to go back to a multiple-apex tree you'd have to
show that there is a *design* or complexity-control advantage to
compartmentalizing the configuration information in that way.  Maybe
there is one, but nobody's shown it to me yet.

(In truth I don't dismiss implementation concerns quite as cavalierly
as it might sound from the above.  But buying a linear speedup wouldn't
be good enough to make me change the design.  A quadratic speedup might
be, but none of CML2's algorithms are quadratic in the number of symbols
in the rulebase.)
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

The men and women who founded our country knew, by experience, that there
are times when the free person's answer to oppressive government has to be
delivered with a bullet.  Thus, the right to bear arms is not just *a*
freedom; it's the mother of all freedoms.  Don't let them disarm you!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[esr]

Alan Cox <[EMAIL PROTECTED]>:
> Ok I see where you are going with that argument. However when you parse all
> the existing Config.in files into a tree you can see those properties by 
> looking from any node back to its dependancies

Granted.  If, that is, the representation you generate supports that kind
of backtracking.  This turns out to be very hard if you're starting from
an imperative representation rather than a declarative one.  

But, as a separate issue, the CML2 design *could* be reworked to support
a multiple-apex tree, if there were any advantage to doing so.  I don't
see one.  Do you?
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

Good intentions will always be pleaded for every assumption of
authority. It is hardly too strong to say that the Constitution was
made to guard the people against the dangers of good intentions. There
are men in all ages who mean to govern well, but they mean to
govern. They promise to be good masters, but they mean to be masters.
-- Daniel Webster
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[esr]

Alan Cox <[EMAIL PROTECTED]>:
> CML2 seems to have two other problems in my mind. Inability to parse
> the existing config files.

I gave upon that early for two reasons.  One was practical; Michael tried this
with mconfig, and (apparently) failed.  Or, at least, appeared to have decided
that path was not worth pursuing.

The other was the procedural vs. declarative problem.  I spent about a
month after the kbuild team originally encouraged me to tackle the
problem working on a design which I later labeled Thesis.  This was an
attempt to build a cleaned-up CML1, basically the existing language
without the syntactic warts.  I got as far as spinning up an
incomplete implementation that could check toy configurations.

But the design basically didn't work.  The problem is that a
procedural language imposes a kind of time order that makes it very
difficult to (a) do backtracking and (b) prove the correctness of your
result.  Perhaps a clearer way to put it is that configuration (like, say,
screen widget layout) is fundamentally a constraint problem rather
than a control problem.

A constraint problem needs a declarative rather than imperative
language, and it needs a baby reasoning engine to generate a
constraint-satisfying solution (Tk approaches screen-widget layout
this way; that's thye source of its power).  Neither of my strawman
designs had significant advantage over CML1 until I bit the bullet and
wrote a theorem prover to reason about timeless constraints.

>Also the draw ordering in the menu based
> config doesnt appear right. Menuconfig has a rather undocumented but
> very important property of doing roughly the right thing with
> screenreaders. Something to bear in mind when fixing the menu
> redrawing stuff.

Yes, I have plans for this.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

Militias, when properly formed, are in fact the people themselves and
include all men capable of bearing arms. [...] To preserve liberty it is
essential that the whole body of the people always possess arms and be
taught alike, especially when young, how to use them.
-- Senator Richard Henry Lee, 1788, on "militia" in the 2nd Amendment
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Alan Cox]

> A multiple-apex tree also tends to pull the configuration questions downwards
> from policy (e.g "Parallel-port support?") towards hardware-specific,
> platform-specific questions ("Atari parallel-port hardware?")  By designing
> the configuration rules for CML2 as a single-apex tree, I'm trying to
> move the questions upwards and have derivations in the rules file handle
> distributing that information to a lower level.

Ok I see where you are going with that argument. However when you parse all
the existing Config.in files into a tree you can see those properties by 
looking from any node back to its dependancies

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Alan Cox]

> PARPORT   'Parallel port support'
> derive PARPORT_PC from PARPORT and X86

PARPORT_PC is found on almost all architectures btw. Its also implied by PCI
bus ISA bus and random silicon all over the place




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[esr]

Alan Cox <[EMAIL PROTECTED]>:
> Multiple layers of Config.in is a feature

I disagree, because I've seen what happens when we go to a single-apex tree.
But you could persuade me otherwise.  What's your reason for believing this?

The problem with having multiple apices of the configuration tree (as I see
it) is that we often ended up duplicating configuration code for things that
aren't actually port-dependent but rather depend on other things such as
supported bus types (ISA, PCA, PCMCIA, etc.).  This is a particularly big
issue with network cards and disk controllers.

The duplicated code then starts to skew.  You end up with lots of features
(especially drivers) that could be supported across architectures but aren't,
simply because port maintainers are focused on their own trees and don't look
at what's going on in the others.

A multiple-apex tree also tends to pull the configuration questions downwards
from policy (e.g "Parallel-port support?") towards hardware-specific,
platform-specific questions ("Atari parallel-port hardware?")  By designing
the configuration rules for CML2 as a single-apex tree, I'm trying to
move the questions upwards and have derivations in the rules file handle
distributing that information to a lower level.

For example, instead of a bunch of parallel questions like this in a 
multiple-apex tree:

PARPORT 'Parallel port support'
PARPORT_PC  'PC-style hardware'
PARPORT_PC_PCMCIA   'Support for PCMCIA management for PC-style ports'
PARPORT_ARC 'Archimedes hardware'
PARPORT_AMIGA   'Amiga builtin port'
PARPORT_MFC3'Multiface III parallel port'
PARPORT_ATARI   'Atari hardware'
PARPORT_SUNBPP  'Sparc hardware'

I'm trying to move us towards having *one* question and a bunch of
well-hidden intelligence about what it implies:

PARPORT 'Parallel port support'
derive PARPORT_PC from PARPORT and X86
derive PARPORT_ARC from PARPORT and ARC
derive PARPORT_AMIGA from PARPORT and AMIGA
derive PARPORT_SUNBPP from PARPORT and SUN
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

Government is actually the worst failure of civilized man. There has
never been a really good one, and even those that are most tolerable
are arbitrary, cruel, grasping and unintelligent.
-- H. L. Mencken 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Alan Cox]

> o it still has multiple top-level config.in.  Again that is easily fixable
>   and in fact I did a patch for it (including {old,menu,x}config support
>   in 2.3 times but never submitted it.

Multiple layers of Config.in is a feature

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[esr]

[EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> One of the first things I noticed was it seems noticably slower
> than CML1. A make menuconfig in CML1 takes me into the menu
> in under a second. (On an already compiled tree).
> CML2 takes around 15 seconds before I get that far.
> This is on an Athlon 800 w/512MB. I dread to think how this
> responds on a 486.

Yes, I know I have some speed-tuning to do.

> Scrolling the cursor bar in menuconfig causes a lot of flickering
> as the entire screen seems to be redrawn. This is becomes unusable
> after a few minutes usage. Scrolling under CML1's menuconfig doesn't
> show this behaviour.

That's odd.  I see no screen flicker at all when I scroll my menu bar.
I wonder what's different about your environment.  You're running under
SuSE, I presume -- perhaps you have an older ncurses version?

> The various colours used to show submenus that have been visited
> seems confusing, and unnecessary. Their meaning also seems undocumented.

I'll document them.  They're intended to help you track what portions
of the configuration you've already done.
 
> Top level menu seems to have gained a few items.
> For example, the `SCSI support' item has disappeared,
> making `SCSI disk support' and `SCSI low-level drivers'
> both appear on the top level menu.

The SCSI support flag is in the buses menu.  You see these two menus because
the defconfig sets it on.
 
> For some reason, the kernel hacking menu doesn't show
> 4/5 of the options that it used to. Instead it replaces
> them with one new one (Disable VHPT). Which it seems to
> picking up from the IA64 tree. Most strange.

Ah.  That's because I didn't have an `unless ia64 suppress DISABLE_VHPT'
I've added that.

A lot of the stuff that used to be under that menu moved to archihacks,
I think.
 
> Finally, quitting the program (q twice) gives me this..
> python2 -O scripts/configtrans.py -h include/linux/autoconf.h -s .config
> config.out
> Traceback (most recent call last):
>   File "scripts/configtrans.py", line 104, in ?
> sys.stderr.write(args[0]);
> TypeError: read-only character buffer, int
> make: *** [menuconfig] Error 1

I can't reproduce this.  Do you get the same behavior under 1.0.3?
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

Such are a well regulated militia, composed of the freeholders,
citizen and husbandman, who take up arms to preserve their property,
as individuals, and their rights as freemen.
-- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" 
referred to in the Second Amendment to the Constitution.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Alan Cox]

> Eric did some performance analysis.  If I recall correctly, all but 1
> or 2 seconds of CML2's runtime is in the parser.  He has rewritten the
> parser once.  Maybe someone needs to rewrite it again, maybe propagate
> some changes into the language spec to make it easier to parse, maybe
> rewrite from Python to C.

CML2 seems to have two other problems in my mind. Inability to parse the
existing config files. Also the draw ordering in the menu based config doesnt
appear right. Menuconfig has a rather undocumented but very important property
of doing roughly the right thing with screenreaders. Something to bear in mind
when fixing the menu redrawing stuff.

Alan



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[esr]

Michael Elizabeth Chastain <[EMAIL PROTECTED]>:
> I like mconfig, but I like CML2 better.

Reminder for the rest of you: Michael *wrote* mconfig.

> My primary reason is that ESR has more time to work on CML2 than I do
> on mconfig.  And speed problems are often the easiest problems to solve.
> 
> Eric did some performance analysis.  If I recall correctly, all but 1
> or 2 seconds of CML2's runtime is in the parser.  He has rewritten the
> parser once.  Maybe someone needs to rewrite it again, maybe propagate
> some changes into the language spec to make it easier to parse, maybe
> rewrite from Python to C.

The *language compiler's* runtime got cut in half when I hand-rolled a
parser for it.  The speed problem now is in the configurator itself.
One of my post-1.0.0 challenges is to profile and tune the configurator
code to within an inch of its life.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

'Faith' means not _wanting_ to know what is true.
-- Nietzsche, Der Antichrist
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Michael Elizabeth Chastain]

I like mconfig, but I like CML2 better.

My primary reason is that ESR has more time to work on CML2 than I do
on mconfig.  And speed problems are often the easiest problems to solve.

Eric did some performance analysis.  If I recall correctly, all but 1
or 2 seconds of CML2's runtime is in the parser.  He has rewritten the
parser once.  Maybe someone needs to rewrite it again, maybe propagate
some changes into the language spec to make it easier to parse, maybe
rewrite from Python to C.

Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Christoph Hellwig]

On Wed, Apr 11, 2001 at 10:16:36PM +0200, Dave Jones wrote:
> On Wed, 11 Apr 2001, Christoph Hellwig wrote:
> 
> > > CML2 takes around 15 seconds before I get that far.
> > > This is on an Athlon 800 w/512MB. I dread to think how this
> > > responds on a 486.
> >
> > If you look for something _even_ faster try mconfig.  For everyone who is
> > interested, I've put my latests half-way stable version is on ftp.  It's at
> >   ftp.openlinux.org:/pub/people/hch/mconfig/mconfig-0.19-pre1.tar.gz
> > Props for all the hard work go to Michael Elizabeth Chastain!
> 
> This is the first I've heard of mconfig. (I don't track the kbuild list)
> Does it solve all the problems that Eric's solution proposes?
> It's certainly fast (CML1 menuconfig speed at least).

Not all (yet).
o It is one programm with multiple frontends:
old,
text,
ncurses,
random,
maximum,
minimum,
syntax checking
(X is still missing as my brain is not made for GUI programming)

o An 'show me all options and handle the rest' mode is still missing -
  my devel tree has something like that in the works, but I'll probably
  never finish it now that CML2 is official.

o it still has multiple top-level config.in.  Again that is easily fixable
  and in fact I did a patch for it (including {old,menu,x}config support
  in 2.3 times but never submitted it.

Something missing?

Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Dave Jones]

On Wed, 11 Apr 2001, Christoph Hellwig wrote:

> > CML2 takes around 15 seconds before I get that far.
> > This is on an Athlon 800 w/512MB. I dread to think how this
> > responds on a 486.
>
> If you look for something _even_ faster try mconfig.  For everyone who is
> interested, I've put my latests half-way stable version is on ftp.  It's at
>   ftp.openlinux.org:/pub/people/hch/mconfig/mconfig-0.19-pre1.tar.gz
> Props for all the hard work go to Michael Elizabeth Chastain!

This is the first I've heard of mconfig. (I don't track the kbuild list)
Does it solve all the problems that Eric's solution proposes?
It's certainly fast (CML1 menuconfig speed at least).

regards,

Dave.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Christoph Hellwig]

In article  you wrote:
> One of the first things I noticed was it seems noticably slower
> than CML1. A make menuconfig in CML1 takes me into the menu
> in under a second. (On an already compiled tree).
> CML2 takes around 15 seconds before I get that far.
> This is on an Athlon 800 w/512MB. I dread to think how this
> responds on a 486.

If you look for something _even_ faster try mconfig.  For everyone who is
interested, I've put my latests half-way stable version is on ftp.  It's at

  ftp.openlinux.org:/pub/people/hch/mconfig/mconfig-0.19-pre1.tar.gz

Props for all the hard work go to Michael Elizabeth Chastain!

Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[davej]

On Tue, 10 Apr 2001, Eric S. Raymond wrote:

> After 11 months of painstaking work and testing, CML2 1.0.0 is ready for use,
> and ready to replace the current kernel-configuration system.  You'll
> find it at .  I've made a transition
> guide available at .

Hi Eric,

 Out of curiosity, I decided to give CML2 a try this evening.
Some feedback:

One of the first things I noticed was it seems noticably slower
than CML1. A make menuconfig in CML1 takes me into the menu
in under a second. (On an already compiled tree).
CML2 takes around 15 seconds before I get that far.
This is on an Athlon 800 w/512MB. I dread to think how this
responds on a 486.

Scrolling the cursor bar in menuconfig causes a lot of flickering
as the entire screen seems to be redrawn. This is becomes unusable
after a few minutes usage. Scrolling under CML1's menuconfig doesn't
show this behaviour.

The various colours used to show submenus that have been visited
seems confusing, and unnecessary. Their meaning also seems undocumented.

Reporting of changing certain features seems to be excessive.
For example, changing CPU target from Pentium Pro to Athlon
tells me that "M686=n (deduced from MK7)"
Another confusing thing on this menu, happens when you select
CRUSOE, and then 386.
"MK7=n (deduced from M386) MCRUSOE=n (deduced from M386)"
Not sure why selecting Crusoe enables MK7.

Top level menu seems to have gained a few items.
For example, the `SCSI support' item has disappeared,
making `SCSI disk support' and `SCSI low-level drivers'
both appear on the top level menu.

For some reason, the kernel hacking menu doesn't show
4/5 of the options that it used to. Instead it replaces
them with one new one (Disable VHPT). Which it seems to
picking up from the IA64 tree. Most strange.

Finally, quitting the program (q twice) gives me this..
python2 -O scripts/configtrans.py -h include/linux/autoconf.h -s .config
config.out
Traceback (most recent call last):
  File "scripts/configtrans.py", line 104, in ?
sys.stderr.write(args[0]);
TypeError: read-only character buffer, int
make: *** [menuconfig] Error 1


All the above was using an 2.4.3-ac4 tree, with CML2-1.0.0

regards,

Dave.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[davej]

On Tue, 10 Apr 2001, Eric S. Raymond wrote:

 After 11 months of painstaking work and testing, CML2 1.0.0 is ready for use,
 and ready to replace the current kernel-configuration system.  You'll
 find it at http://www.tuxedo.org/~esr/cml2/.  I've made a transition
 guide available at http://www.tuxedo.org/~esr/cml2/transition.html.

Hi Eric,

 Out of curiosity, I decided to give CML2 a try this evening.
Some feedback:

One of the first things I noticed was it seems noticably slower
than CML1. A make menuconfig in CML1 takes me into the menu
in under a second. (On an already compiled tree).
CML2 takes around 15 seconds before I get that far.
This is on an Athlon 800 w/512MB. I dread to think how this
responds on a 486.

Scrolling the cursor bar in menuconfig causes a lot of flickering
as the entire screen seems to be redrawn. This is becomes unusable
after a few minutes usage. Scrolling under CML1's menuconfig doesn't
show this behaviour.

The various colours used to show submenus that have been visited
seems confusing, and unnecessary. Their meaning also seems undocumented.

Reporting of changing certain features seems to be excessive.
For example, changing CPU target from Pentium Pro to Athlon
tells me that "M686=n (deduced from MK7)"
Another confusing thing on this menu, happens when you select
CRUSOE, and then 386.
"MK7=n (deduced from M386) MCRUSOE=n (deduced from M386)"
Not sure why selecting Crusoe enables MK7.

Top level menu seems to have gained a few items.
For example, the `SCSI support' item has disappeared,
making `SCSI disk support' and `SCSI low-level drivers'
both appear on the top level menu.

For some reason, the kernel hacking menu doesn't show
4/5 of the options that it used to. Instead it replaces
them with one new one (Disable VHPT). Which it seems to
picking up from the IA64 tree. Most strange.

Finally, quitting the program (q twice) gives me this..
python2 -O scripts/configtrans.py -h include/linux/autoconf.h -s .config
config.out
Traceback (most recent call last):
  File "scripts/configtrans.py", line 104, in ?
sys.stderr.write(args[0]);
TypeError: read-only character buffer, int
make: *** [menuconfig] Error 1


All the above was using an 2.4.3-ac4 tree, with CML2-1.0.0

regards,

Dave.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Christoph Hellwig]

In article Pine.LNX.4.31.0104112013010.25121-10@athlon you wrote:
 One of the first things I noticed was it seems noticably slower
 than CML1. A make menuconfig in CML1 takes me into the menu
 in under a second. (On an already compiled tree).
 CML2 takes around 15 seconds before I get that far.
 This is on an Athlon 800 w/512MB. I dread to think how this
 responds on a 486.

If you look for something _even_ faster try mconfig.  For everyone who is
interested, I've put my latests half-way stable version is on ftp.  It's at

  ftp.openlinux.org:/pub/people/hch/mconfig/mconfig-0.19-pre1.tar.gz

Props for all the hard work go to Michael Elizabeth Chastain!

Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Dave Jones]

On Wed, 11 Apr 2001, Christoph Hellwig wrote:

  CML2 takes around 15 seconds before I get that far.
  This is on an Athlon 800 w/512MB. I dread to think how this
  responds on a 486.

 If you look for something _even_ faster try mconfig.  For everyone who is
 interested, I've put my latests half-way stable version is on ftp.  It's at
   ftp.openlinux.org:/pub/people/hch/mconfig/mconfig-0.19-pre1.tar.gz
 Props for all the hard work go to Michael Elizabeth Chastain!

This is the first I've heard of mconfig. (I don't track the kbuild list)
Does it solve all the problems that Eric's solution proposes?
It's certainly fast (CML1 menuconfig speed at least).

regards,

Dave.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Christoph Hellwig]

On Wed, Apr 11, 2001 at 10:16:36PM +0200, Dave Jones wrote:
 On Wed, 11 Apr 2001, Christoph Hellwig wrote:
 
   CML2 takes around 15 seconds before I get that far.
   This is on an Athlon 800 w/512MB. I dread to think how this
   responds on a 486.
 
  If you look for something _even_ faster try mconfig.  For everyone who is
  interested, I've put my latests half-way stable version is on ftp.  It's at
ftp.openlinux.org:/pub/people/hch/mconfig/mconfig-0.19-pre1.tar.gz
  Props for all the hard work go to Michael Elizabeth Chastain!
 
 This is the first I've heard of mconfig. (I don't track the kbuild list)
 Does it solve all the problems that Eric's solution proposes?
 It's certainly fast (CML1 menuconfig speed at least).

Not all (yet).
o It is one programm with multiple frontends:
old,
text,
ncurses,
random,
maximum,
minimum,
syntax checking
(X is still missing as my brain is not made for GUI programming)

o An 'show me all options and handle the rest' mode is still missing -
  my devel tree has something like that in the works, but I'll probably
  never finish it now that CML2 is official.

o it still has multiple top-level config.in.  Again that is easily fixable
  and in fact I did a patch for it (including {old,menu,x}config support
  in 2.3 times but never submitted it.

Something missing?

Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Michael Elizabeth Chastain]

I like mconfig, but I like CML2 better.

My primary reason is that ESR has more time to work on CML2 than I do
on mconfig.  And speed problems are often the easiest problems to solve.

Eric did some performance analysis.  If I recall correctly, all but 1
or 2 seconds of CML2's runtime is in the parser.  He has rewritten the
parser once.  Maybe someone needs to rewrite it again, maybe propagate
some changes into the language spec to make it easier to parse, maybe
rewrite from Python to C.

Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[esr]

Michael Elizabeth Chastain [EMAIL PROTECTED]:
 I like mconfig, but I like CML2 better.

Reminder for the rest of you: Michael *wrote* mconfig.

 My primary reason is that ESR has more time to work on CML2 than I do
 on mconfig.  And speed problems are often the easiest problems to solve.
 
 Eric did some performance analysis.  If I recall correctly, all but 1
 or 2 seconds of CML2's runtime is in the parser.  He has rewritten the
 parser once.  Maybe someone needs to rewrite it again, maybe propagate
 some changes into the language spec to make it easier to parse, maybe
 rewrite from Python to C.

The *language compiler's* runtime got cut in half when I hand-rolled a
parser for it.  The speed problem now is in the configurator itself.
One of my post-1.0.0 challenges is to profile and tune the configurator
code to within an inch of its life.
-- 
a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a

'Faith' means not _wanting_ to know what is true.
-- Nietzsche, Der Antichrist
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Alan Cox]

 Eric did some performance analysis.  If I recall correctly, all but 1
 or 2 seconds of CML2's runtime is in the parser.  He has rewritten the
 parser once.  Maybe someone needs to rewrite it again, maybe propagate
 some changes into the language spec to make it easier to parse, maybe
 rewrite from Python to C.

CML2 seems to have two other problems in my mind. Inability to parse the
existing config files. Also the draw ordering in the menu based config doesnt
appear right. Menuconfig has a rather undocumented but very important property
of doing roughly the right thing with screenreaders. Something to bear in mind
when fixing the menu redrawing stuff.

Alan



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[esr]

[EMAIL PROTECTED] [EMAIL PROTECTED]:
 One of the first things I noticed was it seems noticably slower
 than CML1. A make menuconfig in CML1 takes me into the menu
 in under a second. (On an already compiled tree).
 CML2 takes around 15 seconds before I get that far.
 This is on an Athlon 800 w/512MB. I dread to think how this
 responds on a 486.

Yes, I know I have some speed-tuning to do.

 Scrolling the cursor bar in menuconfig causes a lot of flickering
 as the entire screen seems to be redrawn. This is becomes unusable
 after a few minutes usage. Scrolling under CML1's menuconfig doesn't
 show this behaviour.

That's odd.  I see no screen flicker at all when I scroll my menu bar.
I wonder what's different about your environment.  You're running under
SuSE, I presume -- perhaps you have an older ncurses version?

 The various colours used to show submenus that have been visited
 seems confusing, and unnecessary. Their meaning also seems undocumented.

I'll document them.  They're intended to help you track what portions
of the configuration you've already done.
 
 Top level menu seems to have gained a few items.
 For example, the `SCSI support' item has disappeared,
 making `SCSI disk support' and `SCSI low-level drivers'
 both appear on the top level menu.

The SCSI support flag is in the buses menu.  You see these two menus because
the defconfig sets it on.
 
 For some reason, the kernel hacking menu doesn't show
 4/5 of the options that it used to. Instead it replaces
 them with one new one (Disable VHPT). Which it seems to
 picking up from the IA64 tree. Most strange.

Ah.  That's because I didn't have an `unless ia64 suppress DISABLE_VHPT'
I've added that.

A lot of the stuff that used to be under that menu moved to archihacks,
I think.
 
 Finally, quitting the program (q twice) gives me this..
 python2 -O scripts/configtrans.py -h include/linux/autoconf.h -s .config
 config.out
 Traceback (most recent call last):
   File "scripts/configtrans.py", line 104, in ?
 sys.stderr.write(args[0]);
 TypeError: read-only character buffer, int
 make: *** [menuconfig] Error 1

I can't reproduce this.  Do you get the same behavior under 1.0.3?
-- 
a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a

Such are a well regulated militia, composed of the freeholders,
citizen and husbandman, who take up arms to preserve their property,
as individuals, and their rights as freemen.
-- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" 
referred to in the Second Amendment to the Constitution.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[esr]

Alan Cox [EMAIL PROTECTED]:
 Multiple layers of Config.in is a feature

I disagree, because I've seen what happens when we go to a single-apex tree.
But you could persuade me otherwise.  What's your reason for believing this?

The problem with having multiple apices of the configuration tree (as I see
it) is that we often ended up duplicating configuration code for things that
aren't actually port-dependent but rather depend on other things such as
supported bus types (ISA, PCA, PCMCIA, etc.).  This is a particularly big
issue with network cards and disk controllers.

The duplicated code then starts to skew.  You end up with lots of features
(especially drivers) that could be supported across architectures but aren't,
simply because port maintainers are focused on their own trees and don't look
at what's going on in the others.

A multiple-apex tree also tends to pull the configuration questions downwards
from policy (e.g "Parallel-port support?") towards hardware-specific,
platform-specific questions ("Atari parallel-port hardware?")  By designing
the configuration rules for CML2 as a single-apex tree, I'm trying to
move the questions upwards and have derivations in the rules file handle
distributing that information to a lower level.

For example, instead of a bunch of parallel questions like this in a 
multiple-apex tree:

PARPORT 'Parallel port support'
PARPORT_PC  'PC-style hardware'
PARPORT_PC_PCMCIA   'Support for PCMCIA management for PC-style ports'
PARPORT_ARC 'Archimedes hardware'
PARPORT_AMIGA   'Amiga builtin port'
PARPORT_MFC3'Multiface III parallel port'
PARPORT_ATARI   'Atari hardware'
PARPORT_SUNBPP  'Sparc hardware'

I'm trying to move us towards having *one* question and a bunch of
well-hidden intelligence about what it implies:

PARPORT 'Parallel port support'
derive PARPORT_PC from PARPORT and X86
derive PARPORT_ARC from PARPORT and ARC
derive PARPORT_AMIGA from PARPORT and AMIGA
derive PARPORT_SUNBPP from PARPORT and SUN
-- 
a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a

Government is actually the worst failure of civilized man. There has
never been a really good one, and even those that are most tolerable
are arbitrary, cruel, grasping and unintelligent.
-- H. L. Mencken 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Alan Cox]

 PARPORT   'Parallel port support'
 derive PARPORT_PC from PARPORT and X86

PARPORT_PC is found on almost all architectures btw. Its also implied by PCI
bus ISA bus and random silicon all over the place




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[esr]

Alan Cox [EMAIL PROTECTED]:
 CML2 seems to have two other problems in my mind. Inability to parse
 the existing config files.

I gave upon that early for two reasons.  One was practical; Michael tried this
with mconfig, and (apparently) failed.  Or, at least, appeared to have decided
that path was not worth pursuing.

The other was the procedural vs. declarative problem.  I spent about a
month after the kbuild team originally encouraged me to tackle the
problem working on a design which I later labeled Thesis.  This was an
attempt to build a cleaned-up CML1, basically the existing language
without the syntactic warts.  I got as far as spinning up an
incomplete implementation that could check toy configurations.

But the design basically didn't work.  The problem is that a
procedural language imposes a kind of time order that makes it very
difficult to (a) do backtracking and (b) prove the correctness of your
result.  Perhaps a clearer way to put it is that configuration (like, say,
screen widget layout) is fundamentally a constraint problem rather
than a control problem.

A constraint problem needs a declarative rather than imperative
language, and it needs a baby reasoning engine to generate a
constraint-satisfying solution (Tk approaches screen-widget layout
this way; that's thye source of its power).  Neither of my strawman
designs had significant advantage over CML1 until I bit the bullet and
wrote a theorem prover to reason about timeless constraints.

Also the draw ordering in the menu based
 config doesnt appear right. Menuconfig has a rather undocumented but
 very important property of doing roughly the right thing with
 screenreaders. Something to bear in mind when fixing the menu
 redrawing stuff.

Yes, I have plans for this.
-- 
a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a

Militias, when properly formed, are in fact the people themselves and
include all men capable of bearing arms. [...] To preserve liberty it is
essential that the whole body of the people always possess arms and be
taught alike, especially when young, how to use them.
-- Senator Richard Henry Lee, 1788, on "militia" in the 2nd Amendment
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[esr]

Alan Cox [EMAIL PROTECTED]:
 Ok I see where you are going with that argument. However when you parse all
 the existing Config.in files into a tree you can see those properties by 
 looking from any node back to its dependancies

Granted.  If, that is, the representation you generate supports that kind
of backtracking.  This turns out to be very hard if you're starting from
an imperative representation rather than a declarative one.  

But, as a separate issue, the CML2 design *could* be reworked to support
a multiple-apex tree, if there were any advantage to doing so.  I don't
see one.  Do you?
-- 
a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a

Good intentions will always be pleaded for every assumption of
authority. It is hardly too strong to say that the Constitution was
made to guard the people against the dangers of good intentions. There
are men in all ages who mean to govern well, but they mean to
govern. They promise to be good masters, but they mean to be masters.
-- Daniel Webster
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[esr]

Jeff Garzik [EMAIL PROTECTED]:
 [EMAIL PROTECTED] wrote:
  But, as a separate issue, the CML2 design *could* be reworked to support
  a multiple-apex tree, if there were any advantage to doing so.  I don't
  see one.  Do you?
 
 Yes, because the current system is directed not by a central file, but
 by an architecture-specific config.in.  Compartmentalized Config.in
 files are easy to include and even easier to exclude selectively.  It's
 pretty pointless for S/390 arch to parse a ton of driver config entries
 it will never present to the user; that wastes memory and slows down the
 configuration system.

The low-level answer is that the configurator doesn't pay the
parse-time cost; the CML2 compiler does all that and presents the
configurator with a rulebase object that is not large enough for the
incremental I/O or memory cost of the "useless" information to be
significant.  (I'm not handwaving here, I've actually profiled this;
the rulebase object for 2.4.3 is only 342K on disk and less than that
in core.)

BTW, CML2 only has a "central file" in a rather trivial sense.  Here's
what the code to include the port-specific rules looks like:

source "arch/i386/rules.cml"
source "arch/alpha/rules.cml"
source "arch/sparc/rules.cml"
source "arch/mips/rules.cml"
source "arch/ppc/rules.cml"
source "arch/m68k/rules.cml"
source "arch/arm/rules.cml"
source "arch/sh/rules.cml"
source "arch/ia64/rules.cml"
source "arch/parisc/rules.cml"
source "arch/s390/rules.cml"
source "arch/cris/rules.cml"

The real issue isn't that they're "centralized", it's that they're 
siblings under a top-level architecture menu (which most users won't
see because normal invocations of the configurator supply that answer
from the command line, just as in CML1).  Which brings me neatly 
to my next point...

The higher-level answer is that you're confusing an implementation
issue with a design issue.  Beware of such premature optimization, for
as the hierophant Knuth hath revealed unto us, it is the root of all
evil.  To persuade me to go back to a multiple-apex tree you'd have to
show that there is a *design* or complexity-control advantage to
compartmentalizing the configuration information in that way.  Maybe
there is one, but nobody's shown it to me yet.

(In truth I don't dismiss implementation concerns quite as cavalierly
as it might sound from the above.  But buying a linear speedup wouldn't
be good enough to make me change the design.  A quadratic speedup might
be, but none of CML2's algorithms are quadratic in the number of symbols
in the rulebase.)
-- 
a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a

The men and women who founded our country knew, by experience, that there
are times when the free person's answer to oppressive government has to be
delivered with a bullet.  Thus, the right to bear arms is not just *a*
freedom; it's the mother of all freedoms.  Don't let them disarm you!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Aaron Lehmann]

On Wed, Apr 11, 2001 at 05:46:09PM -0400, [EMAIL PROTECTED] wrote:
 The speed problem now is in the configurator itself.
 One of my post-1.0.0 challenges is to profile and tune the configurator
 code to within an inch of its life.

Maybe you could kill two birds with one stone by calling 1.0.0 the
prototype and rewriting it in C. Not only would this improve speed
(algorithmic improvements would also be welcome...), but it would
remove the pythonic obstacle to its adoption as a standard. Many,
including me, oppose writing the standard configurator in Python. I
don't have Python installed and I'm not going to install yet another
scripting language just because ESR likes it. Yes, we know about
freeze support, but aren't convinced that it will do well at this. It
seems that a native C configurator will be both faster and more
portable (accross distributions and mindsets) than something requiring
a recent version of SuperEasyInterpretedProgrammingLanguage 2.0.

I know that you're reluctant to make the port, but you don't need to
be too shy to ask for help. Few people on this list are afraid of C.
If you're too lazy to implement CML2 in a standard, popular, robust
language, heck, tell us, and we may be able to help you out.

Sorry for the anti-Python flamage. I'm sure that it has its uses. I,
however, don't view it as appropriate for configuration of an integral
component of a GNU/Linux system. I want to make the view clear to aid
Linus with his descision and to encourage a C port of CML2, which
languages aside looks like a good format and concept BTW.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[esr]

Aaron Lehmann [EMAIL PROTECTED]:
 Maybe you could kill two birds with one stone by calling 1.0.0 the
 prototype and rewriting it in C.

If I were to become absolutely convinced that I can't get acceptable speed
out of Python, I might do that.  There's a gcml project that tracked the CML2
compiler up to about 0.72 level that might make a decent starting point.

Unfortunately, I'm fairly sure that finishing gcml would take long
enough to render the point moot, because by the time it was done the
average Linux machine would have sped up enough for the Python
implementation not to be laggy anymore :-).

No joke -- *you* try writing a theorem-prover in a language with only
fixed-extent data types.  Go on.  Try it.  I think you will (as Mark
Twain put it about the consequences of teasing a cat) acquire a
valuable education, the facts of which will never grow dim or
doubtful.

I'm pretty sure that tuning the Python implementation (coming up with
faster algorithms, perhaps by reorganizing the data structures to do
more precomputation) will be a more effective use of my time.
-- 
a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a

"One of the ordinary modes, by which tyrants accomplish their purposes
without resistance, is, by disarming the people, and making it an
offense to keep arms."
-- Constitutional scholar and Supreme Court Justice Joseph Story, 1840
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Russell King]

On Tue, Apr 10, 2001 at 06:47:00AM -0400, Eric S. Raymond wrote:
> On 30 March 2001 at the Kernel Summit, Keith Owens and I worked out a
> transition schedule with Linus.  Keith's rewrite of the makefile system and
> my configurator tools are officially slated to replace the present system in
> the 2.5.1 to 2.5.2 timeframe.  That, of course, is contingent on us not
> screwing up :-).

Assuming that Keiths makefiles can do everything that architecture
maintainers need it to do.

Currently, one of the many things I'm doing is trying to sort out a
working kbuild-2.5 for the ARM tree.  I have some stuff done, but there
are several things that I'm definitely not happy with, and there is
currently a whole scoop of stuff which I haven't yet found a way for
kbuild-2.5 to handle.  Its looking like the ARM trees use of kbuild-2.5
will be even more messy than its use of the current build system.

(We have around 60 machines, which key both which files get built, the
text and data address of the running kernel image, the text and data
address of the decompressor, and which vmlinux.lds.in file we use to
link the kernel.  This is currently my biggest problem that kbuild-2.5
doesn't seem to be able to handle at present.  Note that it is not
acceptable that users should have to type in 5 or so apparantly
meaningless hex addresses when they configure the kernel.)

I've yet to hear back from Keith on the issues I have with kbuild-2.5,
but I'm hopeful that he has some good suggestions...

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 release announcement

[Russell King]

On Tue, Apr 10, 2001 at 06:47:00AM -0400, Eric S. Raymond wrote:
 On 30 March 2001 at the Kernel Summit, Keith Owens and I worked out a
 transition schedule with Linus.  Keith's rewrite of the makefile system and
 my configurator tools are officially slated to replace the present system in
 the 2.5.1 to 2.5.2 timeframe.  That, of course, is contingent on us not
 screwing up :-).

Assuming that Keiths makefiles can do everything that architecture
maintainers need it to do.

Currently, one of the many things I'm doing is trying to sort out a
working kbuild-2.5 for the ARM tree.  I have some stuff done, but there
are several things that I'm definitely not happy with, and there is
currently a whole scoop of stuff which I haven't yet found a way for
kbuild-2.5 to handle.  Its looking like the ARM trees use of kbuild-2.5
will be even more messy than its use of the current build system.

(We have around 60 machines, which key both which files get built, the
text and data address of the running kernel image, the text and data
address of the decompressor, and which vmlinux.lds.in file we use to
link the kernel.  This is currently my biggest problem that kbuild-2.5
doesn't seem to be able to handle at present.  Note that it is not
acceptable that users should have to type in 5 or so apparantly
meaningless hex addresses when they configure the kernel.)

I've yet to hear back from Keith on the issues I have with kbuild-2.5,
but I'm hopeful that he has some good suggestions...

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/