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

[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

[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

[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

[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

[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

[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

[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

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

[RaúlNúñez de Arenas Coronado]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

    Hi Matthias :)

>Creating a dependency on Python? Is a non-issue.

    Maybe for you. For me it *is* an issue. I don't like more and
more dependencies for the kernel. I mean, if I can drop kbuild and
keep on building the kernel with the old good 'make config' I won't
worry, but otherwise I don't think that kernel building depends on
something like Python.

    Why must I install Python in order to compile the kernel? I don't
understand this. I think there are better alternatives, but kbuild
seems to be imposed any way.

>You don't make the pen yourself when writing a letter either.

    I don't like to be forced in a particular pen, that's the reason
why I use and develop for linux.

>What are the precise issues with Python? Just claiming it is an
>issue is not useful for discussing this. Archive pointers are
>welcome.

    Well, let's start writing kernel drivers with Python, Perl, PHP,
awk, etc... And, why not, C++, Ada, Modula, etc...

    The kernel should depend just on the compiler and assembler, IMHO.

    Raúl

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

[Jakob Kemi]

On Tuesdayen den 4 December 2001 18.08, RaúlNúñez de Arenas	 Coronado wrote:
>     Hi Matthias :)
>
> >Creating a dependency on Python? Is a non-issue.
>
>     Maybe for you. For me it *is* an issue. I don't like more and
> more dependencies for the kernel. I mean, if I can drop kbuild and
> keep on building the kernel with the old good 'make config' I won't
> worry, but otherwise I don't think that kernel building depends on
> something like Python.
>
>     Why must I install Python in order to compile the kernel? I don't
> understand this. I think there are better alternatives, but kbuild
> seems to be imposed any way.
>
> >You don't make the pen yourself when writing a letter either.
>
>     I don't like to be forced in a particular pen, that's the reason
> why I use and develop for linux.
>
> >What are the precise issues with Python? Just claiming it is an
> >issue is not useful for discussing this. Archive pointers are
> >welcome.
>
>     Well, let's start writing kernel drivers with Python, Perl, PHP,
> awk, etc... And, why not, C++, Ada, Modula, etc...
>
>     The kernel should depend just on the compiler and assembler, IMHO.

And you'll select and pass every .c file directly to the compiler via the 
command line ?? Sounds like a giant step forwards !!

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

[Tom Rini]

On Tue, Dec 04, 2001 at 06:08:57PM +0100, Ra?l N??ez de Arenas Coronado wrote:
>     Hi Matthias :)
> 
> >Creating a dependency on Python? Is a non-issue.
> 
>     Maybe for you. For me it *is* an issue. I don't like more and
> more dependencies for the kernel. I mean, if I can drop kbuild and
> keep on building the kernel with the old good 'make config' I won't
> worry, but otherwise I don't think that kernel building depends on
> something like Python.

One of the things that I _think_ is happening is that lots of other
scripts/ files are being redone, and thus removing them from the list,
so in effect we're trading out one or two for just Python.

>     Why must I install Python in order to compile the kernel? I don't
> understand this. I think there are better alternatives, but kbuild
> seems to be imposed any way.

kbuild != CML2.  It all boils down to the current 'language' having no
real definitive spec, and having 3+ incompatible parsers.  We could
either try and tweak the language slightly (and probably make it even
harder on external parsers) or throw it out and try again.  ESR wrote
CML2 with a Python interpreter, so it uses Python.  The spec for CML2 is
out there, and there's even a CML2-in-C project.  If you don't want to
use Python, go help (I believe Greg Banks is who ESR mentioned is in
charge of it) that project out and then convince Linus to include it.

> >You don't make the pen yourself when writing a letter either.
> 
>     I don't like to be forced in a particular pen, that's the reason
> why I use and develop for linux.

To carry this analogy out a bit more, the details on how to make a pen
exist, so if you don't like ESRs pen, go make your own.  That's why a
lot of people use Linux too.

> >What are the precise issues with Python? Just claiming it is an
> >issue is not useful for discussing this. Archive pointers are
> >welcome.
> 
>     Well, let's start writing kernel drivers with Python, Perl, PHP,
> awk, etc... And, why not, C++, Ada, Modula, etc...
> 
>     The kernel should depend just on the compiler and assembler, IMHO.

The right tools for the right job.  C is good for the kernel.  Python is
good at manipulating strings.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

[Eric S. Raymond]

Tom Rini <trini@kernel.crashing.org>:
> >     Maybe for you. For me it *is* an issue. I don't like more and
> > more dependencies for the kernel. I mean, if I can drop kbuild and
> > keep on building the kernel with the old good 'make config' I won't
> > worry, but otherwise I don't think that kernel building depends on
> > something like Python.
> 
> One of the things that I _think_ is happening is that lots of other
> scripts/ files are being redone, and thus removing them from the list,
> so in effect we're trading out one or two for just Python.

That is my intention.

> The right tools for the right job.  C is good for the kernel.  Python is
> good at manipulating strings.

*Perl* is good at strings.  Python is good at actual data structures :-).
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The people of the various provinces are strictly forbidden to have in their
possession any swords, short swords, bows, spears, firearms, or other types
of arms. The possession of unnecessary implements makes difficult the
collection of taxes and dues and tends to foment uprisings.
        -- Toyotomi Hideyoshi, dictator of Japan, August 1588

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

[Greg Banks]

[Cc: list trimmed]

Tom Rini wrote:
> 
> [...  The spec for CML2 is
> out there, and there's even a CML2-in-C project.  If you don't want to
> use Python, go help (I believe Greg Banks is who ESR mentioned is in
> charge of it) that project out [...]

  In charge of it?  I *am* it.  At least, I was it; I haven't done much
on it for a few months.  I got bogged down trying to reproduce Eric's symbol
freezing semantics with my undoable data structure, and then other things
came up.  Besides the whole Python issue seemed to have died down.

  The latest (unreleased) code has GTK and curses GUIs (the curses GUI reuses
the CML1 dialog code so it looks very much like CML1 "make menuconfig"), but
is several months behind tracking CML2 language changes.

  If people are interested in contributing, I'd be happy to put the project
on sourceforge.  But judging by the download counter for the last release at

http://www.alphalink.com.au/~gnb/gcml2/

nobody really cares ;-)  It seems my main contribution has been to provide
Eric with incentive to clarify his language spec and speed up his parser.

Greg.
-- 
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down.	   - Roger Sandall, The Age, 28Sep2001.

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

[Eric S. Raymond]

Greg Banks <gnb@alphalink.com.au>:
>                It seems my main contribution has been to provide
> Eric with incentive to clarify his language spec and speed up his parser.

Stimulus for which I have been deeply grateful.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

..every Man has a Property in his own Person. This no Body has any
Right to but himself.  The Labour of his Body, and the Work of his
Hands, we may say, are properly his. .... The great and chief end
therefore, of Mens uniting into Commonwealths, and putting themselves
under Government, is the Preservation of their Property.
	-- John Locke, "A Treatise Concerning Civil Government"

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

[David Weinehall]

On Tue, Dec 04, 2001 at 06:08:57PM +0100, RaúlNúñez de Arenas Coronado wrote:
>     Hi Matthias :)
> 
> >Creating a dependency on Python? Is a non-issue.
> 
>     Maybe for you. For me it *is* an issue. I don't like more and
> more dependencies for the kernel. I mean, if I can drop kbuild and
> keep on building the kernel with the old good 'make config' I won't
> worry, but otherwise I don't think that kernel building depends on
> something like Python.
> 
>     Why must I install Python in order to compile the kernel? I don't
> understand this. I think there are better alternatives, but kbuild
> seems to be imposed any way.
> 
> >You don't make the pen yourself when writing a letter either.
> 
>     I don't like to be forced in a particular pen, that's the reason
> why I use and develop for linux.
> 
> >What are the precise issues with Python? Just claiming it is an
> >issue is not useful for discussing this. Archive pointers are
> >welcome.
> 
>     Well, let's start writing kernel drivers with Python, Perl, PHP,
> awk, etc... And, why not, C++, Ada, Modula, etc...

Noone's suggested writing kernel-drivers in anything but a combination
of C and assembler (with as little asm as possible), apart from some
heretics that suggested usage of C++ in the kernel...

This only involves usage of Python2 for configuring your kernel.

>     The kernel should depend just on the compiler and assembler, IMHO.

Yeah, let's lose the dependencies on perl, make, awk, sed, ld, ar,
nm, strip, objcopy, objdump, depmod, grep, xargs, find, gzip,
wish, tcl/tk and possibly others. That'd surely shave a lot of diskspace
off my buildsystem. It's not like I use any of them for anything else...

Hey, lets lose C and ASM too, and create all your binaries by
writing hexvalues into a file.


/David Weinehall
  _                                                                 _
 // 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

[Eric S. Raymond]

David Weinehall <tao@acc.umu.se>:
> Yeah, let's lose the dependencies on perl, make, awk, sed, ld, ar,
> nm, strip, objcopy, objdump, depmod, grep, xargs, find, gzip,
> wish, tcl/tk and possibly others. That'd surely shave a lot of diskspace
> off my buildsystem. It's not like I use any of them for anything else...

I'm going to remove a few of these.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

You need only reflect that one of the best ways to get yourself a
reputation as a dangerous citizen these days is to go about repeating
the very phrases which our founding fathers used in the great struggle
for independence.	-- Attributed to Charles Austin Beard (1874-1948)

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

[David Weinehall]

On Tue, Dec 04, 2001 at 01:43:20PM -0500, Eric S. Raymond wrote:
> David Weinehall <tao@acc.umu.se>:
> > Yeah, let's lose the dependencies on perl, make, awk, sed, ld, ar,
> > nm, strip, objcopy, objdump, depmod, grep, xargs, find, gzip,
> > wish, tcl/tk and possibly others. That'd surely shave a lot of diskspace
> > off my buildsystem. It's not like I use any of them for anything else...
> 
> I'm going to remove a few of these.

You know, I _was_ ironic about not needing most of those...


/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 Tue, 04 Dec 2001, RaúlNúñez de Arenas Coronado wrote:

>     Why must I install Python in order to compile the kernel? I don't
> understand this. I think there are better alternatives, but kbuild
> seems to be imposed any way.

Because the Gods of the Kernel command so, simply put. I fail to see the
mutual implications of kbuild and CML2 however. I have until now seen
these as separate (independent of each other) efforts which are both
proposed for early 2.5.x inclusion.

> >What are the precise issues with Python? Just claiming it is an
> >issue is not useful for discussing this. Archive pointers are
> >welcome.
> 
>     Well, let's start writing kernel drivers with Python, Perl, PHP,
> awk, etc... And, why not, C++, Ada, Modula, etc...

Please don't mix the "layers" here. You don't need Python to run the
kernel.

>     The kernel should depend just on the compiler and assembler, IMHO.

less Documentation/Changes
/Current Minimal Requirements -- that's for running, BTW, not for
compiling. Oops.

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

[Stevie O]

At 07:46 PM 12/4/2001 +0100, David Weinehall wrote:
>Yeah, let's lose the dependencies on perl, make, awk, sed, ld, ar,
>nm, strip, objcopy, objdump, depmod, grep, xargs, find, gzip,
>wish, tcl/tk and possibly others. That'd surely shave a lot of diskspace
>off my buildsystem. It's not like I use any of them for anything else...
>
>Hey, lets lose C and ASM too, and create all your binaries by
>writing hexvalues into a file.

Real kernel hackers use

# cat > /vmlinuz; lilo; shutdown -r now



--
Stevie-O

Real programmers use COPY CON PROGRAM.EXE

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

[Wayne.Brown]

It's not the CML1 language spec that interests me, just the user interface.  All
I care about is being able to do make menuconfig and make oldconfig, and get the
same results as before.  What goes on "under the surface" doesn't interest me at
all.

In fact, here's all I want to know about the whole CML2/kbuild 2.5 issue.  Right
now I upgrade my kernel like this (simplified slightly):

<apply latest patches>
mv .config ..
make mrproper
mv ../.config .
make oldconfig
make dep
make bzlilo modules modules_install
<reboot>

Will I still be able to do it this simply in 2.5.x?  (Assuming there's
eventually a 2.5.x I can get to compile cleanly.  :-)

Wayne




John Stoffel <stoffel@casc.com> on 12/04/2001 10:31:10 AM

To:   Christoph Hellwig <hch@caldera.de>
cc:   Keith Owens <kaos@ocs.com.au>, kbuild-devel@lists.sourceforge.net,
      linux-kernel@vger.kernel.org, torvalds@transmeta.com (bcc: Wayne
      Brown/Corporate/Altec)

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




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

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

[Eric S. Raymond]

Wayne.Brown@altec.com <Wayne.Brown@altec.com>:
> It's not the CML1 language spec that interests me, just the user
> interface.  All I care about is being able to do make menuconfig and
> make oldconfig, and get the same results as before.  What goes on
> "under the surface" doesn't interest me at all.
> 
> In fact, here's all I want to know about the whole CML2/kbuild 2.5
> issue.  Right now I upgrade my kernel like this (simplified
> slightly):
> 
> <apply latest patches>
> mv .config ..
> make mrproper
> mv ../.config .
> make oldconfig
> make dep
> make bzlilo modules modules_install
> <reboot>
> 
> Will I still be able to do it this simply in 2.5.x?  (Assuming there's
> eventually a 2.5.x I can get to compile cleanly.  :-)

Yes.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Never trust a man who praises compassion while pointing a gun at you.

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

[Giacomo Catenazzi]

Wayne.Brown@altec.com wrote:

> 
> In fact, here's all I want to know about the whole CML2/kbuild 2.5 issue.  Right
> now I upgrade my kernel like this (simplified slightly):
> 
> <apply latest patches>
> mv .config ..
> make mrproper
> mv ../.config .
> make oldconfig
> make dep
> make bzlilo modules modules_install
> <reboot>
> 
> Will I still be able to do it this simply in 2.5.x?  (Assuming there's
> eventually a 2.5.x I can get to compile cleanly.  :-)
> 


Yes you can do.
hmm. only for the CML2 part. The new kbuild-2.5 (also the new Makefile)
will no more work with your command:
make dep: is no more needed
make bzlilo modules modules_install: it would be a simble
make install: (and you configure with CML1/CML2 what install
means).

	giacomo

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

[Alan Cox]

> make bzlilo modules modules_install: it would be a simble
> make install: (and you configure with CML1/CML2 what install
> means).

How does it handle that when install means different things on each box of
a set of them NFS sharing the kernel tree. This is a real world example

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

[Tom Rini]

On Tue, Dec 04, 2001 at 06:21:15PM +0000, Alan Cox wrote:
> > make bzlilo modules modules_install: it would be a simble
> > make install: (and you configure with CML1/CML2 what install
> > means).
> 
> How does it handle that when install means different things on each box of
> a set of them NFS sharing the kernel tree. This is a real world example

I'd guess  you can change the module install path, and re-run 'install'
without having anything rebuilt.  Admiditly a bit worse off than
INSTALL_MOD_PATH=/nfs/boxA.  Or set the install paths to
.../kernel-XXX/, tar and untar.

Or if /usr/local/src/linux is NFS'ed, and you're installing per box, I
don't get it.  Wouldn't you always install modules into /lib/modules/XXX
?

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

[Keith Owens]

On Tue, 4 Dec 2001 18:21:15 +0000 (GMT), 
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> make bzlilo modules modules_install: it would be a simble
>> make install: (and you configure with CML1/CML2 what install
>> means).
>
>How does it handle that when install means different things on each box of
>a set of them NFS sharing the kernel tree. This is a real world example

I made kbuild 2.5 install very flexible to cater for cases like this.
The answer depends on whether you want every compile to be the same
with different install steps on the target machines or each compile is
different.

In the different compile case you have a single source tree (mounted
read only if you like) and separate object trees for each compile run.
The .config lives in the object directory so is machine local.  The
object trees can be NFS mounted or can use local disk on each build
machine, as a bonus this avoids NFS writes and runs much faster.

If you want a common compile on one machine followed by different
installs on each machine then you have three choices.

(1) make install with an install prefix path (say /var/tmp) will
    install the kernel, modules, System.map and .config in a holding
    directory on the build machine, the other machines can then copy
    the install data to wherever they need it.  Whether the copy is
    done from the build machine to the target directories or on the
    target machine is an NFS implementation detail.

(2) make installable (the default target) on the build machine then run
    make install with overrides on the target machines.  All the
    install config variables are exposed for override on the install
    step.

(3) make installable on the build machine with .config specifying an
    install script name.  Then make install on each target system, the
    version of the install script is local to the target machine.

If none of those suit your environment, let me know what you are trying
to achieve and I will see about adding support to kbuild 2.5.

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

[David Weinehall]

On Wed, Dec 05, 2001 at 10:00:32AM +1100, Keith Owens wrote:
> On Tue, 4 Dec 2001 18:21:15 +0000 (GMT), 
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >> make bzlilo modules modules_install: it would be a simble
> >> make install: (and you configure with CML1/CML2 what install
> >> means).
> >
> >How does it handle that when install means different things on each box of
> >a set of them NFS sharing the kernel tree. This is a real world example
> 
> I made kbuild 2.5 install very flexible to cater for cases like this.
> The answer depends on whether you want every compile to be the same
> with different install steps on the target machines or each compile is
> different.
> 
> In the different compile case you have a single source tree (mounted
> read only if you like) and separate object trees for each compile run.
> The .config lives in the object directory so is machine local.  The
> object trees can be NFS mounted or can use local disk on each build
> machine, as a bonus this avoids NFS writes and runs much faster.
> 
> If you want a common compile on one machine followed by different
> installs on each machine then you have three choices.
> 
> (1) make install with an install prefix path (say /var/tmp) will
>     install the kernel, modules, System.map and .config in a holding
>     directory on the build machine, the other machines can then copy
>     the install data to wherever they need it.  Whether the copy is
>     done from the build machine to the target directories or on the
>     target machine is an NFS implementation detail.
> 
> (2) make installable (the default target) on the build machine then run
>     make install with overrides on the target machines.  All the
>     install config variables are exposed for override on the install
>     step.
> 
> (3) make installable on the build machine with .config specifying an
>     install script name.  Then make install on each target system, the
>     version of the install script is local to the target machine.
> 
> If none of those suit your environment, let me know what you are trying
> to achieve and I will see about adding support to kbuild 2.5.

Would it be easy to add hooks for make-rpm and make-kpkg and alike,
as methods for make installable?


/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

[Keith Owens]

On Wed, 5 Dec 2001 00:05:53 +0100, 
David Weinehall <tao@acc.umu.se> wrote:
>Would it be easy to add hooks for make-rpm and make-kpkg and alike,
>as methods for make installable?

I don't want details for any packaging method in kbuild.  kbuild's job
is to build and install the kernel, not wrap it up in a pretty package
for distribution, I have to draw the line somewhere.  In particular I
am not going to support 3-5 different packaging methods in kbuild, nor
am I going to worry about changes in the packaging process, it is SEP.

Having said that, kbuild is extensible.  Users can specify additional
targets, dependencies and rules on the command line, those become part
of the build process.  So redhat, debian, slackware, new distribution
on the block can supply a packaging script and run this command :-

  make ADD0=pkg ADD0_DEP=install ADD0_CMD='my-package-script' pkg

The packaging script is maintained by the package supplier, not by the
kbuild group.

BTW, that example is straight out of the kbuild 2.5 documentation in
Documentation/kbuild/kbuild-2.5.txt, I wish people would read that
file first.

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

[Michael Elizabeth Chastain]

I suppose a polite title for me would be "maintainer emiritus"
of make config, make menuconfig, and make xconfig.

I'm in favor of abandoning the current tools because:

  It's 3x maintenance to have 3 parsers for the same language.

  It's difficult to do good syntax checking in scripts/Configure and
  menuconfig.

  menuconfig in particular is too ugly to live.

  A company which considers Linux its #1 enemy may own the copyright to
  "scripts/Configure".  I don't know what kind of marketing or legal
  play they could make, but it would surely be hostile to Linux.

I'm in favor of CML2 in particular because:

  ESR has designed a clean theory, which the configuration process really
  needs after ten years of ad hoc extensions.

  ESR has done a lot of grunt work to turn a particular idea into a
  viable implementation.  It's hard to get that work done.

As far as the Python issue goes, I believe that the kernel documentation
just needs to state clearly what tools (and what versions) are needed
to build a kernel.  If other people prefer a C implementation, then
CML2 (the language) is amenable to a C implementation, so they can
write one.

As far as CML2 versus an mconfig-based solution, I am tilted towards CML2,
as it is simply a better language.  I would be happy with either choice
if Linus made one of those choices.  I would be unhappy if 2.6/3.0
continued to ship with Configure/menuconfig/xconfig.

Michael Elizabeth Chastain
<mailto:mec@shout.net>
"love without fear"

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

[Christoph Hellwig]

On Tue, Dec 04, 2001 at 11:18:38AM -0600, Michael Elizabeth Chastain wrote:
> As far as CML2 versus an mconfig-based solution, I am tilted towards CML2,
> as it is simply a better language.  I would be happy with either choice
> if Linus made one of those choices.  I would be unhappy if 2.6/3.0
> continued to ship with Configure/menuconfig/xconfig.

Indepenand of wether 2.6 will use CML1 or CML2 I hope it won't ship with
the actual config tool.  It's so much nicer to have mconfig compiled once
in /usr/bin instead of compiling menuconfig all the time in the tree.

No to mention it's much easier to propagate bug fixes this way..

	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

[Mike Fedyk]

On Tue, Dec 04, 2001 at 06:30:45PM +0100, Christoph Hellwig wrote:
> On Tue, Dec 04, 2001 at 11:18:38AM -0600, Michael Elizabeth Chastain wrote:
> > As far as CML2 versus an mconfig-based solution, I am tilted towards CML2,
> > as it is simply a better language.  I would be happy with either choice
> > if Linus made one of those choices.  I would be unhappy if 2.6/3.0
> > continued to ship with Configure/menuconfig/xconfig.
> 
> Indepenand of wether 2.6 will use CML1 or CML2 I hope it won't ship with
> the actual config tool.  It's so much nicer to have mconfig compiled once
> in /usr/bin instead of compiling menuconfig all the time in the tree.
> 
> No to mention it's much easier to propagate bug fixes this way..
> 

If the configure system is outside of the kernel, you have the possibility
of requiring newer user-space utilities as a stable kernel changes over
time...

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

[RaúlNúñez de Arenas Coronado]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

    Hi Eric :))

>(2) Requiring Python introduces another tool into the requisites list for
>kernel building.  

    I'm happy to see that out of your 'silly' list...

>I'm just going to say "Today's problems, today's tools."

    Hey, hope that Python never gets considered a 'today's tool' or
we will end up needing 256 CPU mainframes just to issue an 'ls'
(maybe this will not be enough if filesystem drivers are written in
Python too. In the future, I mean...).

    And yes, Python is a today's problem. Fortunately, people keeps
rewriting their Python code in true languages.

>Progress happens.

    Python is not progress, is just bloatware. I don't think that the
kernel *building* should be made dependant on such a fatware. And,
how about the 'Python License'. I'm pretty sure that it is compatible
with the rest of the kernel, but we should pray for it not to change.

    And, well, Python is fatware just for me: anyway will see
reasonable to install a 6Mb sources language just for the
configuration of the kernel. Very reasonable.

>If you don't like it, feel free to go back to writing Autocoder on your 1401.

    Good policy... People who don't like Python are morons... And
maybe those that neither use Java or C# for the kernel will be too in
a near future, is that what you're trying to say?

    Eric, I think that this is an important issue and that the
decision about adding such a big dependence to the kernel should be
studied with care, and not imposed.

    Raúl

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

[Eric S. Raymond]

Raúl Núñez de Arenas Coronado <raul@viadomus.com>:
>     Eric, I think that this is an important issue and that the
> decision about adding such a big dependence to the kernel should be
> studied with care, and not imposed.

Fine, try to argue that with Linus.  I suspect he'll decide he has better
things to think about, and ignore you.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Society in every state is a blessing, but government even in its best
state is but a necessary evil; in its worst state an intolerable one;
for when we suffer, or are exposed to the same miseries *by a
government*, which we might expect in a country *without government*,
our calamities is heightened by reflecting that we furnish the means
by which we suffer."
	-- Thomas Paine

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

[Edward Muller]

I'm just sick of people saying that python is bloated.

I've put python on my Compaq IPAQ (running linux) and with very few
amounts of tweaks it took up less 1 MB. And that's including gtk
bindings (no tk though) and just about the entire standard python
library. Someone else tried to do this with perl and they couldn't get
it under 3 MB IIRC. And IIRC, the current kernel build system requires
perl (I could be wrong, I'm just a watcher on this list, not a hacker).
So ... PYTHON IS NOT BLOATED.

Python maybe slow (when compared to C/C++ code). But that is the nature
of an interpreted language. Python's speed is on par with Perl's and
most other interpreted languages.

Anyway ... I'm done venting.

On Tue, 2001-12-04 at 13:30, RaúlNúñez de Arenas Coronado wrote:
>     Hi Eric :))
> 
> >(2) Requiring Python introduces another tool into the requisites list for
> >kernel building.  
> 
>     I'm happy to see that out of your 'silly' list...
> 
> >I'm just going to say "Today's problems, today's tools."
> 
>     Hey, hope that Python never gets considered a 'today's tool' or
> we will end up needing 256 CPU mainframes just to issue an 'ls'
> (maybe this will not be enough if filesystem drivers are written in
> Python too. In the future, I mean...).
> 
>     And yes, Python is a today's problem. Fortunately, people keeps
> rewriting their Python code in true languages.
> 
> >Progress happens.
> 
>     Python is not progress, is just bloatware. I don't think that the
> kernel *building* should be made dependant on such a fatware. And,
> how about the 'Python License'. I'm pretty sure that it is compatible
> with the rest of the kernel, but we should pray for it not to change.
> 
>     And, well, Python is fatware just for me: anyway will see
> reasonable to install a 6Mb sources language just for the
> configuration of the kernel. Very reasonable.
> 
> >If you don't like it, feel free to go back to writing Autocoder on your 1401.
> 
>     Good policy... People who don't like Python are morons... And
> maybe those that neither use Java or C# for the kernel will be too in
> a near future, is that what you're trying to say?
> 
>     Eric, I think that this is an important issue and that the
> decision about adding such a big dependence to the kernel should be
> studied with care, and not imposed.
> 
>     Raúl
> -
> 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

[Edward Muller]

On Tue, 2001-12-04 at 15:07, Robert Love wrote:
> On Tue, 2001-12-04 at 14:50, Edward Muller wrote:
> 
> > I've put python on my Compaq IPAQ (running linux) and with very few
> > amounts of tweaks it took up less 1 MB. And that's including gtk
> > bindings (no tk though) and just about the entire standard python
> > library. Someone else tried to do this with perl and they couldn't get
> > it under 3 MB IIRC. And IIRC, the current kernel build system requires
> > perl (I could be wrong, I'm just a watcher on this list, not a hacker).
> > So ... PYTHON IS NOT BLOATED.
> 
> No, it doesn't require Perl.  Its sh along with the standard Linux
> toolset.  xconfig is Tk, but not binded to Perl.
> 
> Regardless, I don't look at bloat as the issue -- who configures and
> compiles their kernel on an embedded device?  More specifically, it is
> what the kernel hackers have available and want to use that is the
> requirement.  This is partly why the whole "now your mom can easily
> configure her kernel" is a bs argument to me.  Forget my mom..._I_ want
> things a certain way.  My mom, if I ever forc^H^H^H^H get her to use
> Linux, will surely use the distro's kernel.
> 
> 	Robert Love

Re: Perl ...My BAD ... I though someone somewhere listed that perl was a
requirement for building the kernel, but looking at
Documentation/Changes I see I was wrong. In fact Documentation/Changes
already lists 10 necessary packages under the "Minimal Requirements"
section. Anyway ... 

I've been watching the whole CML1 vs. CML2 thing over the past year or
so and I don't think it's ever been about making it easy for a
neophite(sp) to configure their kernel. It's been about the fact that
CML1 is difficult/impossible to maintain in it's current state. I think
the choice was either to fix CML1 (language and tools) or come up with
something new. ESR decided to do the later and picked a tool that he
knew could get the job done. I'd almost bet their wouldn't have been as
much fuss over it if he had chosen perl, instead of python, but that's
just me being biased and cynical (Read: Ignore the comment.)

ESR could have written the CML2 implimentation in assembler, but decided
against it for various portability, code reuse/understandability,
simplicity, etc, etc, etc, reasons (I'll let Eric list them all if he
likes).

And .. Re: configuring a kernel on an embedded device... Well a few
people do actually. :-) I haven't done a lot with my iPAQ recently, but
there were bunches of people configuring and compiling their kernel's on
their ipaq (via nfs, IBM udrive, CF card, etc) last time I was heavily
involved. I was using the iPAQ as a way to illustrate that it's (python)
not all that big and it can fit on a small, embedded device.

And I agree, your Mom, my Mom and their friends, when linux comes to
their computer will use the the kernel that distro X gave them and will
probably never, ever even worry about it. Unless people like you and me
go to their house and upgrade it for them. :-) 


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

[Robert Love]

On Tue, 2001-12-04 at 14:50, Edward Muller wrote:

> I've put python on my Compaq IPAQ (running linux) and with very few
> amounts of tweaks it took up less 1 MB. And that's including gtk
> bindings (no tk though) and just about the entire standard python
> library. Someone else tried to do this with perl and they couldn't get
> it under 3 MB IIRC. And IIRC, the current kernel build system requires
> perl (I could be wrong, I'm just a watcher on this list, not a hacker).
> So ... PYTHON IS NOT BLOATED.

No, it doesn't require Perl.  Its sh along with the standard Linux
toolset.  xconfig is Tk, but not binded to Perl.

Regardless, I don't look at bloat as the issue -- who configures and
compiles their kernel on an embedded device?  More specifically, it is
what the kernel hackers have available and want to use that is the
requirement.  This is partly why the whole "now your mom can easily
configure her kernel" is a bs argument to me.  Forget my mom..._I_ want
things a certain way.  My mom, if I ever forc^H^H^H^H get her to use
Linux, will surely use the distro's kernel.

	Robert Love

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

[Matthias Andree]

On Tue, 04 Dec 2001, RaúlNúñez de Arenas Coronado wrote:

>     Python is not progress, is just bloatware. I don't think that the
> kernel *building* should be made dependant on such a fatware. And,
> how about the 'Python License'. I'm pretty sure that it is compatible
> with the rest of the kernel, but we should pray for it not to change.

You're free to prove there is a significantly leaner solution to the
tasks CML2 fulfills.

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

[Rob Landley]

On Tuesday 04 December 2001 01:30 pm, RaúlNúñez de Arenas	 Coronado wrote:
>     Hi Eric :))
>
> >(2) Requiring Python introduces another tool into the requisites list for
> >kernel building.
>
>     I'm happy to see that out of your 'silly' list...
>
> >I'm just going to say "Today's problems, today's tools."
>
>     Hey, hope that Python never gets considered a 'today's tool' or
> we will end up needing 256 CPU mainframes just to issue an 'ls'

And you've been smoking what to come to this conclusion?  My laptop's a 
pentium 266, and it runs stuff just fine.  (My DESKTOP is a pentium pro 
180...)

You can't attack the performance of the current implementation of CML2, so 
you attack python's performance generically.  Makes perfect sense.

You are aware that what it's replacing in this instance is, in large part, 
shell scripts?  Hello?

You may also want to look at the python-SDL binding, which people have used 
to write action games in python.  (Really.  http://www.pygame.org )

> (maybe this will not be enough if filesystem drivers are written in
> Python too. In the future, I mean...).
>
>     And yes, Python is a today's problem. Fortunately, people keeps
> rewriting their Python code in true languages. 

Ah, you've rediscovered nixon's silent majority, then?  The mysterious "they" 
who always conveniently support your arguments.

Personally, I'm re-writing other stuff in python.  I'm currently working 
(microscopically part-time) on a python nameserver because bind is 
frightening and djbdns is annoying, and it looks like a simple one in python 
should only be a few hundred lines of code.

Are you volunteering to rewrite Anaconda in C?

> >Progress happens.
>
>     Python is not progress, is just bloatware. I don't think that the
> kernel *building* should be made dependant on such a fatware. And,
> how about the 'Python License'.

The most recent version of which is, I believe, GPL compatable.

> I'm pretty sure that it is compatible
> with the rest of the kernel, but we should pray for it not to change.

If a new vesion comes out with an unusable language the project will fork 
into free and non-free versions like dozens of projects before it, several of 
which ARE in the kernel.  You know this, you're just ignoring it.

>     And, well, Python is fatware just for me: anyway will see
> reasonable to install a 6Mb sources language just for the
> configuration of the kernel.

The sources of which already take 260 megs, not counting the space to 
actually compile them or the tools needed to do so now.  (And then if you 
want to look at the source code to those other tools...  Look at glibc ye 
mighty and despair...)

> Very reasonable.

Yes.

> >If you don't like it, feel free to go back to writing Autocoder on your
> > 1401.
>
>     Good policy... People who don't like Python are morons... And
> maybe those that neither use Java or C# for the kernel will be too in
> a near future,

You're confusing "writing the kernel in $LANGUAGE" with "using a tool written 
in $LANGUAGE to build the kernel".  Replace $LANGUAGE with C++ and go search 
the archives to see this boundary previously deliniated...

> is that what you're trying to say?

Well, at least you admit you don't know.  There's hope.

>     Eric, I think that this is an important issue and that the
> decision about adding such a big dependence to the kernel should be
> studied with care, and not imposed.

Why start now?

The kernel tree currently uses perl and tcl/tk.  Anybody remember those being 
debated at length before they went in?  Anybody volunteering to MAINTAIN perl 
code?  (A write-only language?)

Eric's stated that there's a net reduction in the number of dispirate tools 
needed to configure the kernel.  There's certainly less in terms of lines of 
code...

Have you ever looked at the current configurator mess? 

>     Raúl

Rob

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

[Eric S. Raymond]

Rob Landley <landley@trommello.org>:
> Eric's stated that there's a net reduction in the number of dispirate tools 
> needed to configure the kernel.  There's certainly less in terms of lines of 
> code...

Actually, I haven't.  I have stated that I *know how* to get a net reduction, 
but that I haven't done that work yet.  After CML2 drops in I will do that 
work.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The real point of audits is to instill fear, not to extract revenue;
the IRS aims at winning through intimidation and (thereby) getting
maximum voluntary compliance
	-- Paul Strassel, former IRS Headquarters Agent Wall St. Journal 1980

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

[Wayne.Brown]

Amen!  Those are *exactly* the reasons I play with kernel upgrades.

Wayne




Alan Cox <alan@lxorguk.ukuu.org.uk> on 12/04/2001 12:26:27 PM

To:   trini@kernel.crashing.org (Tom Rini)
cc:   dalecki@evision.ag, alan@lxorguk.ukuu.org.uk (Alan Cox),
      matthias.andree@stud.uni-dortmund.de (Matthias Andree),
      linux-kernel@vger.kernel.org, hch@caldera.de (Christoph Hellwig),
      esr@thyrsus.com (Eric S. Raymond), kaos@ocs.com.au (Keith Owens),
      kbuild-devel@lists.sourceforge.net, torvalds@transmeta.com (bcc: Wayne
      Brown/Corporate/Altec)

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



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

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

[RaúlNúñez de Arenas Coronado]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

    Hi Tom :))

>>     Why must I install Python in order to compile the kernel? I don't
>> understand this. I think there are better alternatives, but kbuild
>> seems to be imposed any way.
>kbuild != CML2.

    Yes, sorry, just a mental shortcircuit ;))

>It all boils down to the current 'language' having no
>real definitive spec, and having 3+ incompatible parsers.

    Yes, I know and I think that is a good thing to have a good
configuration language, and it means having a good specification and
a good parser. Just I don't think that 6Mb-Python is a good way to
write a good parser. Well, I'm sure that I cannot do better (right
now), so I don't want to flame anyone with this, just want to show my
opinion (shared by many, although) and show the negative points of
having Python as a dependence.

>The spec for CML2 is out there, and there's even a CML2-in-C project.

    How advanced? Where is the spec, please?

>that project out and then convince Linus to include it.

    Hard job... Convincing Linus, I mean ;)))

>>     The kernel should depend just on the compiler and assembler, IMHO.
>The right tools for the right job.  C is good for the kernel.  Python is
>good at manipulating strings.

    Well, IMHO Python is good only in being big and doing things
slow, but... why the parser cannot be built over flex/bison?. That
way it can be 'pregenerated' and people won't need additional tools
to build the kernel.

    Raúl

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

[Tom Rini]

On Tue, Dec 04, 2001 at 07:50:45PM +0100, Ra?l N??ez de Arenas Coronado wrote:

> >The spec for CML2 is out there, and there's even a CML2-in-C project.
> 
>     How advanced? Where is the spec, please?

I'm not sure how far the C version is, the spec is:
http://www.tuxedo.org/~esr/cml2/cml2-reference.html

> >>     The kernel should depend just on the compiler and assembler, IMHO.
> >The right tools for the right job.  C is good for the kernel.  Python is
> >good at manipulating strings.
> 
>     Well, IMHO Python is good only in being big and doing things
> slow, but... why the parser cannot be built over flex/bison?. That
> way it can be 'pregenerated' and people won't need additional tools
> to build the kernel.

ESR didn't feel it was the right choice, basically.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

[Matthias Andree]

On Tue, 04 Dec 2001, RaúlNúñez de Arenas Coronado wrote:

>     Well, IMHO Python is good only in being big and doing things
> slow, but... why the parser cannot be built over flex/bison?. That
> way it can be 'pregenerated' and people won't need additional tools
> to build the kernel.

Go ahead. Until then, as an interim solution, ship the .depend stuff as
well so people won't need make dep...

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

[RaúlNúñez de Arenas Coronado]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

>>     Eric, I think that this is an important issue and that the
>> decision about adding such a big dependence to the kernel should be
>> studied with care, and not imposed.
>Fine, try to argue that with Linus.  I suspect he'll decide he has better
>things to think about, and ignore you.

    No, I won't argue this with anyone. You have reason, oh blessed ESR,
and I'm currently downloading Python2 just to betatest new kernels as
soon as they are published.

    BTW, ignore me you too, please. I'll try to do the same.

    Raúl