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

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 i

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 acceptabl

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 goo

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 messa

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 abou

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

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

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 compi

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 centr

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 path

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 trying

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

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

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 l

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 80

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

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 pa

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 _eve

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 late

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 th

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: [kbuild-devel] CML2 1.0.0 release announcement

Dunlap, Randy <[EMAIL PROTECTED]>: > Then the README should be listed (linked) on one of the 2 web pages > above. I can't find it without downloading "CML2 prototype > and documentation," right? I think that it should be > more visible that Python version x.yy(?) is needed, without > having to d

RE: [kbuild-devel] CML2 1.0.0 release announcement

> 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: [kbuild-devel] CML2 1.0.0 release announcement

Dunlap, Randy <[EMAIL PROTECTED]>: > I'd like to see one of the prominent web pages inform > people that Python version x.yy(?) is required to use CML2. It's in the README. Is that good enough? -- http://www.tuxedo.org/~esr/">Eric S. Raymond "Boys who own legal firearms have mu

RE: [kbuild-devel] CML2 1.0.0 release announcement

Hi Eric, > 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, 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 > th

CML2 1.0.0 release announcement

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 . (Why thi