Linus, the time has come to convert the 2.5 kernel to kbuild 2.5. I
want to do this in separate steps to make it easier for architectures
that have not been converted yet.
2.5.1 Semi-stable kernel, after bio is working.
2.5.2-pre1 Add the kbuild 2.5 code, still using Makefile-2.5.
i386, sparc, sparc64 can use either kbuild 2.4 or 2.5,
2.5 is recommended.
ia64 can only use kbuild 2.5.
Other architectures continue to use kbuild 2.4.
Wait 24 hours for any major problems then -
2.5.2-pre2 Remove kbuild 2.4 code, rename Makefile-2.5 to Makefile.
i386, ia64, sparc, sparc64 can compile using kbuild 2.5.
Other architectures cannot compile until they convert
to kbuild 2.5. The kbuild group can help with the
conversion but without access to a machine we cannot
test other architectures. Until the other archs have
been converted, they can stay on 2.5.2-pre1.
Doing the change in two steps provides a platform where both kbuild 2.4
and 2.5 work. This allows other architectures to parallel test the old
and new kbuild during their conversion, I found that ability was very
useful during conversion.
The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.
Linus, is this acceptable?
On Sun, 2 Dec 2001 20:19:46 -0500,
"Eric S. Raymond" <[email protected]> wrote:
>Keith Owens <[email protected]>:
>> The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.
>
>The schedule I heard from Linus at the kernel summit was that both changes
>were to go in between 2.5.1 and 2.5.2. I would prefer sooner than later
>because I'm *really* *tired* of maintaining a parallel rulebase.
I have not got CML2 support working in kbuild 2.5 so I left a bit of
room between kbuild 2.5 going in and cutting over to CML2. _If_ I can
get CML2 support working before 2.5.1 comes out then we go
2.5.2-pre1 Add kbuild 2.5 with both CML1 and CML2 support.
2.5.2-pre2 Remove kbuild 2.4.
2.5.2-pre3 Remove CML1.
2.5.2
I would prefer that sequence myself, but I don't want to promise a
timetable that I cannot deliver.
Keith Owens <[email protected]>:
> Linus, the time has come to convert the 2.5 kernel to kbuild 2.5. I
> want to do this in separate steps to make it easier for architectures
> that have not been converted yet.
>
> 2.5.1 Semi-stable kernel, after bio is working.
>
> 2.5.2-pre1 Add the kbuild 2.5 code, still using Makefile-2.5.
> i386, sparc, sparc64 can use either kbuild 2.4 or 2.5,
> 2.5 is recommended.
> ia64 can only use kbuild 2.5.
> Other architectures continue to use kbuild 2.4.
> Wait 24 hours for any major problems then -
>
> 2.5.2-pre2 Remove kbuild 2.4 code, rename Makefile-2.5 to Makefile.
> i386, ia64, sparc, sparc64 can compile using kbuild 2.5.
> Other architectures cannot compile until they convert
> to kbuild 2.5. The kbuild group can help with the
> conversion but without access to a machine we cannot
> test other architectures. Until the other archs have
> been converted, they can stay on 2.5.2-pre1.
>
> Doing the change in two steps provides a platform where both kbuild 2.4
> and 2.5 work. This allows other architectures to parallel test the old
> and new kbuild during their conversion, I found that ability was very
> useful during conversion.
>
> The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.
>
> Linus, is this acceptable?
The schedule I heard from Linus at the kernel summit was that both changes
were to go in between 2.5.1 and 2.5.2. I would prefer sooner than later
because I'm *really* *tired* of maintaining a parallel rulebase.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
A ``decay in the social contract'' is detectable; there is a growing
feeling, particularly among middle-income taxpayers, that they are not
getting back, from society and government, their money's worth for
taxes paid. The tendency is for taxpayers to try to take more control
of their finances ..
-- IRS Strategic Plan, (May 1984)
On Mon, 3 Dec 2001, Keith Owens wrote:
Hi Keith,
> _If_ I can get CML2 support working before 2.5.1 comes out then we go
> 2.5.2-pre1 Add kbuild 2.5 with both CML1 and CML2 support.
> 2.5.2-pre2 Remove kbuild 2.4.
Do you plan to fix the x2 slowdown before removing kbuild 2.4 ?
Or is this something that will be worked on as we progress through 2.5.
regards,
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Tue, 4 Dec 2001 01:22:52 +0100 (CET),
Dave Jones <[email protected]> wrote:
>Do you plan to fix the x2 slowdown before removing kbuild 2.4 ?
>Or is this something that will be worked on as we progress through 2.5.
It will be worked on during 2.5. I don't have time to rewrite the core
code _and_ track kernel releases for two kernel trees and 4
architectures at the same time. Putting kbuild 2.5 into the kernel
frees me to work on the speed up, otherwise it may never get done.
[email protected] said:
> The schedule I heard from Linus at the kernel summit was that both
> changes were to go in between 2.5.1 and 2.5.2. I would prefer
> sooner than later because I'm *really* *tired* of maintaining a
> parallel rulebase.
Is it not possible to write an automatic conversion tool that reads the
existing CML1 files and outputs CML2 rules with identical behaviour?
After all, the only way for the merge of CML2 to be acceptable is to merge
the tools _first_, without changing the resulting behaviour of the config
rules, and then to make behavioural changes in later versions.
--
dwmw2
David Woodhouse <[email protected]>:
>
> [email protected] said:
> > The schedule I heard from Linus at the kernel summit was that both
> > changes were to go in between 2.5.1 and 2.5.2. I would prefer
> > sooner than later because I'm *really* *tired* of maintaining a
> > parallel rulebase.
>
> Is it not possible to write an automatic conversion tool that reads the
> existing CML1 files and outputs CML2 rules with identical behaviour?
No, it's not.
Nobody wishes more than me that this had been possible, as the
parallel CML2 rulebase has been an energy sink you wouldn't believe --
it has eaten more of my time than any other single project I've been
involved with in the last two years.
Unfortunately, the syntax of CML1 is rebarbative, and its imperative
semantics cannot be mechanically translated to CML2's declarative
semantics by any means I'm aware of.
> After all, the only way for the merge of CML2 to be acceptable is to merge
> the tools _first_, without changing the resulting behaviour of the config
> rules, and then to make behavioural changes in later versions.
That's a different issue. The CML2 rulebase does produce behavior
substantially like that of the CML1 rulebase in most respects. There
are divergences due to the single-apex tree, but nothing that has caused
any of the beta testers a problem. I sweated blood to make it so.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Are we to understand," asked the judge, "that you hold your own interests
above the interests of the public?"
"I hold that such a question can never arise except in a society of cannibals."
-- Ayn Rand
> Is it not possible to write an automatic conversion tool that reads the
> existing CML1 files and outputs CML2 rules with identical behaviour?
Bad ones - yes. Its also possible to do everything CML2 does with the CML1
ruleset. All the information required is there. Howeve CML1 (all 4 dialects
of it) is pretty ugly
Alan Cox <[email protected]>:
> > Unfortunately, the syntax of CML1 is rebarbative, and its imperative
> > semantics cannot be mechanically translated to CML2's declarative
> > semantics by any means I'm aware of.
>
> The dependancy tree from CML1 is not that hard to obtain. It's not quite
> complete or correct though
That's right -- and the devil would be in the incomplete/incorrect
details. Areas of special pain: (1) cross-directory constraints, (2)
derivations, (3) multiple port tree apexes. These are all areas where
CML1 has design flaws that human coders get around by applying
higher-level knowledge of a kind a mechanical translator couldn't
have.
This is, alas, one of those cases where the first 90% of the problem looks
easy and the last 10% turns ought to be nigh-impossible -- and the
first 90% is useless without the last 10%.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Among the many misdeeds of British rule in India, history will look
upon the Act depriving a whole nation of arms as the blackest."
-- Mohandas Ghandhi, An Autobiography, pg 446
Christoph Hellwig <[email protected]>:
> There is a CML1 language specification, as written down in a file, namely
> Documentation/kbuild/config-language.txt in the kernel tree.
A specification which, according to its author, is incomplete.
> There is one tool (mconfig) which has a yacc-parser that implements that
> specification completly, and some horrid ugly scripts in the tree that
> parse them in a more or less working way. There also are a number of
> other tools I don't know to much about that understand the language as
> well.
N separate implementations means N dialects and N**2 compatibility problems.
Nicer just to have *one* parser, *one* compiler, and *one* service class that
supports several thin front-end layers, yes? No?
> All of these tools just require the runtime contained in the LSB and no
> funky additional script languages. Also none needs a binary intermediate
> representation of the config.
I quote Linus at the 2.5 kernel summit: "Python is not an issue."
Unless and until he changes his mind about that, waving around this
kind of argument is likely to do your case more harm than good.
If you want to re-open the case for saving CML1, you'd be better off
demonstrating how CML1 can be used to (a) automatically do implied
side-effects when a symbol is changed, (b) guarantee that the user
cannot generate a configuration that violates stated invariants, and
(c) unify the configuration tree so that the equivalents of arch/*
files never suffer from lag or skew when an architecture-independent
feature is added to the kernel.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Where rights secured by the Constitution are involved, there can be no
rule making or legislation which would abrogate them.
-- Miranda vs. Arizona, 384 US 436 p. 491
> Unfortunately, the syntax of CML1 is rebarbative, and its imperative
> semantics cannot be mechanically translated to CML2's declarative
> semantics by any means I'm aware of.
The dependancy tree from CML1 is not that hard to obtain. It's not quite
complete or correct though
On Tue, Dec 04, 2001 at 07:48:15AM -0500, Eric S. Raymond wrote:
> And, by the way, there is no CML1 :-). Instead, there are four
> mutually incompatible dialects and a rulebase that breaks in different
> ways depending on which interpreter you use. Well, maybe just three
> mutual incompatible dialects and one clone -- but it's notoriously
> hard to verify that two interpreters have the same accept language, so
> nobody knows for sure.
There is a CML1 language specification, as written down in a file, namely
Documentation/kbuild/config-language.txt in the kernel tree.
There is one tool (mconfig) which has a yacc-parser that implements that
specification completly, and some horrid ugly scripts in the tree that
parse them in a more or less working way. There also are a number of
other tools I don't know to much about that understand the language as
well.
All of these tools just require the runtime contained in the LSB and no
funky additional script languages. Also none needs a binary intermediate
representation of the config.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
On Tue, Dec 04, 2001 at 07:28:08AM -0500, Eric S. Raymond wrote:
> Christoph Hellwig <[email protected]>:
> > On Mon, Dec 03, 2001 at 12:06:12PM +1100, Keith Owens wrote:
> > > The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.
> >
> > Is the CML2 merge actually agreed on?
>
> Yes, unless Linus has changed his mind since March. Which would be his
> privilege, of course -- but since the CML1 maintainers are unanimous that
> CML1 is too kludgy to live and Linus knows that, it seems unlikely.
There is no CML1 maintainer. There are people maintaining the different
tools intepreting CML1. Some (e.g. the intree ones) are to ugly to consider,
others are pretty nice.
Christoph (current maintainer of a CML1 intepreter)
--
Of course it doesn't work. We've performed a software upgrade.
Christoph Hellwig <[email protected]>:
> On Mon, Dec 03, 2001 at 12:06:12PM +1100, Keith Owens wrote:
> > The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.
>
> Is the CML2 merge actually agreed on?
Yes, unless Linus has changed his mind since March. Which would be his
privilege, of course -- but since the CML1 maintainers are unanimous that
CML1 is too kludgy to live and Linus knows that, it seems unlikely.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
All governments are more or less combinations against the
people. . .and as rulers have no more virtue than the ruled. . .
the power of government can only be kept within its constituted
bounds by the display of a power equal to itself, the collected
sentiment of the people.
-- Benjamin Franklin Bache, in a Phildelphia Aurora editorial 1794
On Tue, Dec 04, 2001 at 08:16:40AM -0500, Eric S. Raymond wrote:
> N separate implementations means N dialects and N**2 compatibility problems.
> Nicer just to have *one* parser, *one* compiler, and *one* service class that
> supports several thin front-end layers, yes? No?
Oh man. When you think one implementation of a 'standard' is better then
multiple go to the MS world.
> > All of these tools just require the runtime contained in the LSB and no
> > funky additional script languages. Also none needs a binary intermediate
> > representation of the config.
>
> I quote Linus at the 2.5 kernel summit: "Python is not an issue."
> Unless and until he changes his mind about that, waving around this
> kind of argument is likely to do your case more harm than good.
For me (and others) it is an issues.
> If you want to re-open the case for saving CML1, you'd be better off
> demonstrating how CML1 can be used to (a) automatically do implied
> side-effects when a symbol is changed,
With mconfig it can be implemented easily - I don't see the point in
doing it, though.
> (b) guarantee that the user
> cannot generate a configuration that violates stated invariants, and
What do you mean with that?
> (c) unify the configuration tree so that the equivalents of arch/*
> files never suffer from lag or skew when an architecture-independent
> feature is added to the kernel.
One toplevel config file can be implemented in CML1 easily,
using mconfig or the old and ugly tools, it's just a question of changeing
the rule base in tree.
At last Alan think multiple toplevel files are a feature, not a bug
(I don't agree with him on that) so it's a completly separate discussion.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
Christoph Hellwig <[email protected]>:
> There is no CML1 maintainer. There are people maintaining the different
> tools intepreting CML1. Some (e.g. the intree ones) are to ugly to consider,
> others are pretty nice.
I was referring to Michael Elizabeth Chastain, Keith Owens, and the other
people on the kbuild list who officially maintain the CML1 tools in the
kernel tree. The same people who took up my offer to attempt a better
alternative to CML1 eighteen months ago.
And, by the way, there is no CML1 :-). Instead, there are four
mutually incompatible dialects and a rulebase that breaks in different
ways depending on which interpreter you use. Well, maybe just three
mutual incompatible dialects and one clone -- but it's notoriously
hard to verify that two interpreters have the same accept language, so
nobody knows for sure.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"The state calls its own violence `law', but that of the individual `crime'"
-- Max Stirner
On Mon, Dec 03, 2001 at 12:06:12PM +1100, Keith Owens wrote:
> The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.
Is the CML2 merge actually agreed on?
I still strongly object to it and I know lots of kernel hackers are
the same opinion.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
On Tue, Dec 04, 2001 at 02:29:58PM +0100, Christoph Hellwig wrote:
> On Tue, Dec 04, 2001 at 08:16:40AM -0500, Eric S. Raymond wrote:
> > N separate implementations means N dialects and N**2 compatibility problems.
> > Nicer just to have *one* parser, *one* compiler, and *one* service class that
> > supports several thin front-end layers, yes? No?
>
> Oh man. When you think one implementation of a 'standard' is better then
> multiple go to the MS world.
Wouldn't multiple tools which don't quite work to a 'standard' better
represent the MS world? Which is what all of the cml1 tools do.
> > > All of these tools just require the runtime contained in the LSB and no
> > > funky additional script languages. Also none needs a binary intermediate
> > > representation of the config.
> >
> > I quote Linus at the 2.5 kernel summit: "Python is not an issue."
> > Unless and until he changes his mind about that, waving around this
> > kind of argument is likely to do your case more harm than good.
>
> For me (and others) it is an issues.
Why?
> > If you want to re-open the case for saving CML1, you'd be better off
> > demonstrating how CML1 can be used to (a) automatically do implied
> > side-effects when a symbol is changed,
>
> With mconfig it can be implemented easily - I don't see the point in
> doing it, though.
To show that CML1 doesn't need to die yet.
> > (b) guarantee that the user
> > cannot generate a configuration that violates stated invariants, and
>
> What do you mean with that?
That you can't turn on CONFIG_FOO_BAR unless CONFIG_FOO is on. This is
getting at things like USB V4L devices which need CONFIG_USB and
CONFIG_VIDEODEV set to !n. This is done poorly in CML1.
> > (c) unify the configuration tree so that the equivalents of arch/*
> > files never suffer from lag or skew when an architecture-independent
> > feature is added to the kernel.
>
> One toplevel config file can be implemented in CML1 easily,
> using mconfig or the old and ugly tools, it's just a question of changeing
> the rule base in tree.
Lots of changing of the Config.in files.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
Christoph Hellwig <[email protected]>:
> With mconfig [side-effect chasing] can be implemented easily [...]
> One toplevel config file can be implemented in CML1 easily,
You can spend all week telling us how easy it would be to implement
all the CML2 benefits that CML1 doesn't have, if you like -- but one
of the rules of this game is that an ounce of working code beats a
pound of handwaving.
When you've shown the list the bundle of CML1 implementation and
rulesfile patches that brings CML1 up to snuff, *then* you'll have
grounds to argue that the switch to CML2 gains nothing.
So don't talk about it, *do it*! Whether you succeed or fail, one of
the two of us will get a valuable education from your attempt. And
until you succeed or fail, arguing is just wasting everyone else's time.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Courage is resistance of fear, mastery of fear, not absence of fear.
Christoph> I still strongly object to it and I know lots of kernel
Christoph> hackers are the same opinion.
I'm not a hacker, but I think it's a good thing to move to CML2. I've
tested it and it's got some nice features. The Python issue I don't
think is too onerous to require of people. And wasn't there someone
out there porting CML2 to straight C code?
Why are people so wedded to the CML1 language spec anyway?
John
John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
[email protected] - http://www.lucent.com - 978-952-7548
On Tue, 04 Dec 2001, Christoph Hellwig wrote:
> On Tue, Dec 04, 2001 at 08:16:40AM -0500, Eric S. Raymond wrote:
> > N separate implementations means N dialects and N**2 compatibility problems.
> > Nicer just to have *one* parser, *one* compiler, and *one* service class that
> > supports several thin front-end layers, yes? No?
>
> Oh man. When you think one implementation of a 'standard' is better then
> multiple go to the MS world.
Well, there is competition: CML2. It is setting a new standard, which
Microsoft only claim, but never achieve (except for standards of making
licensing more restrictive). >:-)
Seriously: what do you fear? Losing the efforts you put into mconfig?
Linux 2.2 and 2.4 will be around for quite some time (not sure about
mconfig on 2.0, I don't use 2.0.x ATM).
Creating a dependency on Python? Is a non-issue. Current systems that
are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
is nice and it does not create such unmaintainable mess. Whether
Python's syntax is actually good is disbutable, but at no avail; it's
possible yet no good to discuss taste. In the end, you do not need to
maintain that code. You don't make the pen yourself when writing a
letter either.
> > I quote Linus at the 2.5 kernel summit: "Python is not an issue."
> > Unless and until he changes his mind about that, waving around this
> > kind of argument is likely to do your case more harm than good.
>
> For me (and others) it is an issues.
What are the precise issues with Python? Just claiming it is an issue is
not useful for discussing this. Archive pointers are welcome.
[email protected] said:
> You can spend all week telling us how easy it would be to implement
> all the CML2 benefits that CML1 doesn't have, if you like -- but one
> of the rules of this game is that an ounce of working code beats a
> pound of handwaving.
FWIW I have no particular problem with CML2. I agree that CML1 is fairly
limited, and can see the advantages in ditching it for a new language.
I do have objections to some of the other ideas which have been floated for
changing the behaviour of the config rules, which aren't strictly related to
the change in language.
I just want to make sure that the introduction of CML2 doesn't sneak in
controversial changes to the config behaviour to make my Aunt Tilley happy,
when those changes should be given individual consideration, not presented
as a fait accomplis.
If I can't have one without the other, I'd rather not have either - CML1
may indeed suck, but it doesn't suck _that_ much.
But I figure we can trust you not to do that - can't we?
--
dwmw2
David Woodhouse wrote:
>
> I do have objections to some of the other ideas which have been floated for
> changing the behaviour of the config rules, which aren't strictly related to
> the change in language.
The rules are nearly the same (but written in another language).
The problem was in converting rules: esr found a lot of error:
these error should be corrected, also some rules are different.
Also converting rules, you surelly found some error: i.e. wrong
dependencies syntax, wrong implementation,....
I don't think esr changed non problematic rules, but one:
all rules without help become automatically dependent to
CONFIG_EXPERIMENTAL. I don't like it, but I understand why
he makes this decision.
Remember: The config.in files contain a lot of errors, and
automatic tools can not find all.
giacomo
> Creating a dependency on Python? Is a non-issue. Current systems that
> are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> is nice and it does not create such unmaintainable mess. Whether
Python2 - which means most users dont have it.
[email protected] said:
> I don't think esr changed non problematic rules, but one: all rules
> without help become automatically dependent to CONFIG_EXPERIMENTAL. I
> don't like it, but I understand why he makes this decision.
That is precisely the kind of bogus change which should _not_ be done in
such an underhand way.
With the exception of obvious and undisputed bug fixes, the behaviour of
the first CML2 version should precisely match the behaviour of the last
CML1 version.
If you want to make symbols without help depend on CONFIG_EXPERIMENTAL,
submit the equivalent patch for CML1 and watch it get shot down in flames.
Then go away.
But don't let this dissuade you from doing something that's actually
useful, like CML2 could be.
On the other hand, perhaps we could reach some kind of a deal.... Eric, if
you can manage to also sneak a kernel debugger past Linus as part of your
big-patch-which-hides-controversial-changes, I for one would be happy enough
to deal with the bogus config changes :)
--
dwmw2
Matthias Andree <[email protected]>:
> Seriously: what do you fear? Losing the efforts you put into mconfig?
> Linux 2.2 and 2.4 will be around for quite some time (not sure about
> mconfig on 2.0, I don't use 2.0.x ATM).
Oops. I wasn't going to tell anyone this yet, but since you've made
this argument I feel I must be up front here....
After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
and lobby for him accepting it into 2.4, on the grounds that doing so
will simplify his maintainance task no end. That's why I'm tracking
both sides of the fork in the rulebase, so it will be an easy drop-in
replacement for Marcelo as well as Linus.
> What are the precise issues with Python? Just claiming it is an issue is
> not useful for discussing this. Archive pointers are welcome.
The issues can be divided into two groups: silly and serious. The
representative silly objection was "Python is evil because significant
whitespace sucks!". Cristoph's objection to the use of a binary pickle
as an intermediate format is in this category also.
I heard two serious objections:
(1) The overhead of learning a new config language is too high.
(2) Requiring Python introduces another tool into the requisites list for
kernel building.
As to (1), the very people who maintained the in-kernel CML1 tools
judged that the overhead of sticking with what they wrote was
forseeably going to be higher than that of putting a new language in
place. Otherwise they would not have encouraged me to replace it when
I offered.
As to (2), I could make all kinds of elaborate defensive technical
arguments, or I could point at Greg Bank's CML2-in-C project, but
screw that. I'm just going to say "Today's problems, today's tools."
Progress happens. If you don't like it, feel free to go back to
writing Autocoder on your 1401.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"The state calls its own violence `law', but that of the individual `crime'"
-- Max Stirner
Giacomo Catenazzi <[email protected]>:
> I don't think esr changed non problematic rules, but one:
> all rules without help become automatically dependent to
> CONFIG_EXPERIMENTAL. I don't like it, but I understand why
> he makes this decision.
No, it's CONFIG_EXPERT. And this change is not wired in. Comment
out this declaration in the top-level rulesfile:
condition nohelp on EXPERT
and it reverts to old behavior.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The conclusion is thus inescapable that the history, concept, and
wording of the second amendment to the Constitution of the United
States, as well as its interpretation by every major commentator and
court in the first half-century after its ratification, indicates
that what is protected is an individual right of a private citizen
to own and carry firearms in a peaceful manner.
-- Report of the Subcommittee On The Constitution of the Committee On
The Judiciary, United States Senate, 97th Congress, second session
(February, 1982), SuDoc# Y4.J 89/2: Ar 5/5
David Woodhouse <[email protected]>:
> I do have objections to some of the other ideas which have been floated for
> changing the behaviour of the config rules, which aren't strictly related to
> the change in language.
I'm listening...what can I do for you?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The IRS has become morally corrupted by the enormous power which we in
Congress have unwisely entrusted to it. Too often it acts like a
Gestapo preying upon defenseless citizens.
-- Senator Edward V. Long
David Woodhouse <[email protected]>:
>
> [email protected] said:
> > I don't think esr changed non problematic rules, but one: all rules
> > without help become automatically dependent to CONFIG_EXPERIMENTAL. I
> > don't like it, but I understand why he makes this decision.
>
> That is precisely the kind of bogus change which should _not_ be done in
> such an underhand way.
Underhanded? Hardly. It was right there, with explanation, in one of the
release announcements I've been posting.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
As war and government prove, insanity is the most contagious of
diseases.
-- Edward Abbey
[email protected] said:
> I'm listening...what can I do for you?
Simply assure me that I don't have to scan every line of the CML2 files for
such changes, and that you'll make a reasonable effort to make the first set
of CML2 rules match the existing CML1 behaviour, without introducing any
controversial changes.
Submit the stuff you know is less popular, like hiding options without help
text, later - and we can argue about them at the time.
--
dwmw2
On Tue, 04 Dec 2001, Alan Cox wrote:
> > Creating a dependency on Python? Is a non-issue. Current systems that
> > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > is nice and it does not create such unmaintainable mess. Whether
>
> Python2 - which means most users dont have it.
Every new kernel version required new tools, 2.2 particularly many, 2.4
also some, so it's just one more tool to add in the end.
Current distributions already ship with Python2, and probably all will
when distributors know that Python2 will be needed to configure Linux
2.5 or 2.6.
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
Alan Cox <[email protected]>:
> > Creating a dependency on Python? Is a non-issue. Current systems that
> > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > is nice and it does not create such unmaintainable mess. Whether
>
> Python2 - which means most users dont have it.
I'm pretty sure that's true any more, Alan. Red Hat shipped Python 2 in
7.1, so the RPM-based distros like KRUD and Mandrake have had it for
seven months. Debian had it before that.
Requiring 2.0 looked aggressive when I did it, but it wasn't -- I could
safely project that it would be deployed everywhere except on a set of
measure zero by the time the actual cutover happened.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Both oligarch and tyrant mistrust the people,
and therefore deprive them of arms."
--Aristotle
[email protected] said:
> No, it's CONFIG_EXPERT. And this change is not wired in. Comment
> out this declaration in the top-level rulesfile:
> condition nohelp on EXPERT
> and it reverts to old behavior.
Good. Please make that the default when submitting the first version of
CML2. You can submit patches which effect the change in behaviour later,
and they can be individually considered.
--
dwmw2
Eric S. Raymond wrote:
>
> Oops. I wasn't going to tell anyone this yet, but since you've made
> this argument I feel I must be up front here....
>
> After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> and lobby for him accepting it into 2.4, on the grounds that doing so
> will simplify his maintainance task no end. That's why I'm tracking
> both sides of the fork in the rulebase, so it will be an easy drop-in
> replacement for Marcelo as well as Linus.
>
Don't do it!
A stable kernel should be stable also on the building tools.
When Marcelo will correct some grave potential security problem,
the user will rebuild the kernel and it will found that it must
install some other package (machine with 2.4 are now common,
python2 not yet so common) to secure his kernel, it would be
happy.
This is an example, but for a better maintainability you will
give serious problem to the novice kernel user.
giacomo
BTW there is alreay a punishment for you:
you will resync the variout ARCH, speak with various
subsystem maintainer, ... before to sent path to Marcelo.
"Eric S. Raymond" wrote:
>
> Alan Cox <[email protected]>:
> > > Creating a dependency on Python? Is a non-issue. Current systems that
> > > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > > is nice and it does not create such unmaintainable mess. Whether
> >
> > Python2 - which means most users dont have it.
>
> I'm pretty sure that's true any more, Alan. Red Hat shipped Python 2 in
> 7.1, so the RPM-based distros like KRUD and Mandrake have had it for
> seven months. Debian had it before that.
>
> Requiring 2.0 looked aggressive when I did it, but it wasn't -- I could
> safely project that it would be deployed everywhere except on a set of
> measure zero by the time the actual cutover happened.
~# rpm -qa | grep -i python
python-1.5.2-35
python-xmlrpc-1.5.0-1
pythonlib-1.28-1
rpm-python-4.0.3-1.03
python-devel-1.5.2-35
Just another megaton unnecessary programming language to compile
somehting like the kernel? I think you are exaggerating the problem.
On Tue, Dec 04, 2001 at 06:30:45PM +0100, Martin Dalecki wrote:
> ~# rpm -qa | grep -i python
> python-1.5.2-35
> python-xmlrpc-1.5.0-1
> pythonlib-1.28-1
> rpm-python-4.0.3-1.03
> python-devel-1.5.2-35
>
> Just another megaton unnecessary programming language to compile
> somehting like the kernel? I think you are exaggerating the problem.
Same here (A few weeks old Caldera development snapshot):
[hch@sb hch]$ rpm -qa | grep python
dcoppython-2.2.1-2
python-1.5.2-8
python-devel-1.5.2-8
python-doc-1.5.2-8
python-eclass-1.2-6
python-tk-1.5.2-8
Alan Cox <[email protected]>:
> > I'm pretty sure that's true any more, Alan. Red Hat shipped Python 2 in
> > 7.1, so the RPM-based distros like KRUD and Mandrake have had it for
> > seven months. Debian had it before that.
>
> RH shipped python2 beginning RH 7.2.
Eh? I'm going to go check my old 7.1 CDs...
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Government should be weak, amateurish and ridiculous. At present, it
fulfills only a third of the role.
-- Edward Abbey
On December 4, 2001 05:52 pm, Giacomo Catenazzi wrote:
> I don't think esr changed non problematic rules, but one:
> all rules without help become automatically dependent to
> CONFIG_EXPERIMENTAL. I don't like it, but I understand why
> he makes this decision.
I love it.
--
Daniel
> > RH shipped python2 beginning RH 7.2.
>
> Eh? I'm going to go check my old 7.1 CDs...
Feel free. You'll find python v1. There is a very early python2 on the
optional power tools CD that some folks will have but downloaders generally
dont bother with.
Trust me, I went through the same pain with a python2 specific gnome2
file convertor
David Woodhouse <[email protected]>:
>
> [email protected] said:
> > I'm listening...what can I do for you?
>
> Simply assure me that I don't have to scan every line of the CML2 files for
> such changes, and that you'll make a reasonable effort to make the first set
> of CML2 rules match the existing CML1 behaviour, without introducing any
> controversial changes.
>
> Submit the stuff you know is less popular, like hiding options without help
> text, later - and we can argue about them at the time.
People like Giacomo and my other beta testers are keeping an eye on me.
Don't sweat it.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"If I must write the truth, I am disposed to avoid every assembly of
bishops; for of no synod have I seen a profitable end, but rather an
addition to than a diminution of evils; for the love of strife and the
thirst for superiority are beyond the power of words to express."
-- Father Gregory Nazianzen, 381 AD
Giacomo Catenazzi <[email protected]>:
> > Oops. I wasn't going to tell anyone this yet, but since you've made
> > this argument I feel I must be up front here....
> >
> > After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> > and lobby for him accepting it into 2.4, on the grounds that doing so
> > will simplify his maintainance task no end. That's why I'm tracking
> > both sides of the fork in the rulebase, so it will be an easy drop-in
> > replacement for Marcelo as well as Linus.
>
> Don't do it!
> A stable kernel should be stable also on the building tools.
That will be Marcelo's call, not mine.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The kind of charity you can force out of people nourishes about as much as
the kind of love you can buy --- and spreads even nastier diseases.
Alan Cox wrote:
>
> > Creating a dependency on Python? Is a non-issue. Current systems that
> > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > is nice and it does not create such unmaintainable mess. Whether
>
> Python2 - which means most users dont have it.
And then you will end with:
python1.4x,
python2,
python3 rewrite in python1 and so on and so on.
Thanks but NO thanks
> > > Python2 - which means most users dont have it.
>
> Most users sure as hell shouldn't be playing with 2.5.x right now
> anyways. With any sort of 'luck' it'll be 6 months at least before
> 2.5.x becomes stable enough that it will probably compile all the time
> again and not have a random fs eating bug. In 6 months even woody might
> be frozen :)
It wont become stable if nobody can configure it because nobody will build
it or run it. Lots of people build non stable kernels because its
a) fun
b) a way to learn and play with the system
c) they might make their own small fix and mark
not all of the them are demon kernel hackers.
Alan
On Tue, Dec 04, 2001 at 06:26:27PM +0000, Alan Cox wrote:
> > > > Python2 - which means most users dont have it.
> >
> > Most users sure as hell shouldn't be playing with 2.5.x right now
> > anyways. With any sort of 'luck' it'll be 6 months at least before
> > 2.5.x becomes stable enough that it will probably compile all the time
> > again and not have a random fs eating bug. In 6 months even woody might
> > be frozen :)
>
> It wont become stable if nobody can configure it because nobody will build
> it or run it. Lots of people build non stable kernels because its
>
> a) fun
> b) a way to learn and play with the system
> c) they might make their own small fix and mark
>
> not all of the them are demon kernel hackers.
But they can't install python2? I _think_ there's src.rpms on
Python.org that will install as python2 even...
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Tue, 2001-12-04 at 13:01, Alan Cox wrote:
> Feel free. You'll find python v1. There is a very early python2 on the
> optional power tools CD that some folks will have but downloaders generally
> dont bother with.
Also, I don't think any version of RedHat has Tkinter 2.0 yet ...
Robert Love
On Tue, 4 Dec 2001, Eric S. Raymond wrote:
> > Don't do it!
> > A stable kernel should be stable also on the building tools.
>
> That will be Marcelo's call, not mine.
Ohhh, that sounds a lot like "I'm not the maintainer, I'm
not responsible for the code I submit" ;)))
*runs like hell*
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
Rik van Riel <[email protected]>:
> Ohhh, that sounds a lot like "I'm not the maintainer, I'm
> not responsible for the code I submit" ;)))
I will provide stable code and be responsible for its stability. It will be
Marcelo's call, not mine, on whether the strategic tradeoffs come out
in favor of the back-port.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Everything you know is wrong. But some of it is a useful first approximation.
Hi.
> But they can't install python2? I _think_ there's src.rpms on
> Python.org that will install as python2 even...
Usually a src.rpm installs a source, not a program :)
// Stefan
On Tue, Dec 04, 2001 at 08:19:52PM +0100, Stefan Smietanowski wrote:
> Hi.
>
> >But they can't install python2? I _think_ there's src.rpms on
> >Python.org that will install as python2 even...
>
> Usually a src.rpm installs a source, not a program :)
Compiling rpms is arguably simpiler than a kernel. rpm --recompile
foo.src.rpm, I think even :)
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Tue, 4 Dec 2001, Eric S. Raymond wrote:
> Alan Cox <[email protected]>:
> > > I'm pretty sure that's true any more, Alan. Red Hat shipped Python 2 in
> > > 7.1, so the RPM-based distros like KRUD and Mandrake have had it for
> > > seven months. Debian had it before that.
> >
> > RH shipped python2 beginning RH 7.2.
>
> Eh? I'm going to go check my old 7.1 CDs...
We shipped python2 as an extra package ever since 7.1, but it's not in any
of the default installs because the standard tools still use python 1.5.x
for compatibility reasons.
LLaP
bero
--
This message is provided to you under the terms outlined at
http://www.bero.org/terms.html
On Tue, Dec 04, 2001 at 06:27:26PM +0100, Martin Dalecki wrote:
> Alan Cox wrote:
> >
> > > Creating a dependency on Python? Is a non-issue. Current systems that
> > > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > > is nice and it does not create such unmaintainable mess. Whether
> >
> > Python2 - which means most users dont have it.
Most users sure as hell shouldn't be playing with 2.5.x right now
anyways. With any sort of 'luck' it'll be 6 months at least before
2.5.x becomes stable enough that it will probably compile all the time
again and not have a random fs eating bug. In 6 months even woody might
be frozen :)
> And then you will end with:
>
> python1.4x,
> python2,
> python3 rewrite in python1 and so on and so on.
Say what? Python (with the exception of undocumented features) has been
pretty good about compatiblity. If it works with 1.5.x and doesn't rely
on undocumented features, it'll work with 2.0x, 2.1x and 2.2x.
> Thanks but NO thanks
Then go help Greg Banks in his CML2-in-C project.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Tue, 4 Dec 2001, Eric S. Raymond wrote:
> After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> and lobby for him accepting it into 2.4, on the grounds that doing so
> will simplify his maintainance task no end.
> ...
> I'm just going to say "Today's problems, today's tools."
So anyone perfectly happy with an older distro that didn't
ship python2-and-whatever-else gets screwed when they want to
build a newer kernel. Nice.
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Tue, 4 Dec 2001, David Weinehall wrote:
> "So anyone happy with an older distro that didn't ship gcc-2.95.x, x > 2
> gets screwed when they want to build a newer kernel. Nice."
The difference being that recommended compiler versions don't
change midway through a stable series. Neither should any other
part of the buildtools.
regards,
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Tue, Dec 04, 2001 at 06:43:17PM +0100, Dave Jones wrote:
> So anyone perfectly happy with an older distro that didn't
> ship python2-and-whatever-else gets screwed when they want to
> build a newer kernel. Nice.
What is so difficult about building python?
I found it a hell of a lot simpler to unpack/configure/compile/install than
the kernel!
mrc
--
Mike Castle [email protected] http://www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
On Tue, 2001-12-04 at 12:43, Dave Jones wrote:
> On Tue, 4 Dec 2001, Eric S. Raymond wrote:
>
> > After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> > and lobby for him accepting it into 2.4, on the grounds that doing so
> > will simplify his maintainance task no end.
> > ...
> > I'm just going to say "Today's problems, today's tools."
>
> So anyone perfectly happy with an older distro that didn't
> ship python2-and-whatever-else gets screwed when they want to
> build a newer kernel. Nice.
That's been the case all along, sans python2. Newer kernels need newer
tools. That's always been the case.
>
> Dave.
>
> --
> | Dave Jones. http://www.codemonkey.org.uk
> | SuSE Labs
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
-------------------------------
Edward Muller
Director of IS
973-715-0230 (cell)
212-487-9064 x115 (NYC)
http://www.learningpatterns.com
-------------------------------
On Tue, Dec 04, 2001 at 08:53:11PM +0100, Dave Jones wrote:
> On Tue, 4 Dec 2001, David Weinehall wrote:
>
> > "So anyone happy with an older distro that didn't ship gcc-2.95.x, x > 2
> > gets screwed when they want to build a newer kernel. Nice."
>
> The difference being that recommended compiler versions don't
> change midway through a stable series. Neither should any other
> part of the buildtools.
AFAIK, changes to the required versions of userland-tools wouldn't
during a stable release happen ever-so-often. I can agree that it
wouldn't be ideal to introduce a completely new requirement, though.
A C-version of CML2-configurator would be a nice solution here.
But, I'm fairly confident that Marcello will make the right decisions
on his own.
/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
On 4 Dec 2001, Edward Muller wrote:
> That's been the case all along, sans python2. Newer kernels need newer
> tools. That's always been the case.
Between major versions yes. Not within the same stable release.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
> > So anyone perfectly happy with an older distro that didn't
> > ship python2-and-whatever-else gets screwed when they want to
> > build a newer kernel. Nice.
>
> That's been the case all along, sans python2. Newer kernels need newer
> tools. That's always been the case.
Not during stable releases. In fact we've jumped through hoops several times
to try and keep egcs built kernels working
On Tue, 4 Dec 2001, Dave Jones wrote:
> On Tue, 4 Dec 2001, Eric S. Raymond wrote:
>
> > After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> > and lobby for him accepting it into 2.4, on the grounds that doing so
> > will simplify his maintainance task no end.
> > ...
> > I'm just going to say "Today's problems, today's tools."
>
> So anyone perfectly happy with an older distro that didn't
> ship python2-and-whatever-else gets screwed when they want to
> build a newer kernel. Nice.
>
> Dave.
I have python. I also have ed.
When the only tool you know how to use is a hammer, every problem
begins to look like a nail.
FYI, I have never known a problem that python has solved, only
changed.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
> After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> and lobby for him accepting it into 2.4, on the grounds that doing so
> will simplify his maintainance task no end. That's why I'm tracking
> both sides of the fork in the rulebase, so it will be an easy drop-in
> replacement for Marcelo as well as Linus.
Thats somewhat impractical. You will break all the existing additional
configuration tools for the 2.4 stable tree that people expect to continue
to work
Breaking them in 2.5 isnt a big issue, but breaking stable kernel trees
is a complete nono
On Tue, Dec 04, 2001 at 06:43:17PM +0100, Dave Jones wrote:
> On Tue, 4 Dec 2001, Eric S. Raymond wrote:
>
> > After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> > and lobby for him accepting it into 2.4, on the grounds that doing so
> > will simplify his maintainance task no end.
> > ...
> > I'm just going to say "Today's problems, today's tools."
>
> So anyone perfectly happy with an older distro that didn't
> ship python2-and-whatever-else gets screwed when they want to
> build a newer kernel. Nice.
"So anyone happy with an older distro that didn't ship gcc-2.95.x, x > 2
gets screwed when they want to build a newer kernel. Nice."
/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
> I'm pretty sure that's true any more, Alan. Red Hat shipped Python 2 in
> 7.1, so the RPM-based distros like KRUD and Mandrake have had it for
> seven months. Debian had it before that.
RH shipped python2 beginning RH 7.2.
Alan
On Tue, 2001-12-04 at 15:20, Alan Cox wrote:
> > > So anyone perfectly happy with an older distro that didn't
> > > ship python2-and-whatever-else gets screwed when they want to
> > > build a newer kernel. Nice.
> >
> > That's been the case all along, sans python2. Newer kernels need newer
> > tools. That's always been the case.
>
> Not during stable releases. In fact we've jumped through hoops several times
> to try and keep egcs built kernels working
Agreed. I spoke a little too broadly. But newer 'trees' (2.0 to 2.2 to
2.4 to 2.5) has always (IIRC) needed newer tools.
--
-------------------------------
Edward Muller
Director of IS
973-715-0230 (cell)
212-487-9064 x115 (NYC)
http://www.learningpatterns.com
-------------------------------
> > That's been the case all along, sans python2. Newer kernels need newer
> > tools. That's always been the case.
>
> Not during stable releases. In fact we've jumped through hoops several
times
> to try and keep egcs built kernels working
Are we not talking about the 2.5 kernel build tree? My understanding of the
numbering of kernels is that the 2.4.x tree is stable; and the 2.5.x tree is
the new development tree
If the suggestion was to alter the 2.4 tree in a way that required
additional tools; I could understand the concern; the 2.5 tree is unstable;
and so to go from 2.5.a to 2.5.b I expect to have to be really carefull and
*READ* the release notes; similarly from 2.2.x to 2.4.x; but 2.4.a to 2.4.b
I generally detar the tree; copy my .config over check with menuconfig that
things make sense; build the kernel and expect things to work; release notes
you ask? ..I only glance at them to see if anything strikes my eye; but they
are not read completely
Trevor
> Are we not talking about the 2.5 kernel build tree? My understanding of the
> numbering of kernels is that the 2.4.x tree is stable; and the 2.5.x tree is
> the new development tree
Erik is talking about crapping in both trees, as opposed to 2.5 only
On December 4, 2001 06:50 pm, Daniel Phillips wrote:
> On December 4, 2001 05:52 pm, Giacomo Catenazzi wrote:
> > I don't think esr changed non problematic rules, but one:
> > all rules without help become automatically dependent to
> > CONFIG_EXPERIMENTAL. I don't like it, but I understand why
> > he makes this decision.
>
> I love it.
Having thought about this a little more, I don't think it's correct. It's
cute and I still love the idea of forcing people to document - I sometimes
imagine there exist contributors who make a point of not documenting - but
the need for a clean design with as few corner cases as possible trumps that.
Suppose I'm working on my patch, doing the part that hooks into config. It
works, I can see my new feature, but for some strange reason the buttons are
grayed out. After I fiddle a while I clue in to the idea that the
'experimental' setting might have something to do with it, I turn it on and
then my buttons work. Now, what the? Eventually I figure out this is
supposed to be a feature, not a bug, and that including some help will
activate my buttons. So I curse the author up and down and submit a patch to
remove that feature.
This is a admittedly a small point and I'm not going to quibble about it any
more. I'm happy the kbuild process is being cleaned up. I've wasted too
much time due to shortcomings in the old one.
I'll wait until this gets into the tree before submitting my patch ;-)
--
Daniel
On Tue, Dec 04, 2001 at 05:44:19PM +0000, Alan Cox <[email protected]> wrote:
| > After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
| > and lobby for him accepting it into 2.4, on the grounds that doing so
| > will simplify his maintainance task no end. That's why I'm tracking
| > both sides of the fork in the rulebase, so it will be an easy drop-in
| > replacement for Marcelo as well as Linus.
|
| Thats somewhat impractical. You will break all the existing additional
| configuration tools for the 2.4 stable tree that people expect to continue
| to work
|
| Breaking them in 2.5 isnt a big issue, but breaking stable kernel trees
| is a complete nono
Folks, have you forgotten that you're programmers?
ESR, is it practical to have CML2 transcribe a CML1 config file?
Then as part of the build-the-kernel-src-tarball, Marcelo or whoever's
make target runs the transcriber.
This would let people fetch a kernel and build with the old tools
for personal hacking purposes which keeping the source config in CML2
which is cleans and more powerful. Kernel code _authors_ would need to
write in CML2, but not kernel end users.
--
Cameron Simpson, DoD#743 [email protected] http://www.zip.com.au/~cs/
A motorcycle is like a toothbrush. Everyone should have their own.
- [email protected]
Richard B. Johnson scripsit:
> FYI, I have never known a problem that python has solved, only
> changed.
The same can be said of computers in general.
--
John Cowan http://www.ccil.org/~cowan [email protected]
Please leave your values | Check your assumptions. In fact,
at the front desk. | check your assumptions at the door.
--sign in Paris hotel | --Miles Vorkosigan
On Tue, Dec 04, 2001 at 10:14:58PM -0500, John Cowan wrote:
> Richard B. Johnson scripsit:
>
> > FYI, I have never known a problem that python has solved, only
> > changed.
>
> The same can be said of computers in general.
>
There are just too many things that computers have allowed us to do that we
*could not* do before. If you step back and think for a while, you'll
probably find at least five things that would be impossible without
computers (excluding computer specific topics).
Cameron Simpson <[email protected]>:
> ESR, is it practical to have CML2 transcribe a CML1 config file?
No, alas.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Government should be weak, amateurish and ridiculous. At present, it
fulfills only a third of the role.
-- Edward Abbey
On Wed, Dec 05, 2001 at 03:29:54AM -0500, Eric S. Raymond wrote:
> Cameron Simpson <[email protected]>:
> > ESR, is it practical to have CML2 transcribe a CML1 config file?
>
> No, alas.
But it _is_ entirely practical to run CML2 with a bog-standard python
1.5 interpreter. I just did a search/replace for the python2-ism's like
<x> += <y> => <x> = <x> + <y>, and
<string>.<op>(<arg>) => string.<op>(<string>, <arg>)
Worked around some missing functionality in the older shlex and curses
modules and I can now use oldconfig, menuconfig, xconfig, and cmladvent
with CML2 and a python1 interpreter. It also still works fine with
python2 as well.
http://ravel.coda.cs.cmu.edu/cml2-1.9.4-python1.patch (36K)
36K might sound like a lot, but given the fact that the CML python
sources totals about 280KB, it is a pretty small diff, and the whole
"but python2 isn't standard in distributions and the license is bad"
argument can be dropped and we can get on with life.
Jan
> > Thanks but NO thanks
>
> Then go help Greg Banks in his CML2-in-C project.
Why? The current system works fine for me!
On Tuesday 04 December 2001 03:20 pm, Richard B. Johnson wrote:
> FYI, I have never known a problem that python has solved, only
> changed.
The same could be said of C. By definition, any program that can be
expressed in C could have been done on paper in binary.
Rob
On Tuesday 04 December 2001 12:43 pm, Dave Jones wrote:
> On Tue, 4 Dec 2001, Eric S. Raymond wrote:
> > After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> > and lobby for him accepting it into 2.4, on the grounds that doing so
> > will simplify his maintainance task no end.
> > ...
> > I'm just going to say "Today's problems, today's tools."
>
> So anyone perfectly happy with an older distro that didn't
> ship python2-and-whatever-else gets screwed when they want to
> build a newer kernel. Nice.
>
> Dave.
1) Moving from 2.2->2.4, it wouldn't work at all without a newer compiler and
newer modutils, and it really helped to have a C library and eight zillion
other things upgraded. So talking about what 2.6 will need that's an amazing
red herring.
2) In terms of a 2.4 backport, if the old stuff isn't removed (the current
garbage that does menuconfig et al), then who cares? It's another option
they don't have to use. It's also Marcelo's call.
3) The fact Linus was cc'd on this before I trimmed it suggests to me that
people are still wishfully thinking that the battle they lost before the
linux-kernel summit would just magically re-open at the last minute. It's
not about the fact that reiserfs, ext3, and a new VM subsystem went into 2.4
but THIS is way too much, it's a group of people bitching about python
because they don't like the concept of significant whitespace. Technically
speaking, this is another variant of the good old indentation/coding style
thread that just won't die.
It's insidious, isn't it?
Rob
On Wed, 5 Dec 2001, Rob Landley wrote:
> > So anyone perfectly happy with an older distro that didn't
> > ship python2-and-whatever-else gets screwed when they want to
> > build a newer kernel. Nice.
>
> 1) Moving from 2.2->2.4, it wouldn't work at all without a newer compiler and
> newer modutils, and it really helped to have a C library and eight zillion
> other things upgraded. So talking about what 2.6 will need that's an amazing
> red herring.
My comment was in regard to the subthread concerning the backport of
CML2 to 2.4 only. Not 2.5/2.6. Yes, tools need to be upgraded
OVER MAJOR VERSIONS. I was not debating that.
> 2) In terms of a 2.4 backport, if the old stuff isn't removed (the current
> garbage that does menuconfig et al), then who cares?
Anyone maintaining Config.in files. What you're proposing doubles the
amount of work to keep them up to date. Especially for out-of-tree code.
> It's also Marcelo's call.
Absolutely.
> It's not about the fact that reiserfs, ext3, and a new VM subsystem went
> into 2.4 but THIS is way too much
And did any of these require updated tools to build the kernel ?
No. I could take a kernel with these features, and build it on
a 6 month old distro.
> it's a group of people bitching about python because they don't like the
> concept of significant whitespace.
Crap. It's about not screwing over an installed userbase for a
feature that is nothing more than a "Nice to have" add-on for 2.4.
It's taken us long enough to get 2.4 where it is, hopefully the
days of things getting shovelled in enmasse are over.
> Technically speaking, this is another variant of the good old
> indentation/coding style thread that just won't die.
I recommend "Kill by thread". Works wonders.
regards,
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Wed, 5 Dec 2001, Rob Landley wrote:
> 3) The fact Linus was cc'd on this before I trimmed it suggests to me
> that people are still wishfully thinking that the battle they lost
> before the linux-kernel summit would just magically re-open at the
> last minute. It's not about the fact that reiserfs, ext3, and a new
> VM subsystem went into 2.4 but THIS is way too much,
IMHO it's not acceptable that people upgrading from one 2.4
kernel to the next will have to install Python 2 on their
machine. Security bugs are and will be discovered, you cannot
make it impossible for people to do security upgrades.
Reiserfs, ext3 and the new VM have never changed the build
requirements for people and haven't made it impossible for
people to upgrade to a new kernel.
> It's insidious, isn't it?
Yes, I agree the method you're using to smuggle CML2 into
a stable kernel is insidious. Please stop it.
regards,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
Rik> IMHO it's not acceptable that people upgrading from one 2.4
Rik> kernel to the next will have to install Python 2 on their
Rik> machine.
So has anyone had time to test the Python version 1.5 based CML2 that
was posted? Would that make it more acceptable?
Rik> Security bugs are and will be discovered, you cannot make it
Rik> impossible for people to do security upgrades.
This is a bogus arguement, since I could say the same about installing
new kernels. There could (and will) be security problems with the
kernel, so we should not release new ones until we have proved they
are correct.
Yeah, I'm being a pain here, but Rik is making a bad arguement here.
Rik> Yes, I agree the method you're using to smuggle CML2 into a
Rik> stable kernel is insidious. Please stop it.
I think you're being too harsh here. Smuggling is not happening here,
it's been very aboveboard that CML2 might (I repeat MIGHT) be
back-ported to the 2.4 series of kernels. But since it would happen
in the -pre tree, there would be plenty of notice. And people could
complain then.
The requirement for python2 is a bit of a pain, but hey, for 2.5, it's
not a problem.
John
John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
[email protected] - http://www.lucent.com - 978-952-7548
> So has anyone had time to test the Python version 1.5 based CML2 that
> was posted? Would that make it more acceptable?
For 2.5 its a great leap forward. For 2.4 its irrelevant. Its simply not the
way stable kernel trees are run, even for people who think they are above
the rules and traditions
On Thursday 06 December 2001 11:49 am, Rik van Riel wrote:
> > It's insidious, isn't it?
>
> Yes, I agree the method you're using to smuggle CML2 into
> a stable kernel is insidious. Please stop it.
1) I'm not. You're getting your players confused.
2) I don't think Marcelo would take it, so I wouldn't even bother offering it
to him.
3) I'm suggesting that if it does go in the old method doesn't go away, so
that people who don't want to use the new stuff don't have to. I think
making the old pile of cruft disappear in a stable series IS a bad thing.
However, if adding new modular subsystems which people don't have to use (and
which require newer tools if you DO want to use them) was a bad thing...
Reiser, ext3, and the new vm circa 2.4.10 broke several GUI system monitors...
> regards,
>
> Rik
Rob
On Thursday 06 December 2001 12:25 pm, Alan Cox wrote:
> > So has anyone had time to test the Python version 1.5 based CML2 that
> > was posted? Would that make it more acceptable?
>
> For 2.5 its a great leap forward. For 2.4 its irrelevant. Its simply not
> the way stable kernel trees are run, even for people who think they are
> above the rules and traditions
Ooh, I can't resist...
"You mean like Linus?"
(Ducks, runs, looks innocent, runs some more...)
Rob
P.S. Can we seperate "add new subsystem y prime" and "remove old subsystem
y". LIke the new and old SCSI error handling, which have been in the tree in
parallel for some time? Did I hear Eric ever suggest removing the old
configurator for 2.4? Anybody?
John Stoffel wrote:
> The requirement for python2 is a bit of a pain, but hey, for 2.5, it's
> not a problem.
It is just a BIT OF PAIN. It gives me more trouble than the trouble
I have even with the insufficiencies of the current make system.
Basta.
On Thu, Dec 06, 2001 at 07:07:14PM +0100, Martin Dalecki wrote:
> John Stoffel wrote:
>
> > The requirement for python2 is a bit of a pain, but hey, for 2.5, it's
> > not a problem.
>
> It is just a BIT OF PAIN. It gives me more trouble than the trouble
> I have even with the insufficiencies of the current make system.
> Basta.
Does the fact that there's a simple patch fixing the requirement down
to Python 1.5 alleviate your troubles?
/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
>>>>> "Alan" == Alan Cox <[email protected]> writes:
>> So has anyone had time to test the Python version 1.5 based CML2 that
>> was posted? Would that make it more acceptable?
Alan> For 2.5 its a great leap forward.
That was my thought when I saw the patch to make CML2 work with Python
1.5 in Kernel 2.5.
John
On Thu, 06 Dec 2001, Rik van Riel wrote:
> IMHO it's not acceptable that people upgrading from one 2.4
> kernel to the next will have to install Python 2 on their
> machine. Security bugs are and will be discovered, you cannot
> make it impossible for people to do security upgrades.
While that should be avoided if can be at low cost, you have yet to
prove that Python 2 is an obstacle rather than a temporary inconvenience
-- and it seems as though Python 1.5.2 could be used with some patches.
On Thu, 6 Dec 2001 05:03:12 -0500,
Rob Landley <[email protected]> wrote:
>P.S. Can we seperate "add new subsystem y prime" and "remove old subsystem
>y". LIke the new and old SCSI error handling, which have been in the tree in
>parallel for some time? Did I hear Eric ever suggest removing the old
>configurator for 2.4? Anybody?
That is exactly what I am doing, adding kbuild 2.5 and CML2 then
removing kbuild 2.4 and CML1 in a later step. Neither Eric nor I want
to parallel run the old and new systems for more than one kernel
release in 2.5. Neither Eric nor I want to parallel run kbuild 2.5 and
CML2 in the 2.4 kernels, we only did the work there because we had no
development tree.
Rob Landley <[email protected]>:
> P.S. Can we seperate "add new subsystem y prime" and "remove old subsystem
> y". LIke the new and old SCSI error handling, which have been in the tree in
> parallel for some time? Did I hear Eric ever suggest removing the old
> configurator for 2.4? Anybody?
The whole point of putting the new configurator in would be to be able
to drop the old one out.
But that would be strictly Marcelo's call. It would be up to him to decide
whether the tradeoff were worth it.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Everything you know is wrong. But some of it is a useful first approximation.
On Thu, Dec 06, 2001 at 07:57:10PM -0500, Eric S. Raymond wrote:
> Rob Landley <[email protected]>:
> > P.S. Can we seperate "add new subsystem y prime" and "remove old subsystem
> > y". LIke the new and old SCSI error handling, which have been in the tree in
> > parallel for some time? Did I hear Eric ever suggest removing the old
> > configurator for 2.4? Anybody?
>
> The whole point of putting the new configurator in would be to be able
> to drop the old one out.
>
> But that would be strictly Marcelo's call. It would be up to him to decide
> whether the tradeoff were worth it.
Yes, but what people are saying (on this part of the thread) is please
don't bother Marcelo with it in the first place. All of the main gripes
people have don't apply to the current unstable tree, but most certainly
do to the current stable one.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Thursday 06 December 2001 07:57 pm, Eric S. Raymond wrote:
> Rob Landley <[email protected]>:
> > P.S. Can we seperate "add new subsystem y prime" and "remove old
> > subsystem y". LIke the new and old SCSI error handling, which have been
> > in the tree in parallel for some time? Did I hear Eric ever suggest
> > removing the old configurator for 2.4? Anybody?
>
> The whole point of putting the new configurator in would be to be able
> to drop the old one out.
Eric, I hate to break this to you, but they ain't gonna do it.
I like the new configurator, but It wouldn't matter if the thing cured
cancer. Removing an old system from a stable series just doesn't happen. We
don't even remove stuff that's clearly broken, we just mark it dangerous.
Even backporting the new configurator as an optional paralell subsystem is
pretty controversial. Technical merit aside, too many people are still
shellshocked over the VM thing.
Now that 2.4 has been handed off to Marcelo, people are looking for LESS
changes out of the stable series. To be blunt, we haven't really HAD a
stable series in 2.4 yet. Even 2.4.15 was almost a "dontuse" kernel due to
the shutdown sync thing. After 11 months of frustration, people are just a
TOUCH sensitive on this issue. Don't prod the sore tooth here, it's all pain
and no benefit...
> But that would be strictly Marcelo's call.
He's going to say no. But by all means, ask him if that will resolve the
issue. (I'll even refrain from calling it a cop-out, if this will help. :)
> It would be up to him to decide whether the tradeoff were worth it.
Worth it for who?
If the whole point of merging the new configurator into 2.4 is to drop the
old one, and we can confirm that's not going to happen (by asking Marcelo),
then there is no point in trying to merge the new configurator into 2.4.
(All syllogisms have three parts, therefore this is not a syllogism.)
Follow 2.5 and drop 2.4 support or hand it off to somebody else if you don't
want to do it. A better configurator is yet another reason for people to
migrate to 2.6 when it comes out. This is a good thing...
Rob
Jan Harkes <[email protected]>:
> But it _is_ entirely practical to run CML2 with a bog-standard python
> 1.5 interpreter. I just did a search/replace for the python2-ism's like
>
> <x> += <y> => <x> = <x> + <y>, and
> <string>.<op>(<arg>) => string.<op>(<string>, <arg>)
>
> Worked around some missing functionality in the older shlex and curses
> modules and I can now use oldconfig, menuconfig, xconfig, and cmladvent
> with CML2 and a python1 interpreter. It also still works fine with
> python2 as well.
>
> http://ravel.coda.cs.cmu.edu/cml2-1.9.4-python1.patch (36K)
>
> 36K might sound like a lot, but given the fact that the CML python
> sources totals about 280KB, it is a pretty small diff, and the whole
> "but python2 isn't standard in distributions and the license is bad"
> argument can be dropped and we can get on with life.
It's a good try. But there are some important things missing from
this patch -- notably the Textpad class, which is needed for doing
popup queries correctly.
Also, arrow keys don't work under the curses implementation linked
with in Red Hat's python1.5. This is a symptom of a deeper problem,
which is that older Pythons link the Berkeley curses library rather
than ncurses.
Clicking on a URL link with bomb xconfig with this patch under 1.5. You
didn't handle `import webbrowser' failure. Easy thing to miss.
I personally added the ncurses/Textpad/ascii features to the Python
libraries shipped in 2.0, and I did it for a reason -- to support what
`make menuconfig' needs. Backporting to 1.5.2 is only going to give a
partial, ugly subset of menuconfig. I don't think it's good enough.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"This country, with its institutions, belongs to the people who inhabit it.
Whenever they shall grow weary of the existing government, they can exercise
their constitutional right of amending it or their revolutionary right to
dismember it or overthrow it." -- Abraham Lincoln, 4 April 1861
Hi
> > But it _is_ entirely practical to run CML2 with a bog-standard python
> > 1.5 interpreter. I just did a search/replace for the python2-ism's like
> >
> > <x> += <y> => <x> = <x> + <y>, and
> > <string>.<op>(<arg>) => string.<op>(<string>, <arg>)
> >
> > Worked around some missing functionality in the older shlex and curses
> > modules and I can now use oldconfig, menuconfig, xconfig, and cmladvent
> > with CML2 and a python1 interpreter. It also still works fine with
> > python2 as well.
> >
> > http://ravel.coda.cs.cmu.edu/cml2-1.9.4-python1.patch (36K)
> >
> > 36K might sound like a lot, but given the fact that the CML python
> > sources totals about 280KB, it is a pretty small diff, and the whole
> > "but python2 isn't standard in distributions and the license is bad"
> > argument can be dropped and we can get on with life.
>
> It's a good try. But there are some important things missing from
> this patch -- notably the Textpad class, which is needed for doing
> popup queries correctly.
...
> I personally added the ncurses/Textpad/ascii features to the Python
> libraries shipped in 2.0, and I did it for a reason -- to support what
>