Converting the 2.5 kernel to kbuild 2.5

Converting the 2.5 kernel to kbuild 2.5

[Keith Owens]

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?

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Keith Owens <kaos@ocs.com.au>:
> 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)

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Keith Owens]

On Sun, 2 Dec 2001 20:19:46 -0500, 
"Eric S. Raymond" <esr@thyrsus.com> wrote:
>Keith Owens <kaos@ocs.com.au>:
>> 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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Dave Jones]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Keith Owens]

On Tue, 4 Dec 2001 01:22:52 +0100 (CET), 
Dave Jones <davej@suse.de> 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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[David Woodhouse]

esr@thyrsus.com 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
> 
> esr@thyrsus.com 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Alan Cox]

> 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Horst von Brand]

"Eric S. Raymond" <esr@thyrsus.com> said:
> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > > 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%.

And doing the hard work of getting even 60% done automatically for a
one-shot conversion (or very near of that) makes absolutely no sense.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Alan Cox]

> 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Christoph Hellwig]

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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Christoph Hellwig <hch@caldera.de>:
> 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Christoph Hellwig]

On Tue, Dec 04, 2001 at 07:28:08AM -0500, Eric S. Raymond wrote:
> Christoph Hellwig <hch@caldera.de>:
> > 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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Christoph Hellwig <hch@caldera.de>:
> 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Christoph Hellwig]

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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Christoph Hellwig <hch@caldera.de>:
> 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Christoph Hellwig]

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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Tom Rini]

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/

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Christoph Hellwig <hch@caldera.de>:
> 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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Matthias Andree]

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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Matthias Andree <matthias.andree@stud.uni-dortmund.de>:
> 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Giacomo Catenazzi]

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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Giacomo Catenazzi <cate@dplanet.ch>:
> > 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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Rik van Riel]

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/

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Rik van Riel <riel@conectiva.com.br>:
> 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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Dave Jones]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[David Weinehall]

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 <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Dave Jones]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[David Weinehall]

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 <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Mike Castle]

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      dalgoda@ix.netcom.com      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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Edward Muller]

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 majordomo@vger.kernel.org
> 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
-------------------------------

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Dave Jones]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Alan Cox]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Edward Muller]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Trevor Smith]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Alan Cox]

> 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Richard B. Johnson]

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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[John Cowan]

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              cowan@ccil.org
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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Mike Fedyk]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Rob Landley]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Rob Landley]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Dave Jones]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Rik van Riel]

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/

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Rob Landley]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[John Stoffel]

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
	 stoffel@lucent.com - http://www.lucent.com - 978-952-7548

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Alan Cox]

> 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Rob Landley]

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?

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Keith Owens]

On Thu, 6 Dec 2001 05:03:12 -0500, 
Rob Landley <landley@trommello.org> 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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Rob Landley <landley@trommello.org>:
> 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.

Re: [kbuild-devel] Converting the 2.4 kernel to kbuild 2.5

[Rob Landley]

On Thursday 06 December 2001 07:57 pm, Eric S. Raymond wrote:
> Rob Landley <landley@trommello.org>:
> > 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Tom Rini]

On Thu, Dec 06, 2001 at 07:57:10PM -0500, Eric S. Raymond wrote:
> Rob Landley <landley@trommello.org>:
> > 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/

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[John Stoffel]

>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Horst von Brand]

John Stoffel <stoffel@casc.com> said:
> >>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> 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. 

I just shudder when thinking that I'll have to learn yet another weird
language to be able to hack on Linux... C, gcc-isms with asm() and all, a
bit of CML1, now CML2, are OK; and now Python...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[David Weinehall]

On Thu, Dec 06, 2001 at 03:51:17PM -0300, Horst von Brand wrote:
> John Stoffel <stoffel@casc.com> said:
> > >>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> 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. 
> 
> I just shudder when thinking that I'll have to learn yet another weird
> language to be able to hack on Linux... C, gcc-isms with asm() and all, a
> bit of CML1, now CML2, are OK; and now Python...

And as of now, how many contributions have you made to the current
configurators? You know, you'll only have to know Python if you intend
to help ESR with the configurator itself...


/David
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Matthias Andree]

On Thu, 06 Dec 2001, Horst von Brand wrote:

> I just shudder when thinking that I'll have to learn yet another weird
> language to be able to hack on Linux... C, gcc-isms with asm() and all, a
> bit of CML1, now CML2, are OK; and now Python...

You'd need to learn CML2 perhaps, but not Python.

If you don't want to learn Python, you can think of it as an opaque
run-time system for _Eric's_ implementation of a CML2 interpreter if you
like.

If someone else did a C or Perl version, CML2 would remain the same, but
the Python run-time system could be dropped perchance.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[John Cowan]

Horst von Brand wrote:

 > I just shudder when thinking that I'll have to learn yet another weird
 > language to be able to hack on Linux... C, gcc-isms with asm() and all, a
 > bit of CML1, now CML2, are OK; and now Python...

You only need to learn Python if you are going to change the
CML2 compiler or interpreter, not if you are just changing
CML2.  You might as well complain that you must learn
Python to hack GNU Mailman.

CML2 hacking requires knowing Python; kernel hacking does not.

-- 
Not to perambulate             || John Cowan <jcowan@reutershealth.com>
    the corridors               || http://www.reutershealth.com
during the hours of repose     || http://www.ccil.org/~cowan
    in the boots of ascension.  \\ Sign in Austrian ski-resort hotel

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Horst von Brand]

John Cowan <jcowan@reutershealth.com> dijo:

[...]

> You only need to learn Python if you are going to change the
> CML2 compiler or interpreter, not if you are just changing
> CML2.

I did look around in CML1 when I had some troubles way back. Turned out to
be my fault, or was fixed in the next patch, so I didn't contribute back.
Trouble is that another opaque tool makes hacking _harder_, and this in
turn turns hackers away, and the development suffers.

>       You might as well complain that you must learn
> Python to hack GNU Mailman.

Just use majordomo ;-)

> CML2 hacking requires knowing Python; kernel hacking does not.

CML2 hacking _is_ kernel hacking, if you like to call it such or not.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[John Alvord]

On Fri, 07 Dec 2001 11:44:55 -0300, Horst von Brand
<vonbrand@inf.utfsm.cl> wrote:

>John Cowan <jcowan@reutershealth.com> dijo:
>
>[...]
>
>> You only need to learn Python if you are going to change the
>> CML2 compiler or interpreter, not if you are just changing
>> CML2.
>
>I did look around in CML1 when I had some troubles way back. Turned out to
>be my fault, or was fixed in the next patch, so I didn't contribute back.
>Trouble is that another opaque tool makes hacking _harder_, and this in
>turn turns hackers away, and the development suffers.
>
>>       You might as well complain that you must learn
>> Python to hack GNU Mailman.
>
>Just use majordomo ;-)
>
>> CML2 hacking requires knowing Python; kernel hacking does not.
>
>CML2 hacking _is_ kernel hacking, if you like to call it such or not.

I wonder how many people did CML1 tool hacking, fixing up one of the
three (four?) parsers/compilers/runtime. Most people wouldn't know if
those were written in C. sh, or ADA... Those would be the only people
that need to worry about learning Python to do the CML2 tool hacking.

john alvord

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Matthias Andree]

On Fri, 07 Dec 2001, Horst von Brand wrote:

> > CML2 hacking requires knowing Python; kernel hacking does not.
> 
> CML2 hacking _is_ kernel hacking, if you like to call it such or not.

There is hacking CML2 (the configuration files), and there is hacking
CML2 tools (rule compiler, GUI, ...), only the latter of which requires
Python knowledge.

Python is not that hard too read, and there's always someone you can ask
to explain you some clauses you don't get; and although I've never
looked at the CML2 tools, I looked at fetchmail, and the source has
EXTENSIVE documentation compared to many other projects, so I don't
think Eric did spaghetti (obfuscated) code in his CML2 tools. After all,
it would not be too helpful to counter the goals for CML2 with the very
implementation...

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Kai Henningsen]

jcowan@reutershealth.com (John Cowan)  wrote on 06.12.01 in <3C0FEE80.2050603@reutershealth.com>:

> Horst von Brand wrote:
>
>  > I just shudder when thinking that I'll have to learn yet another weird
>  > language to be able to hack on Linux... C, gcc-isms with asm() and all, a
>  > bit of CML1, now CML2, are OK; and now Python...
>
> You only need to learn Python if you are going to change the
> CML2 compiler or interpreter, not if you are just changing
> CML2.  You might as well complain that you must learn
> Python to hack GNU Mailman.

Or learning gcc RTL and trees to be able to hack the kernel. Just in case  
a gcc bug makes it miscompile the kernel.

Mind you: I think Python syntax stinks. But I don't expect to need to  
understand it for this.

MfG Kai

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Horst von Brand <vonbrand@inf.utfsm.cl>:
> I just shudder when thinking that I'll have to learn yet another weird
> language to be able to hack on Linux... C, gcc-isms with asm() and all, a
> bit of CML1, now CML2, are OK; and now Python...

You will not need to use Pytho to learn CML2.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Government is actually the worst failure of civilized man. There has
never been a really good one, and even those that are most tolerable
are arbitrary, cruel, grasping and unintelligent.
	-- H. L. Mencken 

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Martin Dalecki]

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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[David Weinehall]

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 <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Matthias Andree]

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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Alan Cox]

> 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

Re: Converting the 2.5 kernel to kbuild 2.5

[Cameron Simpson]

On Tue, Dec 04, 2001 at 05:44:19PM +0000, Alan Cox <alan@lxorguk.ukuu.org.uk> 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        cs@zip.com.au    http://www.zip.com.au/~cs/

A motorcycle is like a toothbrush.  Everyone should have their own.
	- roserunr@noller.com

Re: Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Cameron Simpson <cs@zip.com.au>:
> 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

CML2 with python1

[Jan Harkes]

On Wed, Dec 05, 2001 at 03:29:54AM -0500, Eric S. Raymond wrote:
> Cameron Simpson <cs@zip.com.au>:
> > 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

Re: CML2 with python1

[Eric S. Raymond]

Jan Harkes <jaharkes@cs.cmu.edu>:
> 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

Re: CML2 with python1

[Pavel Machek]

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
> 

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Alan Cox]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Martin Dalecki]

"Eric S. Raymond" wrote:
> 
> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > > 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.

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Christoph Hellwig]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Alan Cox]

> 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Alan Cox]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Robert Love]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Bernhard Rosenkraenzer]

On Tue, 4 Dec 2001, Eric S. Raymond wrote:

> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > > 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Matthias Andree]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Martin Dalecki]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Tom Rini]

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/

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Alan Cox]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Tom Rini]

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/

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Stefan Smietanowski]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Tom Rini]

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/

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Martin Dalecki]

> > Thanks but NO thanks
> 
> Then go help Greg Banks in his CML2-in-C project.

Why? The current system works fine for me!

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[David Woodhouse]

esr@thyrsus.com 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Giacomo Catenazzi]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

Giacomo Catenazzi <cate@dplanet.ch>:
> 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[David Woodhouse]

esr@thyrsus.com 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Daniel Phillips]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Daniel Phillips]

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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[David Woodhouse]

cate@dplanet.ch 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
> 
> cate@dplanet.ch 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
> 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[David Woodhouse]

esr@thyrsus.com 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
> 
> esr@thyrsus.com 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

Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5

[John Stoffel]

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
	 stoffel@lucent.com - http://www.lucent.com - 978-952-7548