Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Thursday 06 December 2001 12:25 pm, Alan Cox wrote: So has anyone had time to test the Python version 1.5 based CML2 that was posted? Would that make it more acceptable? For 2.5 its a great leap forward. For 2.4 its irrelevant. Its simply not the way stable kernel trees are run, even for people who think they are above the rules and traditions Ooh, I can't resist... You mean like Linus? (Ducks, runs, looks innocent, runs some more...) Rob P.S. Can we seperate add new subsystem y prime and remove old subsystem y. LIke the new and old SCSI error handling, which have been in the tree in parallel for some time? Did I hear Eric ever suggest removing the old configurator for 2.4? Anybody? ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Thu, Dec 06, 2001 at 07:07:14PM +0100, Martin Dalecki wrote: John Stoffel wrote: The requirement for python2 is a bit of a pain, but hey, for 2.5, it's not a problem. It is just a BIT OF PAIN. It gives me more trouble than the trouble I have even with the insufficiencies of the current make system. Basta. Does the fact that there's a simple patch fixing the requirement down to Python 1.5 alleviate your troubles? /David _ _ // David Weinehall [EMAIL PROTECTED] / Northern lights wander \\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \ http://www.acc.umu.se/~tao// Full colour fire / ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
John Stoffel wrote: The requirement for python2 is a bit of a pain, but hey, for 2.5, it's not a problem. It is just a BIT OF PAIN. It gives me more trouble than the trouble I have even with the insufficiencies of the current make system. Basta. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Thu, 6 Dec 2001 05:03:12 -0500, Rob Landley [EMAIL PROTECTED] wrote: P.S. Can we seperate add new subsystem y prime and remove old subsystem y. LIke the new and old SCSI error handling, which have been in the tree in parallel for some time? Did I hear Eric ever suggest removing the old configurator for 2.4? Anybody? That is exactly what I am doing, adding kbuild 2.5 and CML2 then removing kbuild 2.4 and CML1 in a later step. Neither Eric nor I want to parallel run the old and new systems for more than one kernel release in 2.5. Neither Eric nor I want to parallel run kbuild 2.5 and CML2 in the 2.4 kernels, we only did the work there because we had no development tree. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
Rob Landley [EMAIL PROTECTED]: P.S. Can we seperate add new subsystem y prime and remove old subsystem y. LIke the new and old SCSI error handling, which have been in the tree in parallel for some time? Did I hear Eric ever suggest removing the old configurator for 2.4? Anybody? The whole point of putting the new configurator in would be to be able to drop the old one out. But that would be strictly Marcelo's call. It would be up to him to decide whether the tradeoff were worth it. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Everything you know is wrong. But some of it is a useful first approximation. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tuesday 04 December 2001 12:43 pm, Dave Jones wrote: On Tue, 4 Dec 2001, Eric S. Raymond wrote: After CML2 has proven itself in 2.5, I do plan to go back to Marcelo and lobby for him accepting it into 2.4, on the grounds that doing so will simplify his maintainance task no end. ... I'm just going to say Today's problems, today's tools. So anyone perfectly happy with an older distro that didn't ship python2-and-whatever-else gets screwed when they want to build a newer kernel. Nice. Dave. 1) Moving from 2.2-2.4, it wouldn't work at all without a newer compiler and newer modutils, and it really helped to have a C library and eight zillion other things upgraded. So talking about what 2.6 will need that's an amazing red herring. 2) In terms of a 2.4 backport, if the old stuff isn't removed (the current garbage that does menuconfig et al), then who cares? It's another option they don't have to use. It's also Marcelo's call. 3) The fact Linus was cc'd on this before I trimmed it suggests to me that people are still wishfully thinking that the battle they lost before the linux-kernel summit would just magically re-open at the last minute. It's not about the fact that reiserfs, ext3, and a new VM subsystem went into 2.4 but THIS is way too much, it's a group of people bitching about python because they don't like the concept of significant whitespace. Technically speaking, this is another variant of the good old indentation/coding style thread that just won't die. It's insidious, isn't it? Rob ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Wed, 5 Dec 2001, Rob Landley wrote: So anyone perfectly happy with an older distro that didn't ship python2-and-whatever-else gets screwed when they want to build a newer kernel. Nice. 1) Moving from 2.2-2.4, it wouldn't work at all without a newer compiler and newer modutils, and it really helped to have a C library and eight zillion other things upgraded. So talking about what 2.6 will need that's an amazing red herring. My comment was in regard to the subthread concerning the backport of CML2 to 2.4 only. Not 2.5/2.6. Yes, tools need to be upgraded OVER MAJOR VERSIONS. I was not debating that. 2) In terms of a 2.4 backport, if the old stuff isn't removed (the current garbage that does menuconfig et al), then who cares? Anyone maintaining Config.in files. What you're proposing doubles the amount of work to keep them up to date. Especially for out-of-tree code. It's also Marcelo's call. Absolutely. It's not about the fact that reiserfs, ext3, and a new VM subsystem went into 2.4 but THIS is way too much And did any of these require updated tools to build the kernel ? No. I could take a kernel with these features, and build it on a 6 month old distro. it's a group of people bitching about python because they don't like the concept of significant whitespace. Crap. It's about not screwing over an installed userbase for a feature that is nothing more than a Nice to have add-on for 2.4. It's taken us long enough to get 2.4 where it is, hopefully the days of things getting shovelled in enmasse are over. Technically speaking, this is another variant of the good old indentation/coding style thread that just won't die. I recommend Kill by thread. Works wonders. regards, Dave. -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
Greg Banks [EMAIL PROTECTED]: It seems my main contribution has been to provide Eric with incentive to clarify his language spec and speed up his parser. Stimulus for which I have been deeply grateful. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a ..every Man has a Property in his own Person. This no Body has any Right to but himself. The Labour of his Body, and the Work of his Hands, we may say, are properly his. The great and chief end therefore, of Mens uniting into Commonwealths, and putting themselves under Government, is the Preservation of their Property. -- John Locke, A Treatise Concerning Civil Government ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
Christoph Hellwig [EMAIL PROTECTED]: On Mon, Dec 03, 2001 at 12:06:12PM +1100, Keith Owens wrote: The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4. Is the CML2 merge actually agreed on? Yes, unless Linus has changed his mind since March. Which would be his privilege, of course -- but since the CML1 maintainers are unanimous that CML1 is too kludgy to live and Linus knows that, it seems unlikely. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a All governments are more or less combinations against the people. . .and as rulers have no more virtue than the ruled. . . the power of government can only be kept within its constituted bounds by the display of a power equal to itself, the collected sentiment of the people. -- Benjamin Franklin Bache, in a Phildelphia Aurora editorial 1794 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tue, Dec 04, 2001 at 02:29:58PM +0100, Christoph Hellwig wrote: On Tue, Dec 04, 2001 at 08:16:40AM -0500, Eric S. Raymond wrote: N separate implementations means N dialects and N**2 compatibility problems. Nicer just to have *one* parser, *one* compiler, and *one* service class that supports several thin front-end layers, yes? No? Oh man. When you think one implementation of a 'standard' is better then multiple go to the MS world. Wouldn't multiple tools which don't quite work to a 'standard' better represent the MS world? Which is what all of the cml1 tools do. All of these tools just require the runtime contained in the LSB and no funky additional script languages. Also none needs a binary intermediate representation of the config. I quote Linus at the 2.5 kernel summit: Python is not an issue. Unless and until he changes his mind about that, waving around this kind of argument is likely to do your case more harm than good. For me (and others) it is an issues. Why? If you want to re-open the case for saving CML1, you'd be better off demonstrating how CML1 can be used to (a) automatically do implied side-effects when a symbol is changed, With mconfig it can be implemented easily - I don't see the point in doing it, though. To show that CML1 doesn't need to die yet. (b) guarantee that the user cannot generate a configuration that violates stated invariants, and What do you mean with that? That you can't turn on CONFIG_FOO_BAR unless CONFIG_FOO is on. This is getting at things like USB V4L devices which need CONFIG_USB and CONFIG_VIDEODEV set to !n. This is done poorly in CML1. (c) unify the configuration tree so that the equivalents of arch/* files never suffer from lag or skew when an architecture-independent feature is added to the kernel. One toplevel config file can be implemented in CML1 easily, using mconfig or the old and ugly tools, it's just a question of changeing the rule base in tree. Lots of changing of the Config.in files. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
Creating a dependency on Python? Is a non-issue. Current systems that are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python is nice and it does not create such unmaintainable mess. Whether Python2 - which means most users dont have it. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
Giacomo Catenazzi [EMAIL PROTECTED]: I don't think esr changed non problematic rules, but one: all rules without help become automatically dependent to CONFIG_EXPERIMENTAL. I don't like it, but I understand why he makes this decision. No, it's CONFIG_EXPERT. And this change is not wired in. Comment out this declaration in the top-level rulesfile: condition nohelp on EXPERT and it reverts to old behavior. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The conclusion is thus inescapable that the history, concept, and wording of the second amendment to the Constitution of the United States, as well as its interpretation by every major commentator and court in the first half-century after its ratification, indicates that what is protected is an individual right of a private citizen to own and carry firearms in a peaceful manner. -- Report of the Subcommittee On The Constitution of the Committee On The Judiciary, United States Senate, 97th Congress, second session (February, 1982), SuDoc# Y4.J 89/2: Ar 5/5 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
David Woodhouse [EMAIL PROTECTED]: [EMAIL PROTECTED] said: I don't think esr changed non problematic rules, but one: all rules without help become automatically dependent to CONFIG_EXPERIMENTAL. I don't like it, but I understand why he makes this decision. That is precisely the kind of bogus change which should _not_ be done in such an underhand way. Underhanded? Hardly. It was right there, with explanation, in one of the release announcements I've been posting. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a As war and government prove, insanity is the most contagious of diseases. -- Edward Abbey ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
[EMAIL PROTECTED] said: No, it's CONFIG_EXPERT. And this change is not wired in. Comment out this declaration in the top-level rulesfile: condition nohelp on EXPERT and it reverts to old behavior. Good. Please make that the default when submitting the first version of CML2. You can submit patches which effect the change in behaviour later, and they can be individually considered. -- dwmw2 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
[EMAIL PROTECTED] said: I'm listening...what can I do for you? Simply assure me that I don't have to scan every line of the CML2 files for such changes, and that you'll make a reasonable effort to make the first set of CML2 rules match the existing CML1 behaviour, without introducing any controversial changes. Submit the stuff you know is less popular, like hiding options without help text, later - and we can argue about them at the time. -- dwmw2 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
[EMAIL PROTECTED] wrote: In fact, here's all I want to know about the whole CML2/kbuild 2.5 issue. Right now I upgrade my kernel like this (simplified slightly): apply latest patches mv .config .. make mrproper mv ../.config . make oldconfig make dep make bzlilo modules modules_install reboot Will I still be able to do it this simply in 2.5.x? (Assuming there's eventually a 2.5.x I can get to compile cleanly. :-) Yes you can do. hmm. only for the CML2 part. The new kbuild-2.5 (also the new Makefile) will no more work with your command: make dep: is no more needed make bzlilo modules modules_install: it would be a simble make install: (and you configure with CML1/CML2 what install means). giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
[mailing lists trimmed] Christoph Hellwig writes: Indepenand of wether 2.6 will use CML1 or CML2 I hope it won't ship with the actual config tool. It's so much nicer to have mconfig compiled once in /usr/bin instead of compiling menuconfig all the time in the tree. I agree, it's really a userland tool, and belongs in its own tarball/rpm/deb, like modutils. But it's up to the config tool author to decide this. Michael C ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Wed, Dec 05, 2001 at 10:00:32AM +1100, Keith Owens wrote: On Tue, 4 Dec 2001 18:21:15 + (GMT), Alan Cox [EMAIL PROTECTED] wrote: make bzlilo modules modules_install: it would be a simble make install: (and you configure with CML1/CML2 what install means). How does it handle that when install means different things on each box of a set of them NFS sharing the kernel tree. This is a real world example I made kbuild 2.5 install very flexible to cater for cases like this. The answer depends on whether you want every compile to be the same with different install steps on the target machines or each compile is different. In the different compile case you have a single source tree (mounted read only if you like) and separate object trees for each compile run. The .config lives in the object directory so is machine local. The object trees can be NFS mounted or can use local disk on each build machine, as a bonus this avoids NFS writes and runs much faster. If you want a common compile on one machine followed by different installs on each machine then you have three choices. (1) make install with an install prefix path (say /var/tmp) will install the kernel, modules, System.map and .config in a holding directory on the build machine, the other machines can then copy the install data to wherever they need it. Whether the copy is done from the build machine to the target directories or on the target machine is an NFS implementation detail. (2) make installable (the default target) on the build machine then run make install with overrides on the target machines. All the install config variables are exposed for override on the install step. (3) make installable on the build machine with .config specifying an install script name. Then make install on each target system, the version of the install script is local to the target machine. If none of those suit your environment, let me know what you are trying to achieve and I will see about adding support to kbuild 2.5. Would it be easy to add hooks for make-rpm and make-kpkg and alike, as methods for make installable? /David _ _ // David Weinehall [EMAIL PROTECTED] / Northern lights wander \\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \ http://www.acc.umu.se/~tao// Full colour fire / ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
RH shipped python2 beginning RH 7.2. Eh? I'm going to go check my old 7.1 CDs... Feel free. You'll find python v1. There is a very early python2 on the optional power tools CD that some folks will have but downloaders generally dont bother with. Trust me, I went through the same pain with a python2 specific gnome2 file convertor ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
Eric S. Raymond wrote: Alan Cox [EMAIL PROTECTED]: Creating a dependency on Python? Is a non-issue. Current systems that are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python is nice and it does not create such unmaintainable mess. Whether Python2 - which means most users dont have it. I'm pretty sure that's true any more, Alan. Red Hat shipped Python 2 in 7.1, so the RPM-based distros like KRUD and Mandrake have had it for seven months. Debian had it before that. Requiring 2.0 looked aggressive when I did it, but it wasn't -- I could safely project that it would be deployed everywhere except on a set of measure zero by the time the actual cutover happened. ~# rpm -qa | grep -i python python-1.5.2-35 python-xmlrpc-1.5.0-1 pythonlib-1.28-1 rpm-python-4.0.3-1.03 python-devel-1.5.2-35 Just another megaton unnecessary programming language to compile somehting like the kernel? I think you are exaggerating the problem. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On December 4, 2001 05:52 pm, Giacomo Catenazzi wrote: I don't think esr changed non problematic rules, but one: all rules without help become automatically dependent to CONFIG_EXPERIMENTAL. I don't like it, but I understand why he makes this decision. I love it. -- Daniel ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
make bzlilo modules modules_install: it would be a simble make install: (and you configure with CML1/CML2 what install means). How does it handle that when install means different things on each box of a set of them NFS sharing the kernel tree. This is a real world example ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tue, Dec 04, 2001 at 06:27:26PM +0100, Martin Dalecki wrote: Alan Cox wrote: Creating a dependency on Python? Is a non-issue. Current systems that are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python is nice and it does not create such unmaintainable mess. Whether Python2 - which means most users dont have it. Most users sure as hell shouldn't be playing with 2.5.x right now anyways. With any sort of 'luck' it'll be 6 months at least before 2.5.x becomes stable enough that it will probably compile all the time again and not have a random fs eating bug. In 6 months even woody might be frozen :) And then you will end with: python1.4x, python2, python3 rewrite in python1 and so on and so on. Say what? Python (with the exception of undocumented features) has been pretty good about compatiblity. If it works with 1.5.x and doesn't rely on undocumented features, it'll work with 2.0x, 2.1x and 2.2x. Thanks but NO thanks Then go help Greg Banks in his CML2-in-C project. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tuesdayen den 4 December 2001 18.08, RaúlNúñez de Arenas Coronado wrote: Hi Matthias :) Creating a dependency on Python? Is a non-issue. Maybe for you. For me it *is* an issue. I don't like more and more dependencies for the kernel. I mean, if I can drop kbuild and keep on building the kernel with the old good 'make config' I won't worry, but otherwise I don't think that kernel building depends on something like Python. Why must I install Python in order to compile the kernel? I don't understand this. I think there are better alternatives, but kbuild seems to be imposed any way. You don't make the pen yourself when writing a letter either. I don't like to be forced in a particular pen, that's the reason why I use and develop for linux. What are the precise issues with Python? Just claiming it is an issue is not useful for discussing this. Archive pointers are welcome. Well, let's start writing kernel drivers with Python, Perl, PHP, awk, etc... And, why not, C++, Ada, Modula, etc... The kernel should depend just on the compiler and assembler, IMHO. And you'll select and pass every .c file directly to the compiler via the command line ?? Sounds like a giant step forwards !! ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tue, Dec 04, 2001 at 06:08:57PM +0100, Ra?l N??ez de Arenas Coronado wrote: Hi Matthias :) Creating a dependency on Python? Is a non-issue. Maybe for you. For me it *is* an issue. I don't like more and more dependencies for the kernel. I mean, if I can drop kbuild and keep on building the kernel with the old good 'make config' I won't worry, but otherwise I don't think that kernel building depends on something like Python. One of the things that I _think_ is happening is that lots of other scripts/ files are being redone, and thus removing them from the list, so in effect we're trading out one or two for just Python. Why must I install Python in order to compile the kernel? I don't understand this. I think there are better alternatives, but kbuild seems to be imposed any way. kbuild != CML2. It all boils down to the current 'language' having no real definitive spec, and having 3+ incompatible parsers. We could either try and tweak the language slightly (and probably make it even harder on external parsers) or throw it out and try again. ESR wrote CML2 with a Python interpreter, so it uses Python. The spec for CML2 is out there, and there's even a CML2-in-C project. If you don't want to use Python, go help (I believe Greg Banks is who ESR mentioned is in charge of it) that project out and then convince Linus to include it. You don't make the pen yourself when writing a letter either. I don't like to be forced in a particular pen, that's the reason why I use and develop for linux. To carry this analogy out a bit more, the details on how to make a pen exist, so if you don't like ESRs pen, go make your own. That's why a lot of people use Linux too. What are the precise issues with Python? Just claiming it is an issue is not useful for discussing this. Archive pointers are welcome. Well, let's start writing kernel drivers with Python, Perl, PHP, awk, etc... And, why not, C++, Ada, Modula, etc... The kernel should depend just on the compiler and assembler, IMHO. The right tools for the right job. C is good for the kernel. Python is good at manipulating strings. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tue, Dec 04, 2001 at 06:26:27PM +, Alan Cox wrote: Python2 - which means most users dont have it. Most users sure as hell shouldn't be playing with 2.5.x right now anyways. With any sort of 'luck' it'll be 6 months at least before 2.5.x becomes stable enough that it will probably compile all the time again and not have a random fs eating bug. In 6 months even woody might be frozen :) It wont become stable if nobody can configure it because nobody will build it or run it. Lots of people build non stable kernels because its a) fun b) a way to learn and play with the system c) they might make their own small fix and mark not all of the them are demon kernel hackers. But they can't install python2? I _think_ there's src.rpms on Python.org that will install as python2 even... -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
Tom Rini [EMAIL PROTECTED]: Maybe for you. For me it *is* an issue. I don't like more and more dependencies for the kernel. I mean, if I can drop kbuild and keep on building the kernel with the old good 'make config' I won't worry, but otherwise I don't think that kernel building depends on something like Python. One of the things that I _think_ is happening is that lots of other scripts/ files are being redone, and thus removing them from the list, so in effect we're trading out one or two for just Python. That is my intention. The right tools for the right job. C is good for the kernel. Python is good at manipulating strings. *Perl* is good at strings. Python is good at actual data structures :-). -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The people of the various provinces are strictly forbidden to have in their possession any swords, short swords, bows, spears, firearms, or other types of arms. The possession of unnecessary implements makes difficult the collection of taxes and dues and tends to foment uprisings. -- Toyotomi Hideyoshi, dictator of Japan, August 1588 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
David Weinehall [EMAIL PROTECTED]: Yeah, let's lose the dependencies on perl, make, awk, sed, ld, ar, nm, strip, objcopy, objdump, depmod, grep, xargs, find, gzip, wish, tcl/tk and possibly others. That'd surely shave a lot of diskspace off my buildsystem. It's not like I use any of them for anything else... I'm going to remove a few of these. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a You need only reflect that one of the best ways to get yourself a reputation as a dangerous citizen these days is to go about repeating the very phrases which our founding fathers used in the great struggle for independence. -- Attributed to Charles Austin Beard (1874-1948) ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tue, 4 Dec 2001, Eric S. Raymond wrote: Don't do it! A stable kernel should be stable also on the building tools. That will be Marcelo's call, not mine. Ohhh, that sounds a lot like I'm not the maintainer, I'm not responsible for the code I submit ;))) *runs like hell* Rik -- Shortwave goes a long way: irc.starchat.net #swl http://www.surriel.com/ http://distro.conectiva.com/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tue, 4 Dec 2001, David Weinehall wrote: So anyone happy with an older distro that didn't ship gcc-2.95.x, x 2 gets screwed when they want to build a newer kernel. Nice. The difference being that recommended compiler versions don't change midway through a stable series. Neither should any other part of the buildtools. regards, Dave. -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
That's been the case all along, sans python2. Newer kernels need newer tools. That's always been the case. Not during stable releases. In fact we've jumped through hoops several times to try and keep egcs built kernels working Are we not talking about the 2.5 kernel build tree? My understanding of the numbering of kernels is that the 2.4.x tree is stable; and the 2.5.x tree is the new development tree If the suggestion was to alter the 2.4 tree in a way that required additional tools; I could understand the concern; the 2.5 tree is unstable; and so to go from 2.5.a to 2.5.b I expect to have to be really carefull and *READ* the release notes; similarly from 2.2.x to 2.4.x; but 2.4.a to 2.4.b I generally detar the tree; copy my .config over check with menuconfig that things make sense; build the kernel and expect things to work; release notes you ask? ..I only glance at them to see if anything strikes my eye; but they are not read completely Trevor ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
Are we not talking about the 2.5 kernel build tree? My understanding of the numbering of kernels is that the 2.4.x tree is stable; and the 2.5.x tree is the new development tree Erik is talking about crapping in both trees, as opposed to 2.5 only ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tue, 4 Dec 2001 18:21:15 + (GMT), Alan Cox [EMAIL PROTECTED] wrote: make bzlilo modules modules_install: it would be a simble make install: (and you configure with CML1/CML2 what install means). How does it handle that when install means different things on each box of a set of them NFS sharing the kernel tree. This is a real world example I made kbuild 2.5 install very flexible to cater for cases like this. The answer depends on whether you want every compile to be the same with different install steps on the target machines or each compile is different. In the different compile case you have a single source tree (mounted read only if you like) and separate object trees for each compile run. The .config lives in the object directory so is machine local. The object trees can be NFS mounted or can use local disk on each build machine, as a bonus this avoids NFS writes and runs much faster. If you want a common compile on one machine followed by different installs on each machine then you have three choices. (1) make install with an install prefix path (say /var/tmp) will install the kernel, modules, System.map and .config in a holding directory on the build machine, the other machines can then copy the install data to wherever they need it. Whether the copy is done from the build machine to the target directories or on the target machine is an NFS implementation detail. (2) make installable (the default target) on the build machine then run make install with overrides on the target machines. All the install config variables are exposed for override on the install step. (3) make installable on the build machine with .config specifying an install script name. Then make install on each target system, the version of the install script is local to the target machine. If none of those suit your environment, let me know what you are trying to achieve and I will see about adding support to kbuild 2.5. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tue, 2001-12-04 at 13:01, Alan Cox wrote: Feel free. You'll find python v1. There is a very early python2 on the optional power tools CD that some folks will have but downloaders generally dont bother with. Also, I don't think any version of RedHat has Tkinter 2.0 yet ... Robert Love ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tue, Dec 04, 2001 at 01:43:20PM -0500, Eric S. Raymond wrote: David Weinehall [EMAIL PROTECTED]: Yeah, let's lose the dependencies on perl, make, awk, sed, ld, ar, nm, strip, objcopy, objdump, depmod, grep, xargs, find, gzip, wish, tcl/tk and possibly others. That'd surely shave a lot of diskspace off my buildsystem. It's not like I use any of them for anything else... I'm going to remove a few of these. You know, I _was_ ironic about not needing most of those... /David _ _ // David Weinehall [EMAIL PROTECTED] / Northern lights wander \\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \ http://www.acc.umu.se/~tao// Full colour fire / ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tue, 4 Dec 2001, Eric S. Raymond wrote: Alan Cox [EMAIL PROTECTED]: I'm pretty sure that's true any more, Alan. Red Hat shipped Python 2 in 7.1, so the RPM-based distros like KRUD and Mandrake have had it for seven months. Debian had it before that. RH shipped python2 beginning RH 7.2. Eh? I'm going to go check my old 7.1 CDs... We shipped python2 as an extra package ever since 7.1, but it's not in any of the default installs because the standard tools still use python 1.5.x for compatibility reasons. LLaP bero -- This message is provided to you under the terms outlined at http://www.bero.org/terms.html ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tue, Dec 04, 2001 at 06:43:17PM +0100, Dave Jones wrote: On Tue, 4 Dec 2001, Eric S. Raymond wrote: After CML2 has proven itself in 2.5, I do plan to go back to Marcelo and lobby for him accepting it into 2.4, on the grounds that doing so will simplify his maintainance task no end. ... I'm just going to say Today's problems, today's tools. So anyone perfectly happy with an older distro that didn't ship python2-and-whatever-else gets screwed when they want to build a newer kernel. Nice. So anyone happy with an older distro that didn't ship gcc-2.95.x, x 2 gets screwed when they want to build a newer kernel. Nice. /David _ _ // David Weinehall [EMAIL PROTECTED] / Northern lights wander \\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \ http://www.acc.umu.se/~tao// Full colour fire / ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tue, Dec 04, 2001 at 06:08:57PM +0100, RaúlNúñez de Arenas Coronado wrote: Hi Matthias :) Creating a dependency on Python? Is a non-issue. Maybe for you. For me it *is* an issue. I don't like more and more dependencies for the kernel. I mean, if I can drop kbuild and keep on building the kernel with the old good 'make config' I won't worry, but otherwise I don't think that kernel building depends on something like Python. Why must I install Python in order to compile the kernel? I don't understand this. I think there are better alternatives, but kbuild seems to be imposed any way. You don't make the pen yourself when writing a letter either. I don't like to be forced in a particular pen, that's the reason why I use and develop for linux. What are the precise issues with Python? Just claiming it is an issue is not useful for discussing this. Archive pointers are welcome. Well, let's start writing kernel drivers with Python, Perl, PHP, awk, etc... And, why not, C++, Ada, Modula, etc... Noone's suggested writing kernel-drivers in anything but a combination of C and assembler (with as little asm as possible), apart from some heretics that suggested usage of C++ in the kernel... This only involves usage of Python2 for configuring your kernel. The kernel should depend just on the compiler and assembler, IMHO. Yeah, let's lose the dependencies on perl, make, awk, sed, ld, ar, nm, strip, objcopy, objdump, depmod, grep, xargs, find, gzip, wish, tcl/tk and possibly others. That'd surely shave a lot of diskspace off my buildsystem. It's not like I use any of them for anything else... Hey, lets lose C and ASM too, and create all your binaries by writing hexvalues into a file. /David Weinehall _ _ // David Weinehall [EMAIL PROTECTED] / Northern lights wander \\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \ http://www.acc.umu.se/~tao// Full colour fire / ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tue, 4 Dec 2001, Dave Jones wrote: On Tue, 4 Dec 2001, Eric S. Raymond wrote: After CML2 has proven itself in 2.5, I do plan to go back to Marcelo and lobby for him accepting it into 2.4, on the grounds that doing so will simplify his maintainance task no end. ... I'm just going to say Today's problems, today's tools. So anyone perfectly happy with an older distro that didn't ship python2-and-whatever-else gets screwed when they want to build a newer kernel. Nice. Dave. I have python. I also have ed. When the only tool you know how to use is a hammer, every problem begins to look like a nail. FYI, I have never known a problem that python has solved, only changed. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). I was going to compile a list of innovations that could be attributed to Microsoft. Once I realized that Ctrl-Alt-Del was handled in the BIOS, I found that there aren't any. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On December 4, 2001 06:50 pm, Daniel Phillips wrote: On December 4, 2001 05:52 pm, Giacomo Catenazzi wrote: I don't think esr changed non problematic rules, but one: all rules without help become automatically dependent to CONFIG_EXPERIMENTAL. I don't like it, but I understand why he makes this decision. I love it. Having thought about this a little more, I don't think it's correct. It's cute and I still love the idea of forcing people to document - I sometimes imagine there exist contributors who make a point of not documenting - but the need for a clean design with as few corner cases as possible trumps that. Suppose I'm working on my patch, doing the part that hooks into config. It works, I can see my new feature, but for some strange reason the buttons are grayed out. After I fiddle a while I clue in to the idea that the 'experimental' setting might have something to do with it, I turn it on and then my buttons work. Now, what the? Eventually I figure out this is supposed to be a feature, not a bug, and that including some help will activate my buttons. So I curse the author up and down and submit a patch to remove that feature. This is a admittedly a small point and I'm not going to quibble about it any more. I'm happy the kbuild process is being cleaned up. I've wasted too much time due to shortcomings in the old one. I'll wait until this gets into the tree before submitting my patch ;-) -- Daniel ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Tue, Dec 04, 2001 at 06:30:45PM +0100, Christoph Hellwig wrote: On Tue, Dec 04, 2001 at 11:18:38AM -0600, Michael Elizabeth Chastain wrote: As far as CML2 versus an mconfig-based solution, I am tilted towards CML2, as it is simply a better language. I would be happy with either choice if Linus made one of those choices. I would be unhappy if 2.6/3.0 continued to ship with Configure/menuconfig/xconfig. Indepenand of wether 2.6 will use CML1 or CML2 I hope it won't ship with the actual config tool. It's so much nicer to have mconfig compiled once in /usr/bin instead of compiling menuconfig all the time in the tree. No to mention it's much easier to propagate bug fixes this way.. If the configure system is outside of the kernel, you have the possibility of requiring newer user-space utilities as a stable kernel changes over time... ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Mon, 3 Dec 2001, Keith Owens wrote: Hi Keith, _If_ I can get CML2 support working before 2.5.1 comes out then we go 2.5.2-pre1 Add kbuild 2.5 with both CML1 and CML2 support. 2.5.2-pre2 Remove kbuild 2.4. Do you plan to fix the x2 slowdown before removing kbuild 2.4 ? Or is this something that will be worked on as we progress through 2.5. regards, Dave. -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converting the 2.5 kernel to kbuild 2.5
On Sun, 2 Dec 2001 20:19:46 -0500, Eric S. Raymond [EMAIL PROTECTED] wrote: Keith Owens [EMAIL PROTECTED]: The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4. The schedule I heard from Linus at the kernel summit was that both changes were to go in between 2.5.1 and 2.5.2. I would prefer sooner than later because I'm *really* *tired* of maintaining a parallel rulebase. I have not got CML2 support working in kbuild 2.5 so I left a bit of room between kbuild 2.5 going in and cutting over to CML2. _If_ I can get CML2 support working before 2.5.1 comes out then we go 2.5.2-pre1 Add kbuild 2.5 with both CML1 and CML2 support. 2.5.2-pre2 Remove kbuild 2.4. 2.5.2-pre3 Remove CML1. 2.5.2 I would prefer that sequence myself, but I don't want to promise a timetable that I cannot deliver. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
