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

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

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

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,

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

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

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

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

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

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

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

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 :-).

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

> 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

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

"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 >

Re: CML2 1.0.0 release announcement

> * 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

Re: CML2 1.0.0 release announcement

* 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

Re: CML2 1.0.0 release announcement

"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

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

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

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

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 :-).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

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

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

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

Re: CML2 1.0.0 release announcement

> 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

Re: CML2 1.0.0 release announcement

> 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

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

> 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

Re: CML2 1.0.0 release announcement

[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

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

> 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 >

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

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. >

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

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

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

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

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

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

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

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

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

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

Re: CML2 1.0.0 release announcement

[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

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

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

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

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

Re: CML2 1.0.0 release announcement

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

Re: CML2 1.0.0 release announcement

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,

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

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

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

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

Re: CML2 1.0.0 release announcement

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 >

Re: CML2 1.0.0 release announcement

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