Will 2.6 require Python for any configuration ? (CML2)

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)

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

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.

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

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

[stuff cut]

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

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.

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.

And many a new system has python.

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

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

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

Of course, this is what I meant.

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

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

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

Kurt

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

On Thu, 23 Aug 2001, Daniel Phillips did have cause to say:

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

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 <[email protected]> /> Northern lights wander \\

//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

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

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/

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

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.

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.

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

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

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

Sounds like we have another volunteer here?!

/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\

//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Or perl.

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

Which is what? The dependancy on python2?

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/

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

[snip]

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

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.

Tom> Which is what? The dependancy on python2?

Yes

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

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

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.

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/

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.

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

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

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

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.

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/

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

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.

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: [email protected]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

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 <[email protected]> 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

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: [email protected]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

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

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.

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

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

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

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

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

"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