Re: [kbuild-devel] Re: CML2 design philosophy heads-up
In article <[EMAIL PROTECTED]> you wrote: > On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: >> distributions). 18 months is more realistic for it to be deployed >> widely enough. > People who are going to be savvy enough to install a development 2.5.* > kernel that is defining a new configuration utility are going to be savvy > enough to install python. In the first months, yes. Once we freeze you've just lost a major part of your testersbase... - 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 design philosophy heads-up
Brent D. Norris <[EMAIL PROTECTED]>: > didn't Eric say that this has stalled though? Is that not the case? Nope. Greg is still working. He got the first version of the theorem prover working recently. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond A wise and frugal government, which shall restrain men from injuring one another, which shall leave them otherwise free to regulate their own pursuits of industry and improvement, and shall not take from the mouth of labor the bread it has earned. This is the sum of good government, and all that is necessary to close the circle of our felicities. -- Thomas Jefferson, in his 1801 inaugural address - 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 design philosophy heads-up
On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote: > Not only that, but Alan said that somebody is rewriting it in C. I'll believe it when I see it. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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 design philosophy heads-up
> On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote: > > Not only that, but Alan said that somebody is rewriting it in C. > I'll believe it when I see it. and if not then obviously nobody hates the python one enough ;) - 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 design philosophy heads-up
> #2 is fixed by rewriting tools in C didn't Eric say that this has stalled though? Is that not the case? Brent Norris Executive Advisor -- WKU-Linux System Administrator -- WKU-Center for Biodiversity Best Mechanical - 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 design philosophy heads-up
Tom Rini <[EMAIL PROTECTED]>: > python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script > uses undocumented things which did work in python1.5.x. That's true of the core language. The reason I moved to 2.0 was that there are library changes in 2.0 that enabled me to to cut CML2's in-kernel footprint substantially. > Which brings up another point, RedHat (7.1?) and Debian/woody both have the > option of having python2 around. Anyone know about mandrake? My point is > that some dists are already dealing with python2. Yes. By the time 2.5 forks, distros covering an estimated 85% of the market will carry python2 binaries which the CML2 install script will find automatically. By the time 2.6 forks, we're going to laugh if we ever remember that we thought this was an issue. > Eric, would it be easy/possible to go back to requiring python 1.5.x for > CML2, since that is what many dists ship with? It wouldn't be too difficult. But it would make the code heavier, and I'm not clear that it would make anybody happy who isn't already willing to deal with the design concept. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The world is filled with violence. Because criminals carry guns, we decent law-abiding citizens should also have guns. Otherwise they will win and the decent people will lose. -- James Earl Jones - 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 design philosophy heads-up
On Monday 21 May 2001 10:01, Tom Rini wrote: > On Mon, May 21, 2001 at 09:58:04AM -0600, Steven Cole wrote: > > On Monday 21 May 2001 09:36, Tom Rini wrote: > > > Which brings up another point, RedHat (7.1?) and Debian/woody both have > > > the option of having python2 around. Anyone know about mandrake? My > > > point is that some dists are already dealing with python2. > > > > Hi Tom, > > I use Linux-Mandrake 8.0 now, and python2 is installed by default for a > > development workstation installation. I asked Mandrakesoft to also > > install the tkinter package (which was not installed by default in > > release candidate 1), and it appeared in LM 8.0 final, so if you like to > > use make xconfig with CML2, you can. > > Could you please send this to linux-kernel as well? :) At Tom's request, posting to lkml. 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 design philosophy heads-up
On 21 May 2001, Wichert Akkerman wrote: > In article <[EMAIL PROTECTED]>, > Mike A. Harris <[EMAIL PROTECTED]> wrote: > >For the record, the kgcc "mess" you speak of was used by > >Conectiva, and I believe also by debian > > Debian never had that mess. I think that Mike refers to gcc272 being used as a kernel compiler for quite a while and gcc-2.95 being used the same way in -testing. having different compilers for kernel and userland is not pretty, but there's no way to avoid it at some points in cycle. - 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 design philosophy heads-up
On Mon, May 21, 2001 at 11:58:34AM +0200, Jes Sorensen wrote: > > "Jakob" == Jakob ?stergaard <[EMAIL PROTECTED]> writes: > > Jakob> On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: > >> I think this is a very important point, and one I agree with. I > >> tend to let my distribution handle stuff like python. now, I use > >> RedHat's on-going devel, RawHide. it is not using python2. in > >> fact, since switching to python2 may break old stuff, I don't > >> expect python2 until 8.0. that wont be for 9 months. 90% of > >> RedHat's configuration tools, et al, are written in python1 and > >> they just are not going to change on someone's whim. > > Jakob> 2.6.0 isn't going to happen for at least a year or two. What's > Jakob> the problem ? > > Jakob> Want 2.5.X ? Get the tools too. > > Some people grab the latest devel kernels because thats all that works > on their hardware. And they can grab the latest tools too. Why is this a problem again? python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script uses undocumented things which did work in python1.5.x. But that's not as big of a problem since they can co-exist. Debian already does this (And thus CML2 already deals with python2 being called 'python2') and I wouldn't be supprised if the PowerTools python2 rpm someone pointed out makes them co-exist as well. Which brings up another point, RedHat (7.1?) and Debian/woody both have the option of having python2 around. Anyone know about mandrake? My point is that some dists are already dealing with python2. > Jakob> I'm in no position to push people around, but I think the > Jakob> whining about CML2 tool requirements is completely unjustified. > Jakob> If we required that everything worked with GCC 2.7.2 and nmake, > Jakob> where would we be today ? I'm a lot more worried about CML2 > Jakob> itself than about the tools it requires :) > > gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are > not. Well no, but python1 requires another 2k lines of python code or so. Eric, would it be easy/possible to go back to requiring python 1.5.x for CML2, since that is what many dists ship with? > Jakob> Whether CML2 requires python2 or not, the distributions will > Jakob> change. This is not about Eric pushing something down people's > Jakob> throats. Tools evolve, and new revisions introduce > Jakob> incompatibilities, but distributions still follow the > Jakob> evolution. Nobody ships perl4 today either. > > The point is that Eric has been trying to push distributions to ship > P2. Maybe, maybe not. Forgetting about the QA time and whatnot, there's good odds that all of the python scripts RedHat (for example) ships will just work with python2. I know one of the PPC dists didn't ship with python2 (which does have a lot of python bits to it) entirely because they were already in testing when it came out. It's not something the distros can switch to at a whim, but it's also something which shouldn't cause them problems when they do. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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 design philosophy heads-up
> Mike A. Harris <[EMAIL PROTECTED]> wrote: > >For the record, the kgcc "mess" you speak of was used by > >Conectiva, and I believe also by debian > Debian never had that mess. Debians variant was gcc272 not kgcc. The 2.2.19 makefile knows about both of them - 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 design philosophy heads-up
In article <[EMAIL PROTECTED]>, Mike A. Harris <[EMAIL PROTECTED]> wrote: >For the record, the kgcc "mess" you speak of was used by >Conectiva, and I believe also by debian Debian never had that mess. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - 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 design philosophy heads-up
> i mean how in 2.2 the Makefile must search out for gcc, kgcc, gcc-2.95, > gcc-2.91 etc. what is the cml2 parser going to do? search for my python2 This isnt a CML2 related problem. Problem 1: People who don't like the CML2 description Problem 2: People who don't like python Problem 3: People who don't like the tool design Problem 4: People who don't have python2 #1 is the important item #2 is fixed by rewriting tools in C #3 is fixed by writing alternative tools using CML2 - and if you cant its a bug in the CML2 language #4 is probably one for the LDPS/LSB and vendor people to discuss so we have an official path for python2 - 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 design philosophy heads-up
On 21 May 2001 02:11:39 -0400, Mike A. Harris wrote: > On 20 May 2001, Robert M. Love wrote: >>(on another note, about the coexist issue: am i going to have a python >>and python2 binary? so now the config tool will find which to use, ala >>the kgcc mess? great) > > For the record, the kgcc "mess" you speak of was used by > Conectiva, and I believe also by debian before adoption in Red > Hat Linux. It was about as good a solution as one could get for > the problem that it solved - the kernel being broken and unable > to build with our gcc-2.96. Just to head anyone off at the > pass... the kernel is fixed and now builds properly with > gcc-2.96. my view of the mess wasn't the fact RedHat used kgcc. i think that was a good move. i mean how in 2.2 the Makefile must search out for gcc, kgcc, gcc-2.95, gcc-2.91 etc. what is the cml2 parser going to do? search for my python2 binary because my python1 binary is my "standard" python? -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] - 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 design philosophy heads-up
> "Ben" == Ben Ford <[EMAIL PROTECTED]> writes: Ben> Mike Castle wrote: >> People who are going to be savvy enough to install a development >> 2.5.* kernel that is defining a new configuration utility are going >> to be savvy enough to install python. >> Ben> Not only that, but Alan said that somebody is rewriting it in C. No and yes, the Python 2 issue is not reasonable, the C version of it is. Hopefully with a proper C version, the Python 2 dependencies will go away completely and that part of the discussion becomes moot. The Python 2 one is a major issue, some people compile current kernels because thats all that exists for their hardware. Some people who are bringing up new architectures etc. wants to be self hosting but things like Perl and Python are not exactly the first things you build. You may not have threads, you may not have proper math support, maybe no shared libraries, but that wont stop you from getting gcc/binutils/bash going. The argument I got from Eric at the 2.5 kernel summit when I first brought this up was 'just configure your kernel on another machine and copy it over'. Thats extremely naiive, in some cases you do not have network nor floppy. You copy your sources over once (so you can hack on the network driver :), you don't want to have to rip out the disk every time you need a change to the .config because some obscure option doesn't compile and you hadn't noticed. It's just not that trivial. Jes - 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 design philosophy heads-up
Mike Castle wrote: >On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: > >>distributions). 18 months is more realistic for it to be deployed >>widely enough. >> > >People who are going to be savvy enough to install a development 2.5.* >kernel that is defining a new configuration utility are going to be savvy >enough to install python. > >mrc > Not only that, but Alan said that somebody is rewriting it in C. -- "One trend that bothers me is the glorification of stupidity, that the media is reassuring people it's alright not to know anything. That to me is far more dangerous than a little pornography on the Internet." - Carl Sagan - 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 design philosophy heads-up
Mike Castle wrote: On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: distributions). 18 months is more realistic for it to be deployed widely enough. People who are going to be savvy enough to install a development 2.5.* kernel that is defining a new configuration utility are going to be savvy enough to install python. mrc Not only that, but Alan said that somebody is rewriting it in C. -- One trend that bothers me is the glorification of stupidity, that the media is reassuring people it's alright not to know anything. That to me is far more dangerous than a little pornography on the Internet. - Carl Sagan - 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 design philosophy heads-up
Ben == Ben Ford [EMAIL PROTECTED] writes: Ben Mike Castle wrote: People who are going to be savvy enough to install a development 2.5.* kernel that is defining a new configuration utility are going to be savvy enough to install python. Ben Not only that, but Alan said that somebody is rewriting it in C. No and yes, the Python 2 issue is not reasonable, the C version of it is. Hopefully with a proper C version, the Python 2 dependencies will go away completely and that part of the discussion becomes moot. The Python 2 one is a major issue, some people compile current kernels because thats all that exists for their hardware. Some people who are bringing up new architectures etc. wants to be self hosting but things like Perl and Python are not exactly the first things you build. You may not have threads, you may not have proper math support, maybe no shared libraries, but that wont stop you from getting gcc/binutils/bash going. The argument I got from Eric at the 2.5 kernel summit when I first brought this up was 'just configure your kernel on another machine and copy it over'. Thats extremely naiive, in some cases you do not have network nor floppy. You copy your sources over once (so you can hack on the network driver :), you don't want to have to rip out the disk every time you need a change to the .config because some obscure option doesn't compile and you hadn't noticed. It's just not that trivial. Jes - 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 design philosophy heads-up
In article [EMAIL PROTECTED], Mike A. Harris [EMAIL PROTECTED] wrote: For the record, the kgcc mess you speak of was used by Conectiva, and I believe also by debian Debian never had that mess. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - 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 design philosophy heads-up
On 21 May 2001, Wichert Akkerman wrote: In article [EMAIL PROTECTED], Mike A. Harris [EMAIL PROTECTED] wrote: For the record, the kgcc mess you speak of was used by Conectiva, and I believe also by debian Debian never had that mess. I think that Mike refers to gcc272 being used as a kernel compiler for quite a while and gcc-2.95 being used the same way in -testing. shrug having different compilers for kernel and userland is not pretty, but there's no way to avoid it at some points in cycle. - 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 design philosophy heads-up
On Monday 21 May 2001 10:01, Tom Rini wrote: On Mon, May 21, 2001 at 09:58:04AM -0600, Steven Cole wrote: On Monday 21 May 2001 09:36, Tom Rini wrote: Which brings up another point, RedHat (7.1?) and Debian/woody both have the option of having python2 around. Anyone know about mandrake? My point is that some dists are already dealing with python2. Hi Tom, I use Linux-Mandrake 8.0 now, and python2 is installed by default for a development workstation installation. I asked Mandrakesoft to also install the tkinter package (which was not installed by default in release candidate 1), and it appeared in LM 8.0 final, so if you like to use make xconfig with CML2, you can. Could you please send this to linux-kernel as well? :) At Tom's request, posting to lkml. 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 design philosophy heads-up
Tom Rini [EMAIL PROTECTED]: python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script uses undocumented things which did work in python1.5.x. That's true of the core language. The reason I moved to 2.0 was that there are library changes in 2.0 that enabled me to to cut CML2's in-kernel footprint substantially. Which brings up another point, RedHat (7.1?) and Debian/woody both have the option of having python2 around. Anyone know about mandrake? My point is that some dists are already dealing with python2. Yes. By the time 2.5 forks, distros covering an estimated 85% of the market will carry python2 binaries which the CML2 install script will find automatically. By the time 2.6 forks, we're going to laugh if we ever remember that we thought this was an issue. Eric, would it be easy/possible to go back to requiring python 1.5.x for CML2, since that is what many dists ship with? It wouldn't be too difficult. But it would make the code heavier, and I'm not clear that it would make anybody happy who isn't already willing to deal with the design concept. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The world is filled with violence. Because criminals carry guns, we decent law-abiding citizens should also have guns. Otherwise they will win and the decent people will lose. -- James Earl Jones - 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 design philosophy heads-up
On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote: Not only that, but Alan said that somebody is rewriting it in C. I'll believe it when I see it. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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 design philosophy heads-up
In article [EMAIL PROTECTED] you wrote: On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: distributions). 18 months is more realistic for it to be deployed widely enough. People who are going to be savvy enough to install a development 2.5.* kernel that is defining a new configuration utility are going to be savvy enough to install python. In the first months, yes. Once we freeze you've just lost a major part of your testersbase... - 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 design philosophy heads-up
Brent D. Norris [EMAIL PROTECTED]: didn't Eric say that this has stalled though? Is that not the case? Nope. Greg is still working. He got the first version of the theorem prover working recently. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a A wise and frugal government, which shall restrain men from injuring one another, which shall leave them otherwise free to regulate their own pursuits of industry and improvement, and shall not take from the mouth of labor the bread it has earned. This is the sum of good government, and all that is necessary to close the circle of our felicities. -- Thomas Jefferson, in his 1801 inaugural address - 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 design philosophy heads-up
On Mon, May 21, 2001 at 11:58:34AM +0200, Jes Sorensen wrote: Jakob == Jakob ?stergaard [EMAIL PROTECTED] writes: Jakob On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: I think this is a very important point, and one I agree with. I tend to let my distribution handle stuff like python. now, I use RedHat's on-going devel, RawHide. it is not using python2. in fact, since switching to python2 may break old stuff, I don't expect python2 until 8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et al, are written in python1 and they just are not going to change on someone's whim. Jakob 2.6.0 isn't going to happen for at least a year or two. What's Jakob the problem ? Jakob Want 2.5.X ? Get the tools too. Some people grab the latest devel kernels because thats all that works on their hardware. And they can grab the latest tools too. Why is this a problem again? python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script uses undocumented things which did work in python1.5.x. But that's not as big of a problem since they can co-exist. Debian already does this (And thus CML2 already deals with python2 being called 'python2') and I wouldn't be supprised if the PowerTools python2 rpm someone pointed out makes them co-exist as well. Which brings up another point, RedHat (7.1?) and Debian/woody both have the option of having python2 around. Anyone know about mandrake? My point is that some dists are already dealing with python2. Jakob I'm in no position to push people around, but I think the Jakob whining about CML2 tool requirements is completely unjustified. Jakob If we required that everything worked with GCC 2.7.2 and nmake, Jakob where would we be today ? I'm a lot more worried about CML2 Jakob itself than about the tools it requires :) gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are not. Well no, but python1 requires another 2k lines of python code or so. Eric, would it be easy/possible to go back to requiring python 1.5.x for CML2, since that is what many dists ship with? Jakob Whether CML2 requires python2 or not, the distributions will Jakob change. This is not about Eric pushing something down people's Jakob throats. Tools evolve, and new revisions introduce Jakob incompatibilities, but distributions still follow the Jakob evolution. Nobody ships perl4 today either. The point is that Eric has been trying to push distributions to ship P2. Maybe, maybe not. Forgetting about the QA time and whatnot, there's good odds that all of the python scripts RedHat (for example) ships will just work with python2. I know one of the PPC dists didn't ship with python2 (which does have a lot of python bits to it) entirely because they were already in testing when it came out. It's not something the distros can switch to at a whim, but it's also something which shouldn't cause them problems when they do. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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 design philosophy heads-up
Mike A. Harris [EMAIL PROTECTED] wrote: For the record, the kgcc mess you speak of was used by Conectiva, and I believe also by debian Debian never had that mess. Debians variant was gcc272 not kgcc. The 2.2.19 makefile knows about both of them - 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 design philosophy heads-up
#2 is fixed by rewriting tools in C didn't Eric say that this has stalled though? Is that not the case? Brent Norris Executive Advisor -- WKU-Linux System Administrator -- WKU-Center for Biodiversity Best Mechanical - 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 design philosophy heads-up
On 21 May 2001 02:11:39 -0400, Mike A. Harris wrote: On 20 May 2001, Robert M. Love wrote: (on another note, about the coexist issue: am i going to have a python and python2 binary? so now the config tool will find which to use, ala the kgcc mess? great) For the record, the kgcc mess you speak of was used by Conectiva, and I believe also by debian before adoption in Red Hat Linux. It was about as good a solution as one could get for the problem that it solved - the kernel being broken and unable to build with our gcc-2.96. Just to head anyone off at the pass... the kernel is fixed and now builds properly with gcc-2.96. my view of the mess wasn't the fact RedHat used kgcc. i think that was a good move. i mean how in 2.2 the Makefile must search out for gcc, kgcc, gcc-2.95, gcc-2.91 etc. what is the cml2 parser going to do? search for my python2 binary because my python1 binary is my standard python? -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] - 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 design philosophy heads-up
On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote: Not only that, but Alan said that somebody is rewriting it in C. I'll believe it when I see it. and if not then obviously nobody hates the python one enough ;) - 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 design philosophy heads-up
i mean how in 2.2 the Makefile must search out for gcc, kgcc, gcc-2.95, gcc-2.91 etc. what is the cml2 parser going to do? search for my python2 This isnt a CML2 related problem. Problem 1: People who don't like the CML2 description Problem 2: People who don't like python Problem 3: People who don't like the tool design Problem 4: People who don't have python2 #1 is the important item #2 is fixed by rewriting tools in C #3 is fixed by writing alternative tools using CML2 - and if you cant its a bug in the CML2 language #4 is probably one for the LDPS/LSB and vendor people to discuss so we have an official path for python2 - 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 design philosophy heads-up
On Mon, 21 May 2001, Jakob Østergaard wrote: > On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: > > > > im not installing python2 from source just so i can run some new config > > utility. > > python2 will be in rawhide when 2.5 development requires it, if I'm not much > mistaken. Alan said someone is rewriting in C, so the python2 requirement is already becoming a non-problem. -Mike (don't like requirement, but don't think it's a big hairy deal either) - 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 design philosophy heads-up
On 21 May 2001, Jes Sorensen wrote: > John> Au contraire. It is very reasonable to have both python and > John> python2 installed. Having two different gcc versions installed > John> is a big pain in the arse. > > It's not unreasonable to have both installed, it's unreasonable to > require it. > > Eric seems to think he can tell every distributor to ship Python2 > tomorrow. Well it's a fine dream but it's not going to happen Distributors aren't going to ship Linux 2.5.x tomorrow either. Nicolas - 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 design philosophy heads-up
On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote:
> On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote:
> > John> Au contraire. It is very reasonable to have both python and
> > John> python2 installed. Having two different gcc versions installed
> > John> is a big pain in the arse.
> >
> > It's not unreasonable to have both installed, it's unreasonable to
> > require it.
> >
> > Eric seems to think he can tell every distributor to ship Python2
> > tomorrow. Well it's a fine dream but it's not going to happen;
>
> I think this is a very important point, and one I agree with. I tend to
> let my distribution handle stuff like python. now, I use RedHat's
> on-going devel, RawHide. it is not using python2. in fact, since
> switching to python2 may break old stuff, I don't expect python2 until
> 8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et
> al, are written in python1 and they just are not going to change on
> someone's whim.
2.6.0 isn't going to happen for at least a year or two. What's the problem ?
Want 2.5.X ? Get the tools too.
I'm in no position to push people around, but I think the whining about CML2
tool requirements is completely unjustified. If we required that everything
worked with GCC 2.7.2 and nmake, where would we be today ? I'm a lot more
worried about CML2 itself than about the tools it requires :)
>
> im not installing python2 from source just so i can run some new config
> utility.
python2 will be in rawhide when 2.5 development requires it, if I'm not much
mistaken.
Whether CML2 requires python2 or not, the distributions will change. This is
not about Eric pushing something down people's throats. Tools evolve, and new
revisions introduce incompatibilities, but distributions still follow the
evolution. Nobody ships perl4 today either.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
-
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 design philosophy heads-up
On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote: > John> Au contraire. It is very reasonable to have both python and > John> python2 installed. Having two different gcc versions installed > John> is a big pain in the arse. > > It's not unreasonable to have both installed, it's unreasonable to > require it. > > Eric seems to think he can tell every distributor to ship Python2 > tomorrow. Well it's a fine dream but it's not going to happen; I think this is a very important point, and one I agree with. I tend to let my distribution handle stuff like python. now, I use RedHat's on-going devel, RawHide. it is not using python2. in fact, since switching to python2 may break old stuff, I don't expect python2 until 8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et al, are written in python1 and they just are not going to change on someone's whim. im not installing python2 from source just so i can run some new config utility. (on another note, about the coexist issue: am i going to have a python and python2 binary? so now the config tool will find which to use, ala the kgcc mess? great) -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] - 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 design philosophy heads-up
On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: > distributions). 18 months is more realistic for it to be deployed > widely enough. People who are going to be savvy enough to install a development 2.5.* kernel that is defining a new configuration utility are going to be savvy enough to install python. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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 design philosophy heads-up
> "John" == John Cowan <[EMAIL PROTECTED]> writes: John> Jes Sorensen wrote: >> Telling them to install an updated gcc for kernel compilation is a >> necessary evil, which can easily be done without disturbing the >> rest of the system. Updating the system's python installation is >> not a reasonable request. John> Au contraire. It is very reasonable to have both python and John> python2 installed. Having two different gcc versions installed John> is a big pain in the arse. It's not unreasonable to have both installed, it's unreasonable to require it. Eric seems to think he can tell every distributor to ship Python2 tomorrow. Well it's a fine dream but it's not going to happen; Most distributors do not ship new major versions of tools in their minor number release versions. I've seen him mention the number 6 months until everybody ships it, but a) thats not going to happen Red Hat is currently at 7.1 (if one looks at their release history, one would say there is a good chance there will be a 7.2) not to mention the release rate of Debian (not sure about the current state of all other distributions). 18 months is more realistic for it to be deployed widely enough. >> So far I haven't heard a single developer say something positive >> about CML2, the most positive I have heard so far has been >> "whatever", "it's his choice", "I don't care", "I want to >> hack". The majority are of the "NO!" and "you got to be kiddin'". John> Anonymized hearsay evidence is less than convincing. Well I don't like to quote personal conversations without peoples' approval, now both David Woodhouse and Arjan are two examples. Jes - 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 design philosophy heads-up
On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: distributions). 18 months is more realistic for it to be deployed widely enough. People who are going to be savvy enough to install a development 2.5.* kernel that is defining a new configuration utility are going to be savvy enough to install python. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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 design philosophy heads-up
On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote:
On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote:
John Au contraire. It is very reasonable to have both python and
John python2 installed. Having two different gcc versions installed
John is a big pain in the arse.
It's not unreasonable to have both installed, it's unreasonable to
require it.
Eric seems to think he can tell every distributor to ship Python2
tomorrow. Well it's a fine dream but it's not going to happen; snip
I think this is a very important point, and one I agree with. I tend to
let my distribution handle stuff like python. now, I use RedHat's
on-going devel, RawHide. it is not using python2. in fact, since
switching to python2 may break old stuff, I don't expect python2 until
8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et
al, are written in python1 and they just are not going to change on
someone's whim.
2.6.0 isn't going to happen for at least a year or two. What's the problem ?
Want 2.5.X ? Get the tools too.
I'm in no position to push people around, but I think the whining about CML2
tool requirements is completely unjustified. If we required that everything
worked with GCC 2.7.2 and nmake, where would we be today ? I'm a lot more
worried about CML2 itself than about the tools it requires :)
im not installing python2 from source just so i can run some new config
utility.
python2 will be in rawhide when 2.5 development requires it, if I'm not much
mistaken.
Whether CML2 requires python2 or not, the distributions will change. This is
not about Eric pushing something down people's throats. Tools evolve, and new
revisions introduce incompatibilities, but distributions still follow the
evolution. Nobody ships perl4 today either.
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
-
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 design philosophy heads-up
On Mon, 21 May 2001, Jakob Østergaard wrote: On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: im not installing python2 from source just so i can run some new config utility. python2 will be in rawhide when 2.5 development requires it, if I'm not much mistaken. Alan said someone is rewriting in C, so the python2 requirement is already becoming a non-problem. -Mike (don't like requirement, but don't think it's a big hairy deal either) - 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 design philosophy heads-up
On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote: John Au contraire. It is very reasonable to have both python and John python2 installed. Having two different gcc versions installed John is a big pain in the arse. It's not unreasonable to have both installed, it's unreasonable to require it. Eric seems to think he can tell every distributor to ship Python2 tomorrow. Well it's a fine dream but it's not going to happen; snip I think this is a very important point, and one I agree with. I tend to let my distribution handle stuff like python. now, I use RedHat's on-going devel, RawHide. it is not using python2. in fact, since switching to python2 may break old stuff, I don't expect python2 until 8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et al, are written in python1 and they just are not going to change on someone's whim. im not installing python2 from source just so i can run some new config utility. (on another note, about the coexist issue: am i going to have a python and python2 binary? so now the config tool will find which to use, ala the kgcc mess? great) -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] - 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 design philosophy heads-up
John == John Cowan [EMAIL PROTECTED] writes: John Jes Sorensen wrote: Telling them to install an updated gcc for kernel compilation is a necessary evil, which can easily be done without disturbing the rest of the system. Updating the system's python installation is not a reasonable request. John Au contraire. It is very reasonable to have both python and John python2 installed. Having two different gcc versions installed John is a big pain in the arse. It's not unreasonable to have both installed, it's unreasonable to require it. Eric seems to think he can tell every distributor to ship Python2 tomorrow. Well it's a fine dream but it's not going to happen; Most distributors do not ship new major versions of tools in their minor number release versions. I've seen him mention the number 6 months until everybody ships it, but a) thats not going to happen Red Hat is currently at 7.1 (if one looks at their release history, one would say there is a good chance there will be a 7.2) not to mention the release rate of Debian (not sure about the current state of all other distributions). 18 months is more realistic for it to be deployed widely enough. So far I haven't heard a single developer say something positive about CML2, the most positive I have heard so far has been whatever, it's his choice, I don't care, I want to hack. The majority are of the NO! and you got to be kiddin'. John Anonymized hearsay evidence is less than convincing. Well I don't like to quote personal conversations without peoples' approval, now both David Woodhouse and Arjan are two examples. Jes - 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 design philosophy heads-up
On 21 May 2001, Jes Sorensen wrote: John Au contraire. It is very reasonable to have both python and John python2 installed. Having two different gcc versions installed John is a big pain in the arse. It's not unreasonable to have both installed, it's unreasonable to require it. Eric seems to think he can tell every distributor to ship Python2 tomorrow. Well it's a fine dream but it's not going to happen Distributors aren't going to ship Linux 2.5.x tomorrow either. Nicolas - 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 design philosophy heads-up
Arjan van de Ven wrote: >"Eric S. Raymond" wrote: > >> >>an old interface in amber do anything to explore new UI possibilities? >> > >kernel != GUI > UI != GUI -- "One trend that bothers me is the glorification of stupidity, that the media is reassuring people it's alright not to know anything. That to me is far more dangerous than a little pornography on the Internet." - Carl Sagan - 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 design philosophy heads-up
On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote: > Even supposing somebody were loony enough to do that, how would preserving > an old interface in amber do anything to explore new UI possibilities? I don't know about the rest of the world, but I _much_ prefer the old menuconfig to CML2's menuconfig. While I haven't spent much time playing with CML2, I'm familiar with cml1's tools and see no reason why they need changes, which IMHO (so far) are detrimental. That's not even to mention python issues, speed, or anything else. - 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 design philosophy heads-up
On 05/18/2001 at 03:56:50 PM Mike Castle <[EMAIL PROTECTED]> wrote: >On Fri, May 18, 2001 at 03:04:43PM -0500, [EMAIL PROTECTED] wrote: >> 1. Some of us are perfectly satisfied with the existing tools and don't want >> them to be yanked out from under us. > >Then stay with 2.4.x > Since doing kernel upgrades is my whole reason for using the tools, that's not a very helpful suggestion. It's a little like saying, "If you don't like the way the air smells, just stop breathing." >> 2. Some of us have no interest in Python and don't like being forced to deal >> with installing/upgrading it just for CML2. > > >Some don't like installing/upgrading the following just for a kernel: > >gcc >binutils >modutils >mount >Not to mention netfilter. I don't especially like upgrading these things, either, and don't do it unless I absolutely have to (that's why I'm still on egcs-2.91.66), but the kernel is important enough to be worth the trouble. If I have to use CML2 to move into 2.5.x, then I will. However, upgrading a programming language I don't use, just so I can replace a perfectly good tool with one I don't want, in order to do a job that's always been easy to accomplish with the existing tools... well, that seems a lot like a solution in search of a problem. Fortunately, Alan's response about someone re-writing CML2 in C offers hope for at least part of the issue. Wayne - 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 design philosophy heads-up
On Fri, May 18, 2001 at 03:04:43PM -0500, [EMAIL PROTECTED] wrote: > 1. Some of us are perfectly satisfied with the existing tools and don't want > them to be yanked out from under us. Then stay with 2.4.x > 2. Some of us have no interest in Python and don't like being forced to deal > with installing/upgrading it just for CML2. Some don't like installing/upgrading the following just for a kernel: gcc binutils modutils mount Not to mention netfilter. -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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 design philosophy heads-up
> On 05/18/2001 at 02:44:07 PM [EMAIL PROTECTED] wrote: > >But the real question is whether the old tools have enough value to be > >worth the effort. What problem are you trying to solve here? > > How about: > 1. Some of us are perfectly satisfied with the existing tools and don't want > them to be yanked out from under us. > 2. Some of us have no interest in Python and don't like being forced to deal > with installing/upgrading it just for CML2. Since someone is rewriting CML2 in C that #2 is a non issue. #1 may be a case of bolting alternative ui's onto the parser - 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 design philosophy heads-up
> But the real question is whether the old tools have enough value to be > worth the effort. What problem are you trying to solve here? Im just playing with ideas and writing a CML1 parser for amusement while I ponder single pass computation of the entire dependancy graph from a CML1 rule base 8) - 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 design philosophy heads-up
Alan Cox <[EMAIL PROTECTED]>: > Being able to turn CML2 into CML1 might be the more useful exercise. That's...not a completely crazy idea. Hmmm... It might be possible to take a CML2 rulebase and generate a sort of stupid jackleg CML1 translation of it. The resulting config.in would be huge and nasty, and would only work in forward sequence with no side-effect computation, but you just might be able to get the old tools to parse it. Again there's a technical problem with derivations. Probably solvable. But the real question is whether the old tools have enough value to be worth the effort. What problem are you trying to solve here? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. - 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 design philosophy heads-up
> For CML1 and CML2 to handle the same language, we would either have > to live with the CML1 language's limitations or retrofit the old tools > to speak CML2 language. The chance of the latter happening is, I think > we can agree, effectively zero. Being able to turn CML2 into CML1 might be the more useful exercise. 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 design philosophy heads-up
Christoph Hellwig wrote: > That's ok as long as she doesn't add backstreet boys songtexts as long as your > signature to her mails. In fact, they aren't so long once you cut out the repetitions. > On the other hand she should _really_ learn how to do it - like we all did. Hey, nothing stops you from buying a used front panel and toggling in Linux in octal. Oughta work the first time, too. -- There is / one art || John Cowan <[EMAIL PROTECTED]> no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein - 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 design philosophy heads-up
On Fri, May 18, 2001 at 01:22:35PM -0400, Eric S. Raymond wrote: > Michael Meissner <[EMAIL PROTECTED]>: > > On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: > > > Aunt Tillie shouldn't try to manually configure a kernel. > > > > Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After > > all, all of us at one point in time were newbies in terms of configuring > > kernels, etc. > > And if she doesn't, maybe her teenage daughter Muffy wants to learn. You know, > the one with the unicorn appliques and the pink scrunchies and the Back Street > Boys posters in her bedroom? That's ok as long as she doesn't add backstreet boys songtexts as long as your signature to her mails. On the other hand she should _really_ learn how to do it - like we all did. > Dammit, if we're serious about empowering people with free software we can't > limit ourselves with the attitude that configuring kernels (or anything > else) is the sacred preserve of a geek elite. I see _no_ reason to give up my control for people with an attitude that configuring kernels will not need knowledge of what one is doing. Your point is basically: Lets rewrite the kernel in VBA to make every word user capable of driver hacking. That doesn't work. Christoph -- Auch der Dumme hat manchmal einen gescheiten Gedanken. Er merkt es nur nicht. -- Danny Kaye - 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 design philosophy heads-up
> Do you really believe that anyone is going to maintain the CML1 tools > for as long as a nanosecond after they get dropped out of the kernel tree? Do you really believe anyone would be dumb enough to delete them out of spite or to further your political machinations if they could both handle the same configuration language. CML1 has had no official maintainer for about 4 years. People contribute bits and it works. So as it stands there would be no reason to remove 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: [kbuild-devel] Re: CML2 design philosophy heads-up
In article <[EMAIL PROTECTED]> you wrote: > On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote: >> Christoph Hellwig wrote: [my voice was snipped here] >> Yes, I should have limited myself to pre-egcs versions. > > Huh? > > It's been possible to have multiple versions of gcc installed for a very > long time. At least since 2.0 came out. > > Thu Dec 19 15:54:29 1991 K. Richard Pixley (rich at cygnus.com) > > * configure: added -V for version number option. But with at least the combination of gcc2.7.2.x and egcs1.x it did not work for me (and others). Christoph -- Whip me. Beat me. Make me maintain AIX. - 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 design philosophy heads-up
On Fri, May 18, 2001 at 01:17:07PM -0400, Eric S. Raymond wrote: > It's been an ugly, nasty, horrible job -- *much* nastier, by an order > of magnitude, than designing and writing the CML2 engine. Going the > other direction would be worse. "Like chewing razor blades" is the > simile that leaps to mind. And you hope this will not be razorblades if Linus decides he likes CML2 ? > (And no, dropping back to CML1 format for the masters wouldn't be an > option; it doesn't have the semantic strength to enable CML2's new > capabilities.) Right now, it's now a dropping back. You seem to take for granted that CML2 and your python2 frontend to it are 2.5.0 material. I don't right now. - 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 design philosophy heads-up
Arjan van de Ven <[EMAIL PROTECTED]>: > I hereby volunteer to maintain at least make oldconfig and make config, > and perhaps make menuconfig. That's the easy part; the CML1 config code may be ugly and broken, but at least it's relatively stable. What you'd also have to do is maintain an entire CML1 ruleset in parallel with the canonical CML2 one. That's the hard part. I've been keeping the CML2 ruleset synced with CML1 for a year now. It's been an ugly, nasty, horrible job -- *much* nastier, by an order of magnitude, than designing and writing the CML2 engine. Going the other direction would be worse. "Like chewing razor blades" is the simile that leaps to mind. (And no, dropping back to CML1 format for the masters wouldn't be an option; it doesn't have the semantic strength to enable CML2's new capabilities.) -- http://www.tuxedo.org/~esr/;>Eric S. Raymond Certainly one of the chief guarantees of freedom under any government, no matter how popular and respected, is the right of the citizens to keep and bear arms. [...] the right of the citizens to bear arms is just one guarantee against arbitrary government and one more safeguard against a tyranny which now appears remote in America, but which historically has proved to be always possible. -- Hubert H. Humphrey, 1960 - 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 design philosophy heads-up
On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote: > Christoph Hellwig wrote: > Yes, I should have limited myself to pre-egcs versions. Huh? It's been possible to have multiple versions of gcc installed for a very long time. At least since 2.0 came out. Thu Dec 19 15:54:29 1991 K. Richard Pixley (rich at cygnus.com) * configure: added -V for version number option. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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 design philosophy heads-up
Michael Meissner <[EMAIL PROTECTED]>: > On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: > > Aunt Tillie shouldn't try to manually configure a kernel. > > Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After > all, all of us at one point in time were newbies in terms of configuring > kernels, etc. And if she doesn't, maybe her teenage daughter Muffy wants to learn. You know, the one with the unicorn appliques and the pink scrunchies and the Back Street Boys posters in her bedroom? Dammit, if we're serious about empowering people with free software we can't limit ourselves with the attitude that configuring kernels (or anything else) is the sacred preserve of a geek elite. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The price of liberty is, always has been, and always will be blood. The person who is not willing to die for his liberty has already lost it to the first scoundrel who is willing to risk dying to violate that person's liberty. Are you free? -- Andrew Ford - 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 design philosophy heads-up
Arjan van de Ven <[EMAIL PROTECTED]>: > Right now, it's now a dropping back. You seem to take for granted that CML2 > and your python2 frontend to it are 2.5.0 material. I don't right now. Linus is free to change his mind. Perhaps he will. But the last word I heard from him is that CML2 goes in in the 2.5.1-2.5.2 timeframe. That's the assumption I'm operating on. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond An armed society is a polite society. Manners are good when one may have to back up his acts with his life. -- Robert A. Heinlein, "Beyond This Horizon", 1942 - 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 design philosophy heads-up
On 05/18/2001 at 11:45:40 AM [EMAIL PROTECTED] wrote: >I hereby volunteer to maintain at least make oldconfig and make config, >and perhaps make menuconfig. THANK YOU THANK YOU THANK YOU!!! I'm quite happy with the current form of oldconfig and menuconfig, and will continue to use them as long as they're available. Wayne - 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 design philosophy heads-up
Michael Meissner wrote: > > On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: > > Aunt Tillie shouldn't try to manually configure a kernel. > > Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After > all, all of us at one point in time were newbies in terms of configuring And maybe she uses KDE and clicks kkernelconfigurator for the first steps. And if she wants to learn, she even might stumble on the HOWTO.. - 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 design philosophy heads-up
On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: > Aunt Tillie shouldn't try to manually configure a kernel. Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After all, all of us at one point in time were newbies in terms of configuring kernels, etc. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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 design philosophy heads-up
"Eric S. Raymond" wrote: > > It would. Because people who like the old config would continue to use the > > old tools > > Excuse me? > Do you really believe that anyone is going to maintain the CML1 tools > for as long as a nanosecond after they get dropped out of the kernel tree? I hereby volunteer to maintain at least make oldconfig and make config, and perhaps make menuconfig. > Even supposing somebody were loony enough to do that, how would preserving > an old interface in amber do anything to explore new UI possibilities? kernel != GUI There are plenty of UI kernel configurators out there. Good ones. Bad ones. LOOK AT THEM. FIX THEM if you don't like them. But PLEASE don't even think about taking the current, very useful for advanced users, tools away without offering something of at least the same capabilities. > Perhaps I'm just unusually dense this morning. Given the rest of this thread, unusual is not the word that comes to my mind (sorry, open door and you asked for 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: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote: > Alan, it sounds very much like you just said something stupid. This > seems sufficiently unlikely that I am shaking my head in disbelief and > fingernailing wax out of both ears (and if you think doing both those > things at once is easy try it sometime :-)). > > Do you really believe that anyone is going to maintain the CML1 tools > for as long as a nanosecond after they get dropped out of the kernel tree? I _will_ continue to maintain mconfig (after mec stopped even before cml2). 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 design philosophy heads-up
Alan Cox <[EMAIL PROTECTED]>: > > I think you're confusing a couple of different issues here, Alan. Even > > supposing CML2 could parse CML1 rulesets, the design question about how > > configuration *should* work (that is, what kind of user experience we > > want to create and who we optimize ruleset design for) wouldn't go away. > > It would. Because people who like the old config would continue to use the > old tools Excuse me? Alan, it sounds very much like you just said something stupid. This seems sufficiently unlikely that I am shaking my head in disbelief and fingernailing wax out of both ears (and if you think doing both those things at once is easy try it sometime :-)). Do you really believe that anyone is going to maintain the CML1 tools for as long as a nanosecond after they get dropped out of the kernel tree? Even supposing somebody were loony enough to do that, how would preserving an old interface in amber do anything to explore new UI possibilities? Perhaps I'm just unusually dense this morning. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond Alcohol still kills more people every year than all `illegal' drugs put together, and Prohibition only made it worse. Oppose the War On Some Drugs! - 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 design philosophy heads-up
On Friday 18 May 2001 09:19, Jes Sorensen wrote: > Replacing the code does not require changing the style of the config > files. Thats a major problem with CML2, you introduce a new 'let me do > everything for you' tool that relies on a programming language that is > not being shipped by any major vendor nor does it look like they are > planning to do it anytime soon. And even if they start doing so, this Actually, Linux-Mandrake 8.0 ships with Python 2.0, but your next point is a very good one: > is a totally unreasonable requirement, you *must* to make it possible > to compile kernels on older distributions without requiring people to > update half of their system. On some architectures, the majority of > the users are still on glibc 2.0 and other old versions of > tools. Telling them to install an updated gcc for kernel compilation > is a necessary evil, which can easily be done without disturbing the > rest of the system. Updating the system's python installation is not a > reasonable request. Nobody disagrees that the Makefiles needs a > redesign, however that doesn't mean everything else has to be > redisigned in a totally incompatible manner. I didn't have trouble installing python 2.0 before LM 8.0 did that for me, but I was probably just lucky. I've seen some reports by other people who did have difficulty upgrading python. If the python installation difficulties are a real obstacle, perhaps that is what needs to be fixed. 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 design philosophy heads-up
On Fri, May 18, 2001 at 12:04:34PM -0400, Eric S. Raymond wrote: > Alan Cox <[EMAIL PROTECTED]>: > > > I don't want to do (a); it conflicts with my design objective of > > > simplifying configuration enough that Aunt Tillie can do it. I won't > > > do that unless I see a strong consensus that it's the only Right Thing. > > > > Its a good way of getting the defaults right. It may also be an appropriate > > way of guiding presentation (eg putting the stuff the ruleset says you wont > > have under a subcategory so you would see > > > > > > CPU type > > Devices > > blah > > blah > > Other Options > > IDE disk > > Cardbus > > I want to understand what you're driving at here and I don't get it. What's > the referent of "Its"? Are you saying you think Aunt Tillie's view of the > world should guide the presentation of options? Aunt Tillie shouldn't try to manually configure a kernel. Christoph P.S. _please_ shorten your .sig -- Whip me. Beat me. Make me maintain AIX. - 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 design philosophy heads-up
On Fri, 18 May 2001, Eric S. Raymond wrote: > That being the case, we do face a question of design > philosophy, expressed as a policy question about how to design > rulesets. Actually two questions: > > 1. When we have a platform symbol for a reference design like MVME147, do >we stick to its spec sheet or consider it representative of all derivatives >(which may have other facilities)? > > I know my answer to this one, which I will implement unless there's > strong consensus otherwise. I go for explicitness. If we're going to > support MVME147 derivatives and variants in the ruleset, they get > their own platform symbols. I believe it's important two distinguish between two things here, auto-configuration and normal configuration. One should take care to not mix these things up. Of course I don't know about the specific hardware there, but I believe selecting NVME147 will give you arch specific code which will cope with general aspects of that board, but also for derived designs. That makes sense, and no need to introduce different config symbols at that level. I'd call CONFIG symbols like that basic, and they should be described by a ruleset which ensures that building the kernel will actually work, and that you have a chance that it even runs. (Things like a SCSI driver requires the SCSI midlayer, etc. which would normally lead to unresolved symbols or the inability to load the driver module into the running kernel later). On the other hand, for some people it would be nice to say I've got the reference board, build the right kernel. That's okay, but it should be another option, and rules like that should be in a separate files, so they don't clutter up the "basic" rulesets. So, leave the flexibility to people who need, and on top of that you can have a mechanism which allows easier configuration for people who don't want to care about the details. However, more important there would be some option like "build me a kernel for the hardware I'm currently running on" (and let the user fine tune afterwards). --Kai - 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 design philosophy heads-up
> I think you're confusing a couple of different issues here, Alan. Even > supposing CML2 could parse CML1 rulesets, the design question about how > configuration *should* work (that is, what kind of user experience we > want to create and who we optimize ruleset design for) wouldn't go away. It would. Because people who like the old config would continue to use the old tools 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 design philosophy heads-up
On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote: > Jes Sorensen wrote: > > > Telling them to install an updated gcc for kernel compilation > > is a necessary evil, which can easily be done without disturbing the > > rest of the system. Updating the system's python installation is not a > > reasonable request. > > > Au contraire. It is very reasonable to have both python and python2 > installed. Having two different gcc versions installed is a big pain > in the arse. Fump. Some distributions do even come with two gcc's out of the box. With the whole egcs and gcc2.95 (dunno about 3.0) you can even share the compiler driver if you want. 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 design philosophy heads-up
Christoph Hellwig wrote: > On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote: > >>Jes Sorensen wrote: >> >> >>>Telling them to install an updated gcc for kernel compilation >>>is a necessary evil, which can easily be done without disturbing the >>>rest of the system. Updating the system's python installation is not a >>>reasonable request. >>> >> >>Au contraire. It is very reasonable to have both python and python2 >>installed. Having two different gcc versions installed is a big pain >>in the arse. >> > > Fump. Some distributions do even come with two gcc's out of the box. > With the whole egcs and gcc2.95 (dunno about 3.0) you can even share > the compiler driver if you want. Yes, I should have limited myself to pre-egcs versions. -- There is / one art || John Cowan <[EMAIL PROTECTED]> no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein - 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 design philosophy heads-up
Alan Cox <[EMAIL PROTECTED]>: > > In general this is the best option, if you create a non-standard > > configuration for machine foo then it is your problem, not everybody > > else's. > > Which makes CML2 inferior to CML1 again. Now if it could parse CML1 rulesets > this whole discussion wouldn't be needed. I think you're confusing a couple of different issues here, Alan. Even supposing CML2 could parse CML1 rulesets, the design question about how configuration *should* work (that is, what kind of user experience we want to create and who we optimize ruleset design for) wouldn't go away. I'm raising these questions now because CML2's capabilities invite thinking about them. But they're independent of the underlying language. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond To stay young requires the unceasing cultivation of the ability to unlearn old falsehoods. -- Lazarus Long - 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 design philosophy heads-up
Eric S. Raymond wrote: It would. Because people who like the old config would continue to use the old tools Excuse me? Do you really believe that anyone is going to maintain the CML1 tools for as long as a nanosecond after they get dropped out of the kernel tree? I hereby volunteer to maintain at least make oldconfig and make config, and perhaps make menuconfig. Even supposing somebody were loony enough to do that, how would preserving an old interface in amber do anything to explore new UI possibilities? kernel != GUI There are plenty of UI kernel configurators out there. Good ones. Bad ones. LOOK AT THEM. FIX THEM if you don't like them. But PLEASE don't even think about taking the current, very useful for advanced users, tools away without offering something of at least the same capabilities. Perhaps I'm just unusually dense this morning. Given the rest of this thread, unusual is not the word that comes to my mind (sorry, open door and you asked for 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: [kbuild-devel] Re: CML2 design philosophy heads-up
Michael Meissner wrote: On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: Aunt Tillie shouldn't try to manually configure a kernel. Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After all, all of us at one point in time were newbies in terms of configuring And maybe she uses KDE and clicks kkernelconfigurator for the first steps. And if she wants to learn, she even might stumble on the HOWTO.. - 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 design philosophy heads-up
On 05/18/2001 at 11:45:40 AM [EMAIL PROTECTED] wrote: I hereby volunteer to maintain at least make oldconfig and make config, and perhaps make menuconfig. THANK YOU THANK YOU THANK YOU!!! I'm quite happy with the current form of oldconfig and menuconfig, and will continue to use them as long as they're available. Wayne - 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 design philosophy heads-up
Arjan van de Ven [EMAIL PROTECTED]: Right now, it's now a dropping back. You seem to take for granted that CML2 and your python2 frontend to it are 2.5.0 material. I don't right now. Linus is free to change his mind. Perhaps he will. But the last word I heard from him is that CML2 goes in in the 2.5.1-2.5.2 timeframe. That's the assumption I'm operating on. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a An armed society is a polite society. Manners are good when one may have to back up his acts with his life. -- Robert A. Heinlein, Beyond This Horizon, 1942 - 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 design philosophy heads-up
On Fri, May 18, 2001 at 01:17:07PM -0400, Eric S. Raymond wrote: It's been an ugly, nasty, horrible job -- *much* nastier, by an order of magnitude, than designing and writing the CML2 engine. Going the other direction would be worse. Like chewing razor blades is the simile that leaps to mind. And you hope this will not be razorblades if Linus decides he likes CML2 ? (And no, dropping back to CML1 format for the masters wouldn't be an option; it doesn't have the semantic strength to enable CML2's new capabilities.) Right now, it's now a dropping back. You seem to take for granted that CML2 and your python2 frontend to it are 2.5.0 material. I don't right now. - 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 design philosophy heads-up
Arjan van de Ven [EMAIL PROTECTED]: I hereby volunteer to maintain at least make oldconfig and make config, and perhaps make menuconfig. That's the easy part; the CML1 config code may be ugly and broken, but at least it's relatively stable. What you'd also have to do is maintain an entire CML1 ruleset in parallel with the canonical CML2 one. That's the hard part. I've been keeping the CML2 ruleset synced with CML1 for a year now. It's been an ugly, nasty, horrible job -- *much* nastier, by an order of magnitude, than designing and writing the CML2 engine. Going the other direction would be worse. Like chewing razor blades is the simile that leaps to mind. (And no, dropping back to CML1 format for the masters wouldn't be an option; it doesn't have the semantic strength to enable CML2's new capabilities.) -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Certainly one of the chief guarantees of freedom under any government, no matter how popular and respected, is the right of the citizens to keep and bear arms. [...] the right of the citizens to bear arms is just one guarantee against arbitrary government and one more safeguard against a tyranny which now appears remote in America, but which historically has proved to be always possible. -- Hubert H. Humphrey, 1960 - 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 design philosophy heads-up
On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote: Christoph Hellwig wrote: Yes, I should have limited myself to pre-egcs versions. Huh? It's been possible to have multiple versions of gcc installed for a very long time. At least since 2.0 came out. Thu Dec 19 15:54:29 1991 K. Richard Pixley (rich at cygnus.com) * configure: added -V for version number option. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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 design philosophy heads-up
In article [EMAIL PROTECTED] you wrote: On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote: Christoph Hellwig wrote: [my voice was snipped here] Yes, I should have limited myself to pre-egcs versions. Huh? It's been possible to have multiple versions of gcc installed for a very long time. At least since 2.0 came out. Thu Dec 19 15:54:29 1991 K. Richard Pixley (rich at cygnus.com) * configure: added -V for version number option. But with at least the combination of gcc2.7.2.x and egcs1.x it did not work for me (and others). Christoph -- Whip me. Beat me. Make me maintain AIX. - 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 design philosophy heads-up
On Fri, May 18, 2001 at 03:04:43PM -0500, [EMAIL PROTECTED] wrote: 1. Some of us are perfectly satisfied with the existing tools and don't want them to be yanked out from under us. Then stay with 2.4.x 2. Some of us have no interest in Python and don't like being forced to deal with installing/upgrading it just for CML2. Some don't like installing/upgrading the following just for a kernel: gcc binutils modutils mount Not to mention netfilter. -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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 design philosophy heads-up
On 05/18/2001 at 03:56:50 PM Mike Castle [EMAIL PROTECTED] wrote: On Fri, May 18, 2001 at 03:04:43PM -0500, [EMAIL PROTECTED] wrote: 1. Some of us are perfectly satisfied with the existing tools and don't want them to be yanked out from under us. Then stay with 2.4.x Since doing kernel upgrades is my whole reason for using the tools, that's not a very helpful suggestion. It's a little like saying, If you don't like the way the air smells, just stop breathing. 2. Some of us have no interest in Python and don't like being forced to deal with installing/upgrading it just for CML2. Some don't like installing/upgrading the following just for a kernel: gcc binutils modutils mount Not to mention netfilter. I don't especially like upgrading these things, either, and don't do it unless I absolutely have to (that's why I'm still on egcs-2.91.66), but the kernel is important enough to be worth the trouble. If I have to use CML2 to move into 2.5.x, then I will. However, upgrading a programming language I don't use, just so I can replace a perfectly good tool with one I don't want, in order to do a job that's always been easy to accomplish with the existing tools... well, that seems a lot like a solution in search of a problem. Fortunately, Alan's response about someone re-writing CML2 in C offers hope for at least part of the issue. Wayne - 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 design philosophy heads-up
On Fri, May 18, 2001 at 12:04:34PM -0400, Eric S. Raymond wrote: Alan Cox [EMAIL PROTECTED]: I don't want to do (a); it conflicts with my design objective of simplifying configuration enough that Aunt Tillie can do it. I won't do that unless I see a strong consensus that it's the only Right Thing. Its a good way of getting the defaults right. It may also be an appropriate way of guiding presentation (eg putting the stuff the ruleset says you wont have under a subcategory so you would see CPU type Devices blah blah Other Options IDE disk Cardbus I want to understand what you're driving at here and I don't get it. What's the referent of Its? Are you saying you think Aunt Tillie's view of the world should guide the presentation of options? Aunt Tillie shouldn't try to manually configure a kernel. Christoph P.S. _please_ shorten your .sig -- Whip me. Beat me. Make me maintain AIX. - 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 design philosophy heads-up
Arjan van de Ven wrote: Eric S. Raymond wrote: an old interface in amber do anything to explore new UI possibilities? kernel != GUI UI != GUI -- One trend that bothers me is the glorification of stupidity, that the media is reassuring people it's alright not to know anything. That to me is far more dangerous than a little pornography on the Internet. - Carl Sagan - 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 design philosophy heads-up
For CML1 and CML2 to handle the same language, we would either have to live with the CML1 language's limitations or retrofit the old tools to speak CML2 language. The chance of the latter happening is, I think we can agree, effectively zero. Being able to turn CML2 into CML1 might be the more useful exercise. 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 design philosophy heads-up
Alan Cox [EMAIL PROTECTED]: In general this is the best option, if you create a non-standard configuration for machine foo then it is your problem, not everybody else's. Which makes CML2 inferior to CML1 again. Now if it could parse CML1 rulesets this whole discussion wouldn't be needed. I think you're confusing a couple of different issues here, Alan. Even supposing CML2 could parse CML1 rulesets, the design question about how configuration *should* work (that is, what kind of user experience we want to create and who we optimize ruleset design for) wouldn't go away. I'm raising these questions now because CML2's capabilities invite thinking about them. But they're independent of the underlying language. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a To stay young requires the unceasing cultivation of the ability to unlearn old falsehoods. -- Lazarus Long - 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 design philosophy heads-up
On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote: Alan, it sounds very much like you just said something stupid. This seems sufficiently unlikely that I am shaking my head in disbelief and fingernailing wax out of both ears (and if you think doing both those things at once is easy try it sometime :-)). Do you really believe that anyone is going to maintain the CML1 tools for as long as a nanosecond after they get dropped out of the kernel tree? I _will_ continue to maintain mconfig (after mec stopped even before cml2). 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 design philosophy heads-up
On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: Aunt Tillie shouldn't try to manually configure a kernel. Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After all, all of us at one point in time were newbies in terms of configuring kernels, etc. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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 design philosophy heads-up
Christoph Hellwig wrote: That's ok as long as she doesn't add backstreet boys songtexts as long as your signature to her mails. In fact, they aren't so long once you cut out the repetitions. On the other hand she should _really_ learn how to do it - like we all did. Hey, nothing stops you from buying a used front panel and toggling in Linux in octal. Oughta work the first time, too. -- There is / one art || John Cowan [EMAIL PROTECTED] no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein - 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 design philosophy heads-up
Michael Meissner [EMAIL PROTECTED]: On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: Aunt Tillie shouldn't try to manually configure a kernel. Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After all, all of us at one point in time were newbies in terms of configuring kernels, etc. And if she doesn't, maybe her teenage daughter Muffy wants to learn. You know, the one with the unicorn appliques and the pink scrunchies and the Back Street Boys posters in her bedroom? Dammit, if we're serious about empowering people with free software we can't limit ourselves with the attitude that configuring kernels (or anything else) is the sacred preserve of a geek elite. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The price of liberty is, always has been, and always will be blood. The person who is not willing to die for his liberty has already lost it to the first scoundrel who is willing to risk dying to violate that person's liberty. Are you free? -- Andrew Ford - 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 design philosophy heads-up
On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote: Even supposing somebody were loony enough to do that, how would preserving an old interface in amber do anything to explore new UI possibilities? I don't know about the rest of the world, but I _much_ prefer the old menuconfig to CML2's menuconfig. While I haven't spent much time playing with CML2, I'm familiar with cml1's tools and see no reason why they need changes, which IMHO (so far) are detrimental. That's not even to mention python issues, speed, or anything else. - 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 design philosophy heads-up
On Fri, May 18, 2001 at 01:22:35PM -0400, Eric S. Raymond wrote: Michael Meissner [EMAIL PROTECTED]: On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: Aunt Tillie shouldn't try to manually configure a kernel. Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After all, all of us at one point in time were newbies in terms of configuring kernels, etc. And if she doesn't, maybe her teenage daughter Muffy wants to learn. You know, the one with the unicorn appliques and the pink scrunchies and the Back Street Boys posters in her bedroom? That's ok as long as she doesn't add backstreet boys songtexts as long as your signature to her mails. On the other hand she should _really_ learn how to do it - like we all did. Dammit, if we're serious about empowering people with free software we can't limit ourselves with the attitude that configuring kernels (or anything else) is the sacred preserve of a geek elite. I see _no_ reason to give up my control for people with an attitude that configuring kernels will not need knowledge of what one is doing. Your point is basically: Lets rewrite the kernel in VBA to make every word user capable of driver hacking. That doesn't work. Christoph -- Auch der Dumme hat manchmal einen gescheiten Gedanken. Er merkt es nur nicht. -- Danny Kaye - 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 design philosophy heads-up
On Fri, 18 May 2001, Eric S. Raymond wrote: That being the case, we do face a question of design philosophy, expressed as a policy question about how to design rulesets. Actually two questions: 1. When we have a platform symbol for a reference design like MVME147, do we stick to its spec sheet or consider it representative of all derivatives (which may have other facilities)? I know my answer to this one, which I will implement unless there's strong consensus otherwise. I go for explicitness. If we're going to support MVME147 derivatives and variants in the ruleset, they get their own platform symbols. I believe it's important two distinguish between two things here, auto-configuration and normal configuration. One should take care to not mix these things up. Of course I don't know about the specific hardware there, but I believe selecting NVME147 will give you arch specific code which will cope with general aspects of that board, but also for derived designs. That makes sense, and no need to introduce different config symbols at that level. I'd call CONFIG symbols like that basic, and they should be described by a ruleset which ensures that building the kernel will actually work, and that you have a chance that it even runs. (Things like a SCSI driver requires the SCSI midlayer, etc. which would normally lead to unresolved symbols or the inability to load the driver module into the running kernel later). On the other hand, for some people it would be nice to say I've got the reference board, build the right kernel. That's okay, but it should be another option, and rules like that should be in a separate files, so they don't clutter up the basic rulesets. So, leave the flexibility to people who need, and on top of that you can have a mechanism which allows easier configuration for people who don't want to care about the details. However, more important there would be some option like build me a kernel for the hardware I'm currently running on (and let the user fine tune afterwards). --Kai - 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 design philosophy heads-up
On 05/18/2001 at 02:44:07 PM [EMAIL PROTECTED] wrote: But the real question is whether the old tools have enough value to be worth the effort. What problem are you trying to solve here? How about: 1. Some of us are perfectly satisfied with the existing tools and don't want them to be yanked out from under us. 2. Some of us have no interest in Python and don't like being forced to deal with installing/upgrading it just for CML2. Since someone is rewriting CML2 in C that #2 is a non issue. #1 may be a case of bolting alternative ui's onto the parser - 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 design philosophy heads-up
On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote: Jes Sorensen wrote: Telling them to install an updated gcc for kernel compilation is a necessary evil, which can easily be done without disturbing the rest of the system. Updating the system's python installation is not a reasonable request. Au contraire. It is very reasonable to have both python and python2 installed. Having two different gcc versions installed is a big pain in the arse. Fump. Some distributions do even come with two gcc's out of the box. With the whole egcs and gcc2.95 (dunno about 3.0) you can even share the compiler driver if you want. 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 design philosophy heads-up
But the real question is whether the old tools have enough value to be worth the effort. What problem are you trying to solve here? Im just playing with ideas and writing a CML1 parser for amusement while I ponder single pass computation of the entire dependancy graph from a CML1 rule base 8) - 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 design philosophy heads-up
On Friday 18 May 2001 09:19, Jes Sorensen wrote: Replacing the code does not require changing the style of the config files. Thats a major problem with CML2, you introduce a new 'let me do everything for you' tool that relies on a programming language that is not being shipped by any major vendor nor does it look like they are planning to do it anytime soon. And even if they start doing so, this Actually, Linux-Mandrake 8.0 ships with Python 2.0, but your next point is a very good one: is a totally unreasonable requirement, you *must* to make it possible to compile kernels on older distributions without requiring people to update half of their system. On some architectures, the majority of the users are still on glibc 2.0 and other old versions of tools. Telling them to install an updated gcc for kernel compilation is a necessary evil, which can easily be done without disturbing the rest of the system. Updating the system's python installation is not a reasonable request. Nobody disagrees that the Makefiles needs a redesign, however that doesn't mean everything else has to be redisigned in a totally incompatible manner. I didn't have trouble installing python 2.0 before LM 8.0 did that for me, but I was probably just lucky. I've seen some reports by other people who did have difficulty upgrading python. If the python installation difficulties are a real obstacle, perhaps that is what needs to be fixed. 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 design philosophy heads-up
Alan Cox [EMAIL PROTECTED]: I think you're confusing a couple of different issues here, Alan. Even supposing CML2 could parse CML1 rulesets, the design question about how configuration *should* work (that is, what kind of user experience we want to create and who we optimize ruleset design for) wouldn't go away. It would. Because people who like the old config would continue to use the old tools Excuse me? Alan, it sounds very much like you just said something stupid. This seems sufficiently unlikely that I am shaking my head in disbelief and fingernailing wax out of both ears (and if you think doing both those things at once is easy try it sometime :-)). Do you really believe that anyone is going to maintain the CML1 tools for as long as a nanosecond after they get dropped out of the kernel tree? Even supposing somebody were loony enough to do that, how would preserving an old interface in amber do anything to explore new UI possibilities? Perhaps I'm just unusually dense this morning. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Alcohol still kills more people every year than all `illegal' drugs put together, and Prohibition only made it worse. Oppose the War On Some Drugs! - 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 design philosophy heads-up
Alan Cox [EMAIL PROTECTED]: Being able to turn CML2 into CML1 might be the more useful exercise. That's...not a completely crazy idea. Hmmm... It might be possible to take a CML2 rulebase and generate a sort of stupid jackleg CML1 translation of it. The resulting config.in would be huge and nasty, and would only work in forward sequence with no side-effect computation, but you just might be able to get the old tools to parse it. Again there's a technical problem with derivations. Probably solvable. But the real question is whether the old tools have enough value to be worth the effort. What problem are you trying to solve here? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. - 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 design philosophy heads-up
Do you really believe that anyone is going to maintain the CML1 tools for as long as a nanosecond after they get dropped out of the kernel tree? Do you really believe anyone would be dumb enough to delete them out of spite or to further your political machinations if they could both handle the same configuration language. CML1 has had no official maintainer for about 4 years. People contribute bits and it works. So as it stands there would be no reason to remove 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/
