Will 2.6 require Python for any configuration ? (CML2)

Will 2.6 require Python for any configuration ? (CML2)

[=?unknown-8bit?B?RnLpZOlyaWMgTC4gVy4=?= Meunier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 1017 bytes --]

Am I the only one afraid that the Python requirement can turn
into a problem ? You can develop anything on Linux without
Python. I'd compare Python to Tcl - you only install it to
waste space, develop, or run applications that use it. Perl
is very different. It's required by GNU Automake and more.

I'm really surprised by the fact that nobody noticed what a
nightmare 2.6 will be with such a requirement. You can't
expect everybody to install something that's of no use for
most.

My intention isn't to diminish the importance of CML2 and the
hard and volunteer work of Eric S. Raymond. I just can't
consider Python a requirement to configure the build process
of a Kernel.

Please, consider using the actual setup if Python isn't
installed.

PS: I install Python at home to use a single application.
BTW, I compiled Python and... the curses module isn't enabled
by default. You have to edit Setup. Another possible problem
for menuconfig.

-- 
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niterói-RJ BR)

Re: Will 2.6 require Python for any configuration ? (CML2)

[Roland Bauerschmidt]

Fr?d?ric L. W. Meunier wrote:
> Am I the only one afraid that the Python requirement can turn
> into a problem ? You can develop anything on Linux without
> Python. I'd compare Python to Tcl - you only install it to
> waste space, develop, or run applications that use it. Perl
> is very different. It's required by GNU Automake and more.
> 
> I'm really surprised by the fact that nobody noticed what a
> nightmare 2.6 will be with such a requirement. You can't
> expect everybody to install something that's of no use for
> most.

Well, I don't know the details of the plans, but IMHO is a dependency to
python for configuring the kernel not unreasonable. Nowadays a lot of
people don't even compile their kernels themselves, and thus not
_everybody_ is required to have python installed. When using make
menuconfig you are also required to have curses development files
installed even if you don't need them for anything else. Python also is
of (fast) growing popularity, and for example in Debian (I don't know
about other distributions, but I suppose it's similar there) Python is
Priority: standard (whereas libncurses5-dev surely isn't). 

You my 0.02$, Roland

-- 
Roland Bauerschmidt

Re: Will 2.6 require Python for any configuration ? (CML2)

[Bob Glamm]

> > Am I the only one afraid that the Python requirement can turn
> > into a problem ? You can develop anything on Linux without
> > Python. I'd compare Python to Tcl - you only install it to
> > waste space, develop, or run applications that use it. Perl
> > is very different. It's required by GNU Automake and more.
> > 
> > I'm really surprised by the fact that nobody noticed what a
> > nightmare 2.6 will be with such a requirement. You can't
> > expect everybody to install something that's of no use for
> > most.
> 
> Well, I don't know the details of the plans, but IMHO is a dependency to
> python for configuring the kernel not unreasonable. Nowadays a lot of
> people don't even compile their kernels themselves, and thus not
> _everybody_ is required to have python installed. When using make

I bet the same number of people still compile their own kernels.
However, the *percentage* of people that still compile their own
kernels probably keeps shrinking as the number of people using
Linux increases.

The same argument applies now that applies when this argument first
started when ESR announced CML to the list: my '386 with 8MB of
RAM and it's 20MB of disk doesn't have the room (or speed, for
that matter) to install the fad interpreted language of today.
Besides, it'll take me 45 minutes to download the latest version
of Python over my 28.8k modem.  And yes, I download the kernel patch
by patch to minimize the download pain ;)

Why isn't ncurses a pain?  For the same reason ncurses wasn't a
pain when 'make menuconfig' (lxdialog) was introduced (yes, I did many a 
'make config'):  curses/ncurses was already on just about every
system running Linux - it was built into the text editor.

> menuconfig you are also required to have curses development files
> installed even if you don't need them for anything else. Python also is
> of (fast) growing popularity, and for example in Debian (I don't know
> about other distributions, but I suppose it's similar there) Python is
> Priority: standard (whereas libncurses5-dev surely isn't). 

Believe it or not, there are people like me that take a distribution,
do a minimal install just to get a machine up and running, then remove
most of the package management software from the installation once
networking has been configured, then continually update software
from source as new fixes are released.  I managed to update an
early version of Slackware from the earliest libc4 releases through
libc6 without ever touching a distribution disk - all updated through
source.

But I would expect that I'm in the minority in this regard. ;)

It does surprise me that Linus would actually allow this to happen.
It's been my impression that he favors a clean, elegant solution.
Maybe it's just me, but adding a dependency solely for the sake of
building the kernel doesn't strike me as very clean or elegant.

-Bob

Re: Will 2.6 require Python for any configuration ? (CML2)

[Disconnect]

On Thu, 23 Aug 2001, Bob Glamm did have cause to say:

> The same argument applies now that applies when this argument first
> started when ESR announced CML to the list: my '386 with 8MB of
> RAM and it's 20MB of disk doesn't have the room (or speed, for
> that matter) to install the fad interpreted language of today.
> Besides, it'll take me 45 minutes to download the latest version
> of Python over my 28.8k modem.  And yes, I download the kernel patch
> by patch to minimize the download pain ;)

[stuff cut]

> It does surprise me that Linus would actually allow this to happen.

>From the original message:

> (For those of you who grumbled about adding Python to the build-tools
> set, Linus has uttered a ukase: CML2's reliance on Python is not an
> issue.  I have promised that once CML2 is incorporated I will actually
> *reduce* the kernel tree's net dependence on external tools, and I know
> exactly how to deliver on that promise.)

My suspicion is (and I have no inside knowledge on this) he is going to do
something along the lines of the python-to-c converter -- the only people
who need python after that is done are those people working on the
configuration *engine* (not the rules files, and certainly not just to
configure/build the kernel).  Although come to think of it, a stripped
down python interpreter (in C) would also work, with roughly the same
'build the tools along the way' as the current menuconfig.  Either way, I
would be very surprised if I downloaded a stable kernel and it -required-
python.

Those are the ways (off the top of my head) to reduce the dependence on
external tools and still use python. (Although it is one of my favorite
scripting languages, I agree that it is a bit much just to configure a
kernel.) I wouldn't be surprised if, while he was at it, a lot of the
other tool dependencies got pulled out (tcl/tk, etc) such that make
menuconfig requires only libncurses and gcc, make xconfig requires only
xlib and gcc, etc.

This message brought to you by my vivid imagination, and may bear little
to no resemblence to reality. Do not taunt Happy Fun Message. ;)

---
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C++++$ ULBS*++++$ P- L+++>+++++ 
E--- W+++ N+@ o+>$ K? w--->+++++ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b++++>$ DI++++ D++(+++) G++ e* h(-)* r++ y++
------END GEEK CODE BLOCK------

Re: Will 2.6 require Python for any configuration ? (CML2)

[Daniel Phillips]

On August 23, 2001 05:55 pm, Disconnect wrote:
> Those are the ways (off the top of my head) to reduce the dependence on
> external tools and still use python. (Although it is one of my favorite
> scripting languages, I agree that it is a bit much just to configure a
> kernel.)

Take a close look at the word "just" in that sentence.  Kernel configuration 
is not a trivial task at all and it gets less trivial every time Linux gets 
more general.

--
Daniel

Re: Will 2.6 require Python for any configuration ? (CML2)

[Disconnect]

On Thu, 23 Aug 2001, Daniel Phillips did have cause to say:
> Take a close look at the word "just" in that sentence.  Kernel configuration 
> is not a trivial task at all and it gets less trivial every time Linux gets 
> more general.

I don't disagree. But the point isn't how trivial or non-trivial the task
of configuring the kernel is, the point is for a lot of people it is the
ONLY task that they will use python for.  And everyone who builds a kernel
will have gcc, so thats the 'ideal' dependency.  Second and third most
likely, a C++ compiler or perl (depending on what you figure the
installbase of each one is).  Forth, some form of java runtime.  And after
that is python.  (I'm not advocating using any of the above for kernel
configuration. But they are more likely to already be installed than
python is.)

What this says is that either linux sources are going to grow (and the
build process get more complex) by whatever the size of the python
interpreter is, OR some method will be used that doesn't require a
separate interpreter.

This is also in agreement with his statement about reducing the dependence
on external tools, whereas requiring everyone to install python does not.  
It could either be read as using straight gcc C -or- as including all the
external tools in buildable form.  I'm betting on the former.

---
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C++++$ ULBS*++++$ P- L+++>+++++ 
E--- W+++ N+@ o+>$ K? w--->+++++ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b++++>$ DI++++ D++(+++) G++ e* h(-)* r++ y++
------END GEEK CODE BLOCK------

Re: Will 2.6 require Python for any configuration ? (CML2)

[David Weinehall]

On Thu, Aug 23, 2001 at 02:44:06PM -0400, Disconnect wrote:
> On Thu, 23 Aug 2001, Daniel Phillips did have cause to say:
> > Take a close look at the word "just" in that sentence.  Kernel configuration 
> > is not a trivial task at all and it gets less trivial every time Linux gets 
> > more general.
> 
> I don't disagree. But the point isn't how trivial or non-trivial the task
> of configuring the kernel is, the point is for a lot of people it is the
> ONLY task that they will use python for.  And everyone who builds a kernel
> will have gcc, so thats the 'ideal' dependency.  Second and third most
> likely, a C++ compiler or perl (depending on what you figure the
> installbase of each one is).  Forth, some form of java runtime.  And after
> that is python.  (I'm not advocating using any of the above for kernel
> configuration. But they are more likely to already be installed than
> python is.)
> 
> What this says is that either linux sources are going to grow (and the
> build process get more complex) by whatever the size of the python
> interpreter is, OR some method will be used that doesn't require a
> separate interpreter.
> 
> This is also in agreement with his statement about reducing the dependence
> on external tools, whereas requiring everyone to install python does not.  
> It could either be read as using straight gcc C -or- as including all the
> external tools in buildable form.  I'm betting on the former.

Look, either you implement CML2 in C (it can be done; but I'd wager it
isn't easy), or you pay someone else to do it, _or_ you stop complaining.
Simple as that. If you really can't stand having Python on your machine
(I'll bet it's a perl vs python religious thing... I have both installed),
there's always $EDITOR + .config for you to use. I promise that you won't
have to install any extra libraries/compilers/whatever to use that one.

Read the archives damn it, it's not the first time this kind of
arguing takes place here.

I'll give you another option:

make do with the current set of tools (with all of its errors and
short-comings, which are _numerous_) and maintain a forward-compatible
version. 


/David
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: Will 2.6 require Python for any configuration ? (CML2)

[Alan Cox]

> Look, either you implement CML2 in C (it can be done; but I'd wager it
> isn't easy), or you pay someone else to do it, _or_ you stop complaining.

It probably isnt very hard. Its not hard for example to knock up the needed
C code to do proper rule validation from CML1 in 2.4

Alan

Re: Will 2.6 require Python for any configuration ? (CML2)

[Roland Bauerschmidt]

Disconnect wrote:
> Forth, some form of java runtime.  And after that is python.

I disagree that a java runtime environment is more likely to be
installed than python. I'm not much into Java, but from what I know
there isn't even a really good java virtual machine for linux that is
free (kaffe is lacking quite a few features and stuff?).

Roland

-- 
Roland Bauerschmidt

Re: Will 2.6 require Python for any configuration ? (CML2)

[Rik van Riel]

On Thu, 23 Aug 2001, Disconnect wrote:

> ONLY task that they will use python for.  And everyone who builds a kernel
> will have gcc, so thats the 'ideal' dependency.  Second and third most
> likely, a C++ compiler or perl (depending on what you figure the
> installbase of each one is).  Forth, some form of java runtime.  And after
> that is python.

Sounds like you'd just might be fanatical enough to implement
CML2 in C or Perl, then ;)

Personally, I'd welcome such a thing...

cheers,

Rik
--
IA64: a worthy successor to the i860.

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: Will 2.6 require Python for any configuration ? (CML2)

[Disconnect]

On Thu, 23 Aug 2001, Rik van Riel did have cause to say:

> On Thu, 23 Aug 2001, Disconnect wrote:
> 
> > ONLY task that they will use python for.  And everyone who builds a kernel
> > will have gcc, so thats the 'ideal' dependency.  Second and third most
> > likely, a C++ compiler or perl (depending on what you figure the
> > installbase of each one is).  Forth, some form of java runtime.  And after
> > that is python.
> 
> Sounds like you'd just might be fanatical enough to implement
> CML2 in C or Perl, then ;)
> 
> Personally, I'd welcome such a thing...

You are mistaking my position I think.  Personally, I like python quite a
bit ;) 

But my point isn't that its good/bad for CML2.  My point is that I would
be very surprised if you had to install python in order to configure and
build a kernel under CML2, once CML2 is the official configuration
platform.  (Right now it is necessary to have python to use cml2.  But
CML2 is not yet in the stock kernel sources.)

But until ESR either chimes in or releases the final CML2, this is a moot
discussion.

(As far as someone else's point about a JRE not being installed on most
systems, those were guesstimates rather than statistics.  And even if
-every- distribution included eg kaffe by default, there would still be
people yelling if the kernel had a new dependency on it. ;) ..)

---
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C++++$ ULBS*++++$ P- L+++>+++++ 
E--- W+++ N+@ o+>$ K? w--->+++++ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b++++>$ DI++++ D++(+++) G++ e* h(-)* r++ y++
------END GEEK CODE BLOCK------

Re: Will 2.6 require Python for any configuration ? (CML2)

[John Alvord]

On Thu, 23 Aug 2001 15:31:26 -0400, Disconnect <lkml@sigkill.net>
wrote:

>On Thu, 23 Aug 2001, Rik van Riel did have cause to say:
>
>> On Thu, 23 Aug 2001, Disconnect wrote:
>> 
>> > ONLY task that they will use python for.  And everyone who builds a kernel
>> > will have gcc, so thats the 'ideal' dependency.  Second and third most
>> > likely, a C++ compiler or perl (depending on what you figure the
>> > installbase of each one is).  Forth, some form of java runtime.  And after
>> > that is python.
>> 
>> Sounds like you'd just might be fanatical enough to implement
>> CML2 in C or Perl, then ;)
>> 
>> Personally, I'd welcome such a thing...
>
>You are mistaking my position I think.  Personally, I like python quite a
>bit ;) 
>
>But my point isn't that its good/bad for CML2.  My point is that I would
>be very surprised if you had to install python in order to configure and
>build a kernel under CML2, once CML2 is the official configuration
>platform.  (Right now it is necessary to have python to use cml2.  But
>CML2 is not yet in the stock kernel sources.)
>
>But until ESR either chimes in or releases the final CML2, this is a moot
>discussion.

ESR is awaiting the 2.5 branch and the makefile rewrite.

My impression is that CML2 is "less bad" than CML in terms of weird
languages and buggy interpreters.

john

Re: Will 2.6 require Python for any configuration ? (CML2)

[Keith Owens]

On Thu, 23 Aug 2001 22:52:35 GMT, 
jalvo@mbay.net (John Alvord) wrote:
>ESR is awaiting the 2.5 branch and the makefile rewrite.

Wrong.  CML2 is working fine now.  CML2 runs on kernel 2.4, with or
without kbuild 2.5.  kbuild 2.5 supports CML1 and CML2 and runs on
kernel 2.4.  There are no timeline dependencies between kbuild 2.5 and
CML2, they are independent features.

As the kbuild maintainer, I have no opinion about CML2, Python etc.  I
do require several things from CML:

* Generate an accurate .config.  CML1 can and does generate
  inconsistent .config files, because the language assumes top down
  processing.  Menus break that assumption, CML2 fixes the problem,
  Alan Cox's changes to CML1 may also do so.

* Use a single parser.  CML1 uses three different parsers for
  oldconfig, menuconfig and xconfig, each parser has special cases
  which do not work on the other parsers.  CML2 uses a single parser.

* Easy to maintain and verify.  Everybody involved with CML1, including
  the current maintainer, agrees that CML1 has reached end of life.  It
  is too difficult to maintain and to verify that the rule sets give
  the desired results.  CML2's constraint handler fixes this, AC's CML1
  might, I have not looked at it.

* Easier to configure for beginners and to autoconfigure.  The list of
  configure options has grown to the point where it discourages people
  from configuring their own kernel.  WIth CML1 it is well nigh
  impossible to autoconfigure a kernel by looking at the hardware and
  deducing the config settings required.

As long as those requirements are met I do not care how .config is
created nor which language is used to build .config, display menus etc.
So far CML2 is the only code that meets the requirements.  That does
not mean that CML2 is the only possibility, nor that Python 2.0 is an
absolute requirement.  There is (or was) a work in progress to do CML2
in C instead of Python.  If somebody else comes up with CML3, the
kbuild group would look at it.

Saying that Python is a problem is just guessing at this stage.  CML2
will only be getting widespread usage in kernel 2.5, developers can
cope with installing the latest Python.  By the time 2.6 is released,
Python 2.0 will be widespread.

Until somebody actually codes a better CML, we are going with CML2.  If
you don't like CML2 or Python, do a better version instead of
complaining.  Put up or shut up.

Re: Will 2.6 require Python for any configuration ? (CML2)

[Joshua Schmidlkofer]

> Maybe it's just me, but adding a dependency solely for the sake of
> building the kernel doesn't strike me as very clean or elegant.
>

IMHO that is a highly suspect view.  Kernel building is already a hideously 
complicated problem [At least it seems so to me].   I am certainly in favor 
using a more intelligent and capable scripting lang to add capability and 
reduce some of the dependancy & symbol issues. If all we are doing is adding 
a different front end, it's not of much point, but some genuises here have 
streched make + shell to about as far as one can.  So if that can be done 
with make, someone surley can replace all that with Python.  [However, maybe 
I have missed the scope of the inclusion of python]
  Also, I would like to point out that while Python does have a 'flavor of 
the month' look for some people, it is a useable stable solution.  Who 
knows what my supercede it tomorrow, but as a whole it's maturing, and I 
personally use it a TON.   Plus it has a powerful library.  

Side note:
    It took about 10 days for the last kernel compile I did on my 386sx 16 
[whopping 32 megs of ram thought =] [that was a while ago]..   I suspect that 
with python it wouldn't actually take much longer.   Besides, I compile 
kernels for it on something else.

Re: Will 2.6 require Python for any configuration ? (CML2)

[Tom Rini]

On Thu, Aug 23, 2001 at 10:36:20AM -0500, Bob Glamm wrote:
 
> The same argument applies now that applies when this argument first
> started when ESR announced CML to the list: my '386 with 8MB of
> RAM and it's 20MB of disk doesn't have the room (or speed, for
> that matter) to install the fad interpreted language of today.
> Besides, it'll take me 45 minutes to download the latest version
> of Python over my 28.8k modem.  And yes, I download the kernel patch
> by patch to minimize the download pain ;)

And the same set of replies.
Doing it in !python would be much harder than it sounds.  But people have
stepped up and said they'd do it in C.  So python is only needed for
xconfig.  And that's just trading tcl for python.  The other thing is,
the python cml2 tools are supposed to eliminate a bunch of other tools and
remove some of the dependancies.

> Why isn't ncurses a pain?  For the same reason ncurses wasn't a
> pain when 'make menuconfig' (lxdialog) was introduced (yes, I did many a 
> 'make config'):  curses/ncurses was already on just about every
> system running Linux - it was built into the text editor.

And many a new system has python.

> Believe it or not, there are people like me that take a distribution,
> do a minimal install just to get a machine up and running, then remove
> most of the package management software from the installation once
> networking has been configured, then continually update software
> from source as new fixes are released.  I managed to update an
> early version of Slackware from the earliest libc4 releases through
> libc6 without ever touching a distribution disk - all updated through
> source.
> 
> But I would expect that I'm in the minority in this regard. ;)

Probably.  And you can compile python too I bet :)

> It does surprise me that Linus would actually allow this to happen.
> It's been my impression that he favors a clean, elegant solution.
> Maybe it's just me, but adding a dependency solely for the sake of
> building the kernel doesn't strike me as very clean or elegant.

Because the python solution happened to fix all of the problems.

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

Re: Will 2.6 require Python for any configuration ? (CML2)

[Jes Sorensen]

>>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:

Tom> On Thu, Aug 23, 2001 at 10:36:20AM -0500, Bob Glamm wrote:
Tom> And the same set of replies.  Doing it in !python would be much
Tom> harder than it sounds.  But people have stepped up and said
Tom> they'd do it in C.  So python is only needed for xconfig.  And
Tom> that's just trading tcl for python.  The other thing is, the
Tom> python cml2 tools are supposed to eliminate a bunch of other
Tom> tools and remove some of the dependancies.

Most of these tools were written in bash or C ... going the python way
is a major loss.

>> Why isn't ncurses a pain?  For the same reason ncurses wasn't a
>> pain when 'make menuconfig' (lxdialog) was introduced (yes, I did
>> many a 'make config'): curses/ncurses was already on just about
>> every system running Linux - it was built into the text editor.

Tom> And many a new system has python.

It still doesn't solve the situation of people building embedded
systems who do only have a bare minimum on their systems. Or people
who are bringing up systems who do not have network/floppy available
and do not want to move their disks between systems constantly in
order to configure their kernels. I have brought this point up
several times to the CML2 developer and every time I received the
utterly useless answer saying I should move my source to another box,
configure it there and move it back to the devel box.

>> It does surprise me that Linus would actually allow this to happen.
>> It's been my impression that he favors a clean, elegant solution.
>> Maybe it's just me, but adding a dependency solely for the sake of
>> building the kernel doesn't strike me as very clean or elegant.

Tom> Because the python solution happened to fix all of the problems.

And introduces new problems that so far haven't been addressed.

The solution seems to be that someone implements CML2 in C, once that
happens we are talking something completely different.

Jes

Re: Will 2.6 require Python for any configuration ? (CML2)

[David Weinehall]

On Thu, Aug 23, 2001 at 09:26:33PM +0200, Jes Sorensen wrote:
> >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
> 
> Tom> On Thu, Aug 23, 2001 at 10:36:20AM -0500, Bob Glamm wrote:
> Tom> And the same set of replies.  Doing it in !python would be much
> Tom> harder than it sounds.  But people have stepped up and said
> Tom> they'd do it in C.  So python is only needed for xconfig.  And
> Tom> that's just trading tcl for python.  The other thing is, the
> Tom> python cml2 tools are supposed to eliminate a bunch of other
> Tom> tools and remove some of the dependancies.
> 
> Most of these tools were written in bash or C ... going the python way
> is a major loss.
> 
> >> Why isn't ncurses a pain?  For the same reason ncurses wasn't a
> >> pain when 'make menuconfig' (lxdialog) was introduced (yes, I did
> >> many a 'make config'): curses/ncurses was already on just about
> >> every system running Linux - it was built into the text editor.
> 
> Tom> And many a new system has python.
> 
> It still doesn't solve the situation of people building embedded
> systems who do only have a bare minimum on their systems. Or people
> who are bringing up systems who do not have network/floppy available
> and do not want to move their disks between systems constantly in
> order to configure their kernels. I have brought this point up
> several times to the CML2 developer and every time I received the
> utterly useless answer saying I should move my source to another box,
> configure it there and move it back to the devel box.
> 
> >> It does surprise me that Linus would actually allow this to happen.
> >> It's been my impression that he favors a clean, elegant solution.
> >> Maybe it's just me, but adding a dependency solely for the sake of
> >> building the kernel doesn't strike me as very clean or elegant.
> 
> Tom> Because the python solution happened to fix all of the problems.
> 
> And introduces new problems that so far haven't been addressed.
> 
> The solution seems to be that someone implements CML2 in C, once that
> happens we are talking something completely different.

Sounds like we have another volunteer here?!


/David
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: Will 2.6 require Python for any configuration ? (CML2)

[Tom Rini]

On Thu, Aug 23, 2001 at 09:26:33PM +0200, Jes Sorensen wrote:

> >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
> 
> Tom> On Thu, Aug 23, 2001 at 10:36:20AM -0500, Bob Glamm wrote:
> Tom> And the same set of replies.  Doing it in !python would be much
> Tom> harder than it sounds.  But people have stepped up and said
> Tom> they'd do it in C.  So python is only needed for xconfig.  And
> Tom> that's just trading tcl for python.  The other thing is, the
> Tom> python cml2 tools are supposed to eliminate a bunch of other
> Tom> tools and remove some of the dependancies.
> 
> Most of these tools were written in bash or C ... going the python way
> is a major loss.

Or perl.

> >> Why isn't ncurses a pain?  For the same reason ncurses wasn't a
> >> pain when 'make menuconfig' (lxdialog) was introduced (yes, I did
> >> many a 'make config'): curses/ncurses was already on just about
> >> every system running Linux - it was built into the text editor.
> 
> Tom> And many a new system has python.
> 
> It still doesn't solve the situation of people building embedded
> systems who do only have a bare minimum on their systems. Or people
> who are bringing up systems who do not have network/floppy available
> and do not want to move their disks between systems constantly in
> order to configure their kernels. I have brought this point up
> several times to the CML2 developer and every time I received the
> utterly useless answer saying I should move my source to another box,
> configure it there and move it back to the devel box.

You've said this before. :)  Just how small of an 'embedded' system are
you talking about?  I know of people who do compile a kernel now and
again on a 'small' system, for fun.  On a larger (cPCI) system, I
don't see your point.  If you can somehow transport the 21mb[1] bzip2
kernel source to your system, you can transport python.  If you're
porting to a brand new arch, there's still good tests before you
have shlib support (You've mentioned that before too I think).

> >> It does surprise me that Linus would actually allow this to happen.
> >> It's been my impression that he favors a clean, elegant solution.
> >> Maybe it's just me, but adding a dependency solely for the sake of
> >> building the kernel doesn't strike me as very clean or elegant.
> 
> Tom> Because the python solution happened to fix all of the problems.
> 
> And introduces new problems that so far haven't been addressed.

Which is what?  The dependancy on python2?

> The solution seems to be that someone implements CML2 in C, once that
> happens we are talking something completely different.

As long as it does everything the current version does and is just as
fast I don't think there'll be much of an argument for either.  Hell,
probably both for a while...

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

Re: Will 2.6 require Python for any configuration ? (CML2)

[Tom Rini]

On Thu, Aug 23, 2001 at 12:41:09PM -0700, Tom Rini wrote:

[snip]
> don't see your point.  If you can somehow transport the 21mb[1] bzip2
[snip]

1:
$ ls -lh linux-2.4.6.tar.bz2 
-rw-r--r--    1 trini    trini         21M Jul  3 17:07 linux-2.4.6.tar.bz2

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

Re: Will 2.6 require Python for any configuration ? (CML2)

[Jes Sorensen]

>>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:

Tom> You've said this before. :) Just how small of an 'embedded'
Tom> system are you talking about?  I know of people who do compile a
Tom> kernel now and again on a 'small' system, for fun.  On a larger
Tom> (cPCI) system, I don't see your point.  If you can somehow
Tom> transport the 21mb[1] bzip2 kernel source to your system, you can
Tom> transport python.  If you're porting to a brand new arch, there's
Tom> still good tests before you have shlib support (You've mentioned
Tom> that before too I think).

I am actually much more concerned about bringing up new systems than
embedded however it is not uncommon to have very limited space to work
in (like 64MB). My point is that the transport process of the kernel
image is painful. Some of the embedded devices or new systems being
brought up may only have serial some do not have network or
floppy. This makes it *very* painful to move things around because you
have to physically move your disk or similar. In particular when
bringing up a system you tend to disable large parts of the kernel in
order to make the thing compile and you don't want to have to copy
things back and forth constantly because you found that serial no
longer compiles and you don't want to fight that while you are trying
to fix a bug in your video driver. Hence you just disable serial and
recompile - with the new system this has suddenly become extremely
painful.

>>  And introduces new problems that so far haven't been addressed.

Tom> Which is what?  The dependancy on python2?

Yes

>> The solution seems to be that someone implements CML2 in C, once
>> that happens we are talking something completely different.

Tom> As long as it does everything the current version does and is
Tom> just as fast I don't think there'll be much of an argument for
Tom> either.  Hell, probably both for a while...

Well getting a C versions means we can get rid of the Python hell, it
would be a major win.

Jes

Re: Will 2.6 require Python for any configuration ? (CML2)

[Tom Rini]

On Thu, Aug 23, 2001 at 10:02:07PM +0200, Jes Sorensen wrote:
> >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
> 
> Tom> You've said this before. :) Just how small of an 'embedded'
> Tom> system are you talking about?  I know of people who do compile a
> Tom> kernel now and again on a 'small' system, for fun.  On a larger
> Tom> (cPCI) system, I don't see your point.  If you can somehow
> Tom> transport the 21mb[1] bzip2 kernel source to your system, you can
> Tom> transport python.  If you're porting to a brand new arch, there's
> Tom> still good tests before you have shlib support (You've mentioned
> Tom> that before too I think).
> 
> I am actually much more concerned about bringing up new systems than
> embedded however it is not uncommon to have very limited space to work
> in (like 64MB).

64mb of space for 'disk' ?  You aren't compiling the kernel anyhow without
some serious mucking around.

> My point is that the transport process of the kernel
> image is painful. Some of the embedded devices or new systems being
> brought up may only have serial some do not have network or
> floppy. This makes it *very* painful to move things around because you
> have to physically move your disk or similar.

And you think that trying to transport the kernel srcs + userland
will save you time in the long run?  If you have to physically move
your disk to initially put userland on, you can put on python too.  Or
go and run the 'freeze' schitt on it and have the C version.  What kind
of 'new' systems are you talking about?  I'm biased I guess since I'm
used to working on documented hardware.  So documents + time + good hw
debugger tend to help things along.

> >>  And introduces new problems that so far haven't been addressed.
> 
> Tom> Which is what?  The dependancy on python2?
> 
> Yes

Because with the exception of your unique situation in which you have
a machine which is stable enough to compile a kernel on and develop
but can't run python, it's not a problem.

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

Re: Will 2.6 require Python for any configuration ? (CML2)

[Jes Sorensen]

>>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:

Tom> On Thu, Aug 23, 2001 at 10:02:07PM +0200, Jes Sorensen wrote:
>>  I am actually much more concerned about bringing up new systems
>> than embedded however it is not uncommon to have very limited space
>> to work in (like 64MB).

Tom> 64mb of space for 'disk' ?  You aren't compiling the kernel
Tom> anyhow without some serious mucking around.

You may keep your binaries in flash on system like that.

>> My point is that the transport process of the kernel image is
>> painful. Some of the embedded devices or new systems being brought
>> up may only have serial some do not have network or floppy. This
>> makes it *very* painful to move things around because you have to
>> physically move your disk or similar.

Tom> And you think that trying to transport the kernel srcs + userland
Tom> will save you time in the long run?  If you have to physically
Tom> move your disk to initially put userland on, you can put on
Tom> python too.  Or go and run the 'freeze' schitt on it and have the
Tom> C version.  What kind of 'new' systems are you talking about?
Tom> I'm biased I guess since I'm used to working on documented
Tom> hardware.  So documents + time + good hw debugger tend to help
Tom> things along.

What I am saying is that I do *not* want to transport source
etc. every time I want to make a kernel change. And no I *cannot* just
put Python on it if I a) don't have the space or b) haven't brought up
Python on the system yet.

I am not speaking of any new systems I am working on right now, I am
speaking from my experience bringing up systems such as the m68k and
ia64.

Tom> Because with the exception of your unique situation in which you
Tom> have a machine which is stable enough to compile a kernel on and
Tom> develop but can't run python, it's not a problem.

As I have pointed out, it *is* indeed a problem to kernel developers
who are actually working on bringing up systems. Most of the people
who argue in favor of the Python dependency have never tried bringing
up a system.

Jes

Re: Will 2.6 require Python for any configuration ? (CML2)

[Tom Rini]

On Thu, Aug 23, 2001 at 10:43:46PM +0200, Jes Sorensen wrote:
> >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
> 
> Tom> On Thu, Aug 23, 2001 at 10:02:07PM +0200, Jes Sorensen wrote:
> >>  I am actually much more concerned about bringing up new systems
> >> than embedded however it is not uncommon to have very limited space
> >> to work in (like 64MB).
> 
> Tom> 64mb of space for 'disk' ?  You aren't compiling the kernel
> Tom> anyhow without some serious mucking around.
> 
> You may keep your binaries in flash on system like that.

Yes.  But you need some sort of 'disk' >128MB to extract the kernel
sources to.

> >> My point is that the transport process of the kernel image is
> >> painful. Some of the embedded devices or new systems being brought
> >> up may only have serial some do not have network or floppy. This
> >> makes it *very* painful to move things around because you have to
> >> physically move your disk or similar.
> 
> Tom> And you think that trying to transport the kernel srcs + userland
> Tom> will save you time in the long run?  If you have to physically
> Tom> move your disk to initially put userland on, you can put on
> Tom> python too.  Or go and run the 'freeze' schitt on it and have the
> Tom> C version.  What kind of 'new' systems are you talking about?
> Tom> I'm biased I guess since I'm used to working on documented
> Tom> hardware.  So documents + time + good hw debugger tend to help
> Tom> things along.
> 
> What I am saying is that I do *not* want to transport source
> etc. every time I want to make a kernel change. And no I *cannot* just
> put Python on it if I a) don't have the space or b) haven't brought up
> Python on the system yet.

If you don't have the room to put Python on the box you probably don't have
the room to put the kernel source on the box and compile either.  I've seen
lots of stuff shoved onto a very small ammount of flash (The bloody Agentas 
(sp?) have X on what, 32 megs?)

> I am not speaking of any new systems I am working on right now, I am
> speaking from my experience bringing up systems such as the m68k and
> ia64.

m68k I could understand maybe not having ethernet and small disks.  But
not ia64.  Coming from a PPC background, things tend to have ethernet.  You
tend to want ethernet to be working (basic board bring up, serial, ethernet)
so you can have an NFS root and start playing with the system.

> Tom> Because with the exception of your unique situation in which you
> Tom> have a machine which is stable enough to compile a kernel on and
> Tom> develop but can't run python, it's not a problem.
> 
> As I have pointed out, it *is* indeed a problem to kernel developers
> who are actually working on bringing up systems. Most of the people
> who argue in favor of the Python dependency have never tried bringing
> up a system.

The _only_ problem you've pointed out which seems to be really valid is that
python2 will mean you do need shared library support.  Having worked with
and talked to numerous people in the process of bringing up a new board
(I don't have the time right now to try my hand at it just yet) this
wouldn't be a problem for them.  Initial bring up is usually done from
what I've gathered, by people with a cross-compiler (or another system on
the platform that's known to work) and then feeding the device a kernel.
If you're developing on the machine you're attempting to bring up, you're
always going to be having lots of fun.

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

Re: Will 2.6 require Python for any configuration ? (CML2)

[Denis Perchine]

On Friday 24 August 2001 02:41, Tom Rini wrote:
> On Thu, Aug 23, 2001 at 09:26:33PM +0200, Jes Sorensen wrote:
> > >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
> You've said this before. :)  Just how small of an 'embedded' system are
> you talking about?  I know of people who do compile a kernel now and
> again on a 'small' system, for fun.  On a larger (cPCI) system, I
> don't see your point.  If you can somehow transport the 21mb[1] bzip2
> kernel source to your system, you can transport python.  If you're
> porting to a brand new arch, there's still good tests before you
> have shlib support (You've mentioned that before too I think).

There is another point why having Python installed is a problem. Usually when 
you install a server you remove everything from it because of space, and 
security reasons. The main security concern is the less is installed the 
better security is. I always remove python from any servers I have. As I 
remove guile, forth, and other useless (in terms of server) languages. Now 
you tell me that I should have this bloat installed just to configure my 
kernel. Do not you think that it is too much? Current kernel does not require 
anything like this.

-- 
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

Re: Will 2.6 require Python for any configuration ? (CML2)

[Leonid Mamtchenkov]

Hello Denis Perchine,

Once you wrote about "Re: Will 2.6 require Python for any configuration ? (CML2)":
DP> On Friday 24 August 2001 02:41, Tom Rini wrote:
DP> > On Thu, Aug 23, 2001 at 09:26:33PM +0200, Jes Sorensen wrote:
DP> > > >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
DP> > You've said this before. :)  Just how small of an 'embedded' system are
DP> > you talking about?  I know of people who do compile a kernel now and
DP> > again on a 'small' system, for fun.  On a larger (cPCI) system, I
DP> > don't see your point.  If you can somehow transport the 21mb[1] bzip2
DP> > kernel source to your system, you can transport python.  If you're
DP> > porting to a brand new arch, there's still good tests before you
DP> > have shlib support (You've mentioned that before too I think).
DP> 
DP> There is another point why having Python installed is a problem. Usually when 
DP> you install a server you remove everything from it because of space, and 
DP> security reasons. The main security concern is the less is installed the 
DP> better security is. I always remove python from any servers I have. As I 
DP> remove guile, forth, and other useless (in terms of server) languages. Now 
DP> you tell me that I should have this bloat installed just to configure my 
DP> kernel. Do not you think that it is too much? Current kernel does not require 
DP> anything like this.

Why should you have gcc and make on the server then?  Compile you kernel
on another machine and then just install it on your servers.  This way
you will not only save space and improve security, but also gain some
time, which is always good.

-- 
 Best regards,
 Leonid Mamtchenkov
 Red Hat Certified Linux Engineer (RHCE)
 System Administrator
 Francoudi & Stephanou Ltd

Re: Will 2.6 require Python for any configuration ? (CML2)

[Denis Perchine]

On Friday 24 August 2001 13:35, Leonid Mamtchenkov wrote:
> Once you wrote about "Re: Will 2.6 require Python for any configuration ?
> (CML2)": DP> On Friday 24 August 2001 02:41, Tom Rini wrote:
> DP> > On Thu, Aug 23, 2001 at 09:26:33PM +0200, Jes Sorensen wrote:
> DP> > > >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
> DP> > You've said this before. :)  Just how small of an 'embedded' system are
> DP> > you talking about?  I know of people who do compile a kernel now and
> DP> > again on a 'small' system, for fun.  On a larger (cPCI) system, I
> DP> > don't see your point.  If you can somehow transport the 21mb[1] bzip2
> DP> > kernel source to your system, you can transport python.  If you're
> DP> > porting to a brand new arch, there's still good tests before you
> DP> > have shlib support (You've mentioned that before too I think).
> DP> There is another point why having Python installed is a problem. Usually when
> DP> you install a server you remove everything from it because of space, and
> DP> security reasons. The main security concern is the less is installed the
> DP> better security is. I always remove python from any servers I have. As I
> DP> remove guile, forth, and other useless (in terms of server) languages. Now
> DP> you tell me that I should have this bloat installed just to configure my
> DP> kernel. Do not you think that it is too much? Current kernel does not require
> DP> anything like this.

> Why should you have gcc and make on the server then?  Compile you kernel
> on another machine and then just install it on your servers.  This way
> you will not only save space and improve security, but also gain some
> time, which is always good.

That's nice idea, but it does not have any connection to subj.
I prefer to do things the way I do them now. Anyway I need compiler for other things.
I have lot of C/C++ daemons running, and want to fix problems right there.
But having Python just to configure a kernel is an overkill. Why not Sather, or other rarely used language.
Oberon-2 would be also nice.

This is just a laziness of people who do not want to make things right. Actually interesting question
is what Linus think of all this crap?

-- 
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

Re: Will 2.6 require Python for any configuration ? (CML2)

[Mark Hahn]

> But having Python just to configure a kernel is an overkill. Why not Sather, or other rarely used language.
> Oberon-2 would be also nice.

obviously, Prolog would be The Right Thing for doing kernel dependencies.

Re: Will 2.6 require Python for any configuration ? (CML2)

[Ryan W. Maple]

On Fri, 24 Aug 2001, Denis Perchine wrote:

> On Friday 24 August 2001 02:41, Tom Rini wrote:
> > On Thu, Aug 23, 2001 at 09:26:33PM +0200, Jes Sorensen wrote:
> > > >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
> > You've said this before. :)  Just how small of an 'embedded' system are
> > you talking about?  I know of people who do compile a kernel now and
> > again on a 'small' system, for fun.  On a larger (cPCI) system, I
> > don't see your point.  If you can somehow transport the 21mb[1] bzip2
> > kernel source to your system, you can transport python.  If you're
> > porting to a brand new arch, there's still good tests before you
> > have shlib support (You've mentioned that before too I think).
> 
> There is another point why having Python installed is a problem. Usually when 
> you install a server you remove everything from it because of space, and 
> security reasons. The main security concern is the less is installed the 
> better security is. I always remove python from any servers I have. As I 
> remove guile, forth, and other useless (in terms of server) languages. Now 
> you tell me that I should have this bloat installed just to configure my 
> kernel. Do not you think that it is too much? Current kernel does not require 
> anything like this.

Personally, I'm on the "against Python" side of the argument, but I don't
think that this argument will hold up for very long.  I also remove just
about everything from a newly installed system _including_ compilers and
all devel tools.  Thus, I can't even compile a kernel on a "production"
box let alone configure it.

I build it on another box and either a) package it or b) tar it up for
"installation" on the target machine.

So this argument will not hold up very long, and I fear the Python
dependancy will be here to stay.  I'm just about over it. :)

Cheers,
Ryan

Re: Will 2.6 require Python for any configuration ? (CML2)

[Michael Peddemors]

My 2 bits? I have been running Linux for a long long time now...  worked
on hundreds (more likely thousands) of Linux Systems.. (Wish I would
have catalogued the number) and I have never installed Python yet on a
single system...  

Seems like bloat to me to install a whole language to keep afront in
Linux developments..


On 24 Aug 2001 09:35:04 -0400, Ryan W. Maple wrote:
> 
> On Fri, 24 Aug 2001, Denis Perchine wrote:
> 

-- 
"Catch the Magic of Linux..."
--------------------------------------------------------
Michael Peddemors - Senior Consultant
LinuxAdministration - Internet Services
NetworkServices - Programming - Security
Wizard IT Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604)589-0037 Beautiful British Columbia, Canada

Re: Will 2.6 require Python for any configuration ? (CML2)

[David Lang]

let's see you remove perl, python, etc but are going to leave gcc on there
so you can compile kernels there????

if you are really locking a box down like that you will compile the kernel
on another machine and so will not need gcc or python on the box.

David Lang

On Fri, 24 Aug 2001, Denis Perchine wrote:

> Date: Fri, 24 Aug 2001 11:59:41 +0700
> From: Denis Perchine <dyp@perchine.com>
> To: linux-kernel@vger.kernel.org
> Subject: Re: Will 2.6 require Python for any configuration ? (CML2)
>
> On Friday 24 August 2001 02:41, Tom Rini wrote:
> > On Thu, Aug 23, 2001 at 09:26:33PM +0200, Jes Sorensen wrote:
> > > >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
> > You've said this before. :)  Just how small of an 'embedded' system are
> > you talking about?  I know of people who do compile a kernel now and
> > again on a 'small' system, for fun.  On a larger (cPCI) system, I
> > don't see your point.  If you can somehow transport the 21mb[1] bzip2
> > kernel source to your system, you can transport python.  If you're
> > porting to a brand new arch, there's still good tests before you
> > have shlib support (You've mentioned that before too I think).
>
> There is another point why having Python installed is a problem. Usually when
> you install a server you remove everything from it because of space, and
> security reasons. The main security concern is the less is installed the
> better security is. I always remove python from any servers I have. As I
> remove guile, forth, and other useless (in terms of server) languages. Now
> you tell me that I should have this bloat installed just to configure my
> kernel. Do not you think that it is too much? Current kernel does not require
> anything like this.
>
> --
> Sincerely Yours,
> Denis Perchine
>
> ----------------------------------
> E-Mail: dyp@perchine.com
> HomePage: http://www.perchine.com/dyp/
> FidoNet: 2:5000/120.5
> ----------------------------------
> -
> 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: Will 2.6 require Python for any configuration ? (CML2)

[Roland Bauerschmidt]

Bob Glamm wrote:
> I bet the same number of people still compile their own kernels.
> However, the *percentage* of people that still compile their own
> kernels probably keeps shrinking as the number of people using
> Linux increases.

Of course, this is what I meant.

> Why isn't ncurses a pain?  For the same reason ncurses wasn't a
> pain when 'make menuconfig' (lxdialog) was introduced (yes, I did many a 
> 'make config'):  curses/ncurses was already on just about every
> system running Linux - it was built into the text editor.

It probably still is, but not every *user* that might want to compile a
kernel himself has the ncurses development files installed. Instead of
installing those he might as well install python (which most normal
users can use probably a lot better since the kernel wouldn't be the
only thing depending on it)...

> It does surprise me that Linus would actually allow this to happen.
> It's been my impression that he favors a clean, elegant solution.
> Maybe it's just me, but adding a dependency solely for the sake of
> building the kernel doesn't strike me as very clean or elegant.

I have to admit that I don't really know anything about CML at all (so
my points might be wrong), but I personally would favour a nice
replacement of 'make menuconfig' written in python.

Roland

-- 
Roland Bauerschmidt

Re: Will 2.6 require Python for any configuration ? (CML2)

[Kurt Roeckx]

On Thu, Aug 23, 2001 at 10:36:20AM -0500, Bob Glamm wrote:
> 
> Believe it or not, there are people like me that take a distribution,
> do a minimal install just to get a machine up and running, then remove
> most of the package management software from the installation once
> networking has been configured, then continually update software
> from source as new fixes are released.  I managed to update an
> early version of Slackware from the earliest libc4 releases through
> libc6 without ever touching a distribution disk - all updated through
> source.
> 
> But I would expect that I'm in the minority in this regard. ;)

I only started with slackware 3.0, which already had libc 5.0.9.


Kurt

Re: Will 2.6 require Python for any configuration ? (CML2)

[Matthias Andree]

On Wed, 22 Aug 2001, Frédéric L. W. Meunier wrote:

> Am I the only one afraid that the Python requirement can turn
> into a problem ? You can develop anything on Linux without
> Python. I'd compare Python to Tcl - you only install it to
> waste space, develop, or run applications that use it. Perl
> is very different. It's required by GNU Automake and more.

But you only install it to waste space, develop, or run applications
that use it. What's the difference?

> I'm really surprised by the fact that nobody noticed what a
> nightmare 2.6 will be with such a requirement. You can't
> expect everybody to install something that's of no use for
> most.

You'd expect distributors to ship a Python version that's suited for
Kernel configuration by then. If they don't, well, get another
distribution.

> My intention isn't to diminish the importance of CML2 and the
> hard and volunteer work of Eric S. Raymond. I just can't
> consider Python a requirement to configure the build process
> of a Kernel.

Why not? You expect people to have a not-too recent GCC, GNU make and
other tools, so why not Python?

Of course, a standalone code that'd run out of C would be fine, but if
that comes with less maintainability or would be more difficult to
maintain, there's nothing to be gained.

Is there a py2c compiler? If so, it might be useful if kernel.org
carried a compiled version of CML2, if at all possible.

But I feel there's no need to whine about 2.6. Enough time for
distributors to ship their distributions with Python 2.x.1 and for
distributors or third parties to package Python2 for older distribution
releases.

The only valid point might be "embedded systems", but then again, you
should be able to cross compile the kernel for your embedded system for
fun and for speed.

Regards,
Matthias Andree

Re: Will 2.6 require Python for any configuration ? (CML2)

[Samium Gromoff]

      Hey guys, can`t resist more this thread... =)

   1. I heard a lot of arguments why _not_ to include
  python. Also alot of arguments why _ignore_ the arguments
  to _not_ include python.
    BUT! No arguments why to _include_ it...
  kinda disbalance as i see.

  2. Those who tells that playing with 21M large kernel
 isnt any better than playing with kernel PLUS 20M
 python are, politely saying, definitely not right.

  3. i ALREADY cannot tolerate how current config
 heartbrakingly slow crawls on my p166. No, do not ask
 me why is it so. just think: we have 3k strings, 3k
 deps, and asketic ncurses interface. So WHY is it so
 slow? And you think python-powered config engine 
 will be at least _approachingly_ tolerable on an
 386??? Nah. It wont.

 What we win in the true C way: 
      speed, size
 What we lose --------=-------:
      maintainability?????? (i`ll believe if esr
 will tell so...)

---


cheers,


   Samium Gromoff

Re: Will 2.6 require Python for any configuration ? (CML2)

[Tom Rini]

On Fri, Aug 24, 2001 at 12:41:39AM +0400, Samium Gromoff wrote:

>    1. I heard a lot of arguments why _not_ to include
>   python. Also alot of arguments why _ignore_ the arguments
>   to _not_ include python.
>     BUT! No arguments why to _include_ it...
>   kinda disbalance as i see.

The main reason to include it, is that that's what it was done in.
If you go back and read the archives, ESR goes over why all sorts of
other languages wouldn't work as easily.

>   2. Those who tells that playing with 21M large kernel
>  isnt any better than playing with kernel PLUS 20M
>  python are, politely saying, definitely not right.

That wasn't my point at all.  My point was that if you're somehow
transfering the 21mb source .tar.bz2'ed, you can also stand to transport
the 4mb of python 2.0.1 source, tar.gz'ed over as well.  In other words,
having to bring python over any of the methods that Jes mentioned isn't
any more painful than the kernel source.  It's roughly the size of a couple
of vmlinux'es.

>   3. i ALREADY cannot tolerate how current config
>  heartbrakingly slow crawls on my p166. No, do not ask
>  me why is it so. just think: we have 3k strings, 3k
>  deps, and asketic ncurses interface. So WHY is it so
>  slow? And you think python-powered config engine 
>  will be at least _approachingly_ tolerable on an
>  386??? Nah. It wont.

Have you tried cml2 on your p166?  ESR went and did much speed tweaking of
the code about 6 months ago it seems like and managed to please some of the
people using a low-end pentium.  Building a kernel on a 386 isn't approcaching
tolerable right now anyhow.  Someone pointed out today or yesterday it takes
~10 days.

>  What we win in the true C way: 
>       speed, size

Speed is arguable.  On my p2/333s I didn't notice much of a difference.
On a lower end, yes, you might notice a bit of a slowdown.  But I'm also
one of those people who doesn't plan on running 2.4 on my p100 laptop,
let alone 2.6.

>  What we lose --------=-------:
>       maintainability?????? (i`ll believe if esr will tell so...)

Python is no harder to maintain then C.

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

Re: Will 2.6 require Python for any configuration ? (CML2)

[Ben Ford]

Tom Rini wrote:

>On Fri, Aug 24, 2001 at 12:41:39AM +0400, Samium Gromoff wrote:
>
>>   1. I heard a lot of arguments why _not_ to include
>>  python. Also alot of arguments why _ignore_ the arguments
>>  to _not_ include python.
>>    BUT! No arguments why to _include_ it...
>>  kinda disbalance as i see.
>>
>
>The main reason to include it, is that that's what it was done in.
>


That is never an excuse.

Re: Will 2.6 require Python for any configuration ? (CML2)

[Tom Rini]

On Fri, Aug 24, 2001 at 09:11:24PM -0700, Ben Ford wrote:
> Tom Rini wrote:
> 
> >On Fri, Aug 24, 2001 at 12:41:39AM +0400, Samium Gromoff wrote:
> >
> >>  1. I heard a lot of arguments why _not_ to include
> >> python. Also alot of arguments why _ignore_ the arguments
> >> to _not_ include python.
> >>   BUT! No arguments why to _include_ it...
> >> kinda disbalance as i see.
> >
> >The main reason to include it, is that that's what it was done in.
> 
> That is never an excuse.

Then write it in something else.

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

Re: Will 2.6 require Python for any configuration ? (CML2)

[Samium Gromoff]

> Because with the exception of your unique situation in which you have
> a machine which is stable enough to compile a kernel on and develop
> but can't run python, it's not a problem.

   Tom, i think Jes wanted to tell that basically
 there _are_ the cases when python hurts, so
 losing the freedom not to install python is not
 good. 

   And you told him that his case is not looking good,
 so Jes miss the whole point. Bad logical chain.

---


cheers,


   Samium Gromoff

Re: Will 2.6 require Python for any configuration ? (CML2)

[Tom Rini]

On Fri, Aug 24, 2001 at 12:56:52AM +0400, Samium Gromoff wrote:
> > Because with the exception of your unique situation in which you have
> > a machine which is stable enough to compile a kernel on and develop
> > but can't run python, it's not a problem.
> 
>    Tom, i think Jes wanted to tell that basically
>  there _are_ the cases when python hurts, so
>  losing the freedom not to install python is not
>  good. 

What I'm saying is that the cases where you somehow don't have the room
to toss in a stripped down python, but do have room for gcc and the
kernel sources + compiling them are freakishly rare, if they do exist.

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

Re: Will 2.6 require Python for any configuration ? (CML2)

[Rick Hohensee]

Jes Sorensen
I am actually much more concerned about bringing up new systems than
embedded however it is not uncommon to have very limited space to work
in (like 64MB). My point is that the transport process of the kernel
image is painful. Some of the embedded devices or new systems being
brought up may only have serial some do not have network or
floppy. This makes it *very* painful to move things around because you
have to physically move your disk or similar. In particular when
bringing up a system you tend to disable large parts of the kernel in

moi
 In other words, a kernel build has a close correlation with actual system
bootstrap processes, where the niceties of the interpreter-du-jour are
irrelvant, as are the percentages or absolute numbers of people that don't
do hard bootstrapping of anything. This is the aspect of low-level code
that utilities used in a kernel build should adhere to, no gratuitous
dependancies. Linux is and always has been hard enough to bring up,
needing as it does a C compiler that needs a C compiler. Somehow the
cuteness of this class of recursion is lost on me. 

This is why I wrote and am extending an assembler in Bash. Two
dependancies; a recent unix shell, and an OS. The one-link toolchain.

Rick Hohensee
	

	www.clienux.com

Re: Will 2.6 require Python for any configuration ? (CML2)

[Tom Rini]

On Thu, Aug 23, 2001 at 05:08:14PM -0400, Rick Hohensee wrote:

>  In other words, a kernel build has a close correlation with actual system
> bootstrap processes, where the niceties of the interpreter-du-jour are
> irrelvant, as are the percentages or absolute numbers of people that don't
> do hard bootstrapping of anything. This is the aspect of low-level code
> that utilities used in a kernel build should adhere to, no gratuitous
> dependancies. Linux is and always has been hard enough to bring up,
> needing as it does a C compiler that needs a C compiler. Somehow the
> cuteness of this class of recursion is lost on me. 

Yes, Linux does have a nice chicken-and-egg process.  But unless you're
building a brand new arch, which means you have to fix glibc and gcc and
binutils to know about you, throwing in python isn't going to hurt you.
And if you're trying to do this on the machine you're trying to make
supported, you're going to have lots of fun.  In other words, I don't
see this as an issue.  If you're talking about bringing up a new board
for supported platform X, the only issue is getting Python2 onto the
system.  Which isn't nearly as painful as getting the kernel source, glibc
or gcc will be.  It'll only be maybe twice as painful as getting the bash
sources over (2.05) even. :)

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

Re: Will 2.6 require Python for any configuration ? (CML2)

[Samium Gromoff]

> The main reason to include it, is that that's what it was done in.
> If you go back and read the archives, ESR goes over why all sorts of
> other languages wouldn't work as easily.
in such cases the solution is to elaborate, and not to
leave things to decay.

> That wasn't my point at all.  My point was that if you're somehow
> transfering the 21mb source .tar.bz2'ed, you can also stand to transport
> the 4mb of python 2.0.1 source, tar.gz'ed over as well.  In other words,
> having to bring python over any of the methods that Jes mentioned isn't
> any more painful than the kernel source.  It's roughly the size of a couple
> of vmlinux'es.
  i was sarcastic here. actually the fact is that
  4MB of tarred sources is more than 10 .c files
  doing the same thing 1.5x times faster.

> Have you tried cml2 on your p166?  ESR went and did much speed tweaking of
> the code about 6 months ago it seems like and managed to please some of the
> people using a low-end pentium.  Building a kernel on a 386 isn't approcaching
> tolerable right now anyhow.  Someone pointed out today or yesterday it takes
> ~10 days.
  it is not an excuse to make things even worser.
 
> Python is no harder to maintain then C.
  actually i meant that "i hardly can believe that
  c in such task is harder to maintain than python".

---


cheers,


   Samium Gromoff

Re: Will 2.6 require Python for any configuration ? (CML2)

[Tom Rini]

On Fri, Aug 24, 2001 at 01:12:33AM +0400, Samium Gromoff wrote:
> > The main reason to include it, is that that's what it was done in.
> > If you go back and read the archives, ESR goes over why all sorts of
> > other languages wouldn't work as easily.
>
> in such cases the solution is to elaborate, and not to
> leave things to decay.

Well, the flames finally died down and everyone forgot about it again
for a while.

> > That wasn't my point at all.  My point was that if you're somehow
> > transfering the 21mb source .tar.bz2'ed, you can also stand to transport
> > the 4mb of python 2.0.1 source, tar.gz'ed over as well.  In other words,
> > having to bring python over any of the methods that Jes mentioned isn't
> > any more painful than the kernel source.  It's roughly the size of a couple
> > of vmlinux'es.
>   i was sarcastic here. actually the fact is that
>   4MB of tarred sources is more than 10 .c files
>   doing the same thing 1.5x times faster.

Where'd you get 1.5x from? :)  But, go ahead and re-write the CML2 engine
in C.  There's been some work done on this.  A few people (Al Viro?) even
said that if this got into 2.5 they'd do a 'C' version.  Many many months
ago, if i recall correctly.

> > Have you tried cml2 on your p166?  ESR went and did much speed tweaking of
> > the code about 6 months ago it seems like and managed to please some of the
> > people using a low-end pentium.  Building a kernel on a 386 isn't approcaching
> > tolerable right now anyhow.  Someone pointed out today or yesterday it takes
> > ~10 days.
>   it is not an excuse to make things even worser.

It shouldn't be a consideration at all.  I'd go as far as to say any sort of
speed bonus on a 486 is gravy.  In other words, how fast something will be
on 10 year old hardware shouldn't be important (I'm speaking of 386 with
10 years.)

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

Re: Will 2.6 require Python for any configuration ? (CML2)

[Samium Gromoff]

> And if you're trying to do this on the machine you're trying to make
> supported, you're going to have lots of fun.
  so you like python. okay.

  but imagine the X arch hacker does not like python,
and nevertheless needs to port it on arch X.
  still fun? 
  hardly... 


:)

----


cheers,


   Samium Gromoff

Re: Will 2.6 require Python for any configuration ? (CML2)

[Tom Rini]

On Fri, Aug 24, 2001 at 01:18:02AM +0400, Samium Gromoff wrote:
> > And if you're trying to do this on the machine you're trying to make
> > supported, you're going to have lots of fun.
>
>   so you like python. okay.

Actually, I only know a bit of python.  It seems nice but I've been
caught up doing real work (and learning PPC asm at the same time.)

>   but imagine the X arch hacker does not like python,
> and nevertheless needs to port it on arch X.
>   still fun?

Well I know python is endian-clean.  I'd suspect it's even 32/64bit clean.
So it's not a matter of 'port' but compile.  And Linus has done things which
have made lots of kernel hackers scratch their head for a while.  (Jump
out of this fire and into the min/max macros in 2.4.9 fire to see
what I mean).

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

Re: Will 2.6 require Python for any configuration ? (CML2)

[Jes Sorensen]

>>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:

Tom> On Fri, Aug 24, 2001 at 01:18:02AM +0400, Samium Gromoff wrote:
>> but imagine the X arch hacker does not like python, and
>> nevertheless needs to port it on arch X.  still fun?

Tom> Well I know python is endian-clean.  I'd suspect it's even
Tom> 32/64bit clean.  So it's not a matter of 'port' but compile.  And
Tom> Linus has done things which have made lots of kernel hackers
Tom> scratch their head for a while.  (Jump out of this fire and into
Tom> the min/max macros in 2.4.9 fire to see what I mean).

Again, please try and do real porting work before you make such silly
statements. Perl is 32/64 little/big-endian clean ... and still it's
the absolutely worst app to bring up (even X tends to be easier).

There is a lot more to this than meets the eye!

Jes

Re: Will 2.6 require Python for any configuration ? (CML2)

[Tom Rini]

On Fri, Aug 24, 2001 at 02:59:37PM +0200, Jes Sorensen wrote:
> >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:
> 
> Tom> On Fri, Aug 24, 2001 at 01:18:02AM +0400, Samium Gromoff wrote:
> >> but imagine the X arch hacker does not like python, and
> >> nevertheless needs to port it on arch X.  still fun?
> 
> Tom> Well I know python is endian-clean.  I'd suspect it's even
> Tom> 32/64bit clean.  So it's not a matter of 'port' but compile.  And
> Tom> Linus has done things which have made lots of kernel hackers
> Tom> scratch their head for a while.  (Jump out of this fire and into
> Tom> the min/max macros in 2.4.9 fire to see what I mean).
> 
> Again, please try and do real porting work before you make such silly
> statements. Perl is 32/64 little/big-endian clean ... and still it's
> the absolutely worst app to bring up (even X tends to be easier).

perl is (or was last time I tried it) a PITA because it doesn't have
a real config script.  In my experiance (and I do have a lot here)
apps which use autoconf/et al suck less at porting, as long as you have
autoconf/libtool/et al happy.  Then it usually comes down to poorly
written code.

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

Re: Will 2.6 require Python for any configuration ? (CML2)

[Jes Sorensen]

>>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:

Tom> On Fri, Aug 24, 2001 at 02:59:37PM +0200, Jes Sorensen wrote:
>>  Again, please try and do real porting work before you make such
>> silly statements. Perl is 32/64 little/big-endian clean ... and
>> still it's the absolutely worst app to bring up (even X tends to be
>> easier).

Tom> perl is (or was last time I tried it) a PITA because it doesn't
Tom> have a real config script.  In my experiance (and I do have a lot
Tom> here) apps which use autoconf/et al suck less at porting, as long
Tom> as you have autoconf/libtool/et al happy.  Then it usually comes
Tom> down to poorly written code.

The configure script has almost nothing to do with this! autoconf
etc. is just little bits on the surface. So pardon if I question the
relevance of your experience in this area.

The real problems with Perl is that it exercises almost all of your
libc, uses floating point math, dlopen() and a lot of other
funnies. Successfully running Perl's test suite is a very good
indicator for the completeness of your libc. On the other hand gcc and
the development toolchain are remarkably easy to accomodate on that
front.

Jes

Re: Will 2.6 require Python for any configuration ? (CML2)

[Tom Rini]

On Fri, Aug 24, 2001 at 05:42:47PM +0200, Jes Sorensen wrote:
 
> The real problems with Perl is that it exercises almost all of your
> libc, uses floating point math, dlopen() and a lot of other
> funnies. Successfully running Perl's test suite is a very good
> indicator for the completeness of your libc. On the other hand gcc and
> the development toolchain are remarkably easy to accomodate on that
> front.

We're getting someplace now.  If you question the ability of the platform
to make reliable tools such as perl, why do you think you'll have good
binutils and gcc on the platform?  If your platform doesn't have dlopen()
working then yes, python2 will probably be pissed off.  I conceeded this
last time too I think.  If you're trying to bring up a platform
compiling a kernel is a good test of having lots of things working.  With
2.6 it'll mean one more thing is at least somewhat working, dlopen().  Or
you can go and make a CML2 interp in C.  Or sh.  I'm quite happy cross
compiling stuff until things get a bit farther along on a brand spanking new
platform.

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

Re: Will 2.6 require Python for any configuration ? (CML2)

[Jes Sorensen]

>>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes:

Tom> On Fri, Aug 24, 2001 at 05:42:47PM +0200, Jes Sorensen wrote:
>> The real problems with Perl is that it exercises almost all of your
>> libc, uses floating point math, dlopen() and a lot of other
>> funnies. Successfully running Perl's test suite is a very good
>> indicator for the completeness of your libc. On the other hand gcc
>> and the development toolchain are remarkably easy to accomodate on
>> that front.

Tom> We're getting someplace now.  If you question the ability of the
Tom> platform to make reliable tools such as perl, why do you think
Tom> you'll have good binutils and gcc on the platform?

Maybe because I have ''been there done that''! This is exactly how
things were when we brought up the ia64 port.

Tom> If your
Tom> platform doesn't have dlopen() working then yes, python2 will
Tom> probably be pissed off.  I conceeded this last time too I think.
Tom> If you're trying to bring up a platform compiling a kernel is a
Tom> good test of having lots of things working.  With 2.6 it'll mean
Tom> one more thing is at least somewhat working, dlopen().

Do you have any idea how dlopen() actually works? It requires you to
have dynamic loading working, that means shared libraries ... please
do us a favor and go read the code in glibc in elf/*.c and
sysdep/<some-arch>/dl-machine.h (plus a couple of other
files). Implementing shared library support is ''very interesting''
but it's by far the first thing you do on a new system.

That aside, I am not aware whether Python2 actually requires dlopen to
work well enough to run CML2.

Tom> Or you
Tom> can go and make a CML2 interp in C.  Or sh.  I'm quite happy
Tom> cross compiling stuff until things get a bit farther along on a
Tom> brand spanking new platform.

Well I can tell you that most people would like to compile their
kernels on the host even BEFORE they get shared libraries going.

Ok, I think I have spent enough time on this discussion now, back to
hacking.

Jes

Re: Will 2.6 require Python for any configuration ? (CML2)

[Samium Gromoff]

> And if you're trying to do this on the machine you're trying to make
> supported, you're going to have lots of fun.
  so you like python. okay.

  but imagine the X arch hacker does not like python,
and nevertheless needs to port it on arch X.
  still fun? 
  hardly... 


:)

----


cheers,


   Samium Gromoff

Re: Will 2.6 require Python for any configuration ? (CML2)

[Rick Hohensee]

> 
> On Thu, Aug 23, 2001 at 10:25:17PM -0400, Rick Hohensee wrote:
>  
> > Throwing in Python is going to hurt me.
> 
> Then either help out the people trying to do it in C, or maintain a fwd
> compatible version of 'config'/'oldconfig'.
> 
> -- 
> Tom Rini (TR1265)
> http://gate.crashing.org/~trini/
> 

google for 

cLIeNUX Cheap Quick Dirty kernel config

Rick Hohensee


www.			cLIeNUX                          .com