[kbuild-devel] Re: Disgusted with kbuild developers
Hi! . A Microsoft engineer wrote scripts/Configure. For three years, I have lived in fear that Microsoft would notice this fact and use it to attack Linux through public relations channels or legal means. They haven't yet, so I have been wrong so far. Teehee. I don't think you have anything to worry about, Microsoft would be incredibly embarassed to admit they're contributing to 'problem number 1'. I agree, but we know some strange 'behaviour' of MS. They have a lot of lawers, they can make us a lot of trouble. (You will notice that there are no copyright statment on that file, only the name of authors). Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-)) way to include 'free' patches: sign and send to FSF a piece of paper, that the patches CAN be included. I think nobody in Linux have done that, thus we can expect some more troubles and microsoft is a large troubles-maker FSF is actually doing something completely different, they want to be able to change copyrights. Pavel -- (about SSSCA) I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy. --hpa ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Disgusted with kbuild developers
. A Microsoft engineer wrote scripts/Configure. For three years, I have lived in fear that Microsoft would notice this fact and use it to attack Linux through public relations channels or legal means. They haven't yet, so I have been wrong so far. Teehee. I don't think you have anything to worry about, Microsoft would be incredibly embarassed to admit they're contributing to 'problem number 1'. -- Daniel ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Disgusted with kbuild developers
Daniel Phillips wrote: . A Microsoft engineer wrote scripts/Configure. For three years, I have lived in fear that Microsoft would notice this fact and use it to attack Linux through public relations channels or legal means. They haven't yet, so I have been wrong so far. Teehee. I don't think you have anything to worry about, Microsoft would be incredibly embarassed to admit they're contributing to 'problem number 1'. I agree, but we know some strange 'behaviour' of MS. They have a lot of lawers, they can make us a lot of trouble. (You will notice that there are no copyright statment on that file, only the name of authors). Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-)) way to include 'free' patches: sign and send to FSF a piece of paper, that the patches CAN be included. I think nobody in Linux have done that, thus we can expect some more troubles and microsoft is a large troubles-maker giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Disgusted with kbuild developers
On Tue, 19 Feb 2002, Giacomo Catenazzi wrote: I agree, but we know some strange 'behaviour' of MS. They have a lot of lawers, they can make us a lot of trouble. (You will notice that there are no copyright statment on that file, only the name of authors). Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-)) way to include 'free' patches: sign and send to FSF a piece of paper, that the patches CAN be included. I think nobody in Linux have done that, thus we can expect some more troubles and microsoft is a large troubles-maker ... and script in question is fscking trivial to reimplement if and when it happens. End of story. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Disgusted with kbuild developers
Jeff Garzik replies to me: mec I believe that CML1 is rococo and I welcome a replacement. I think that mec leapfrog development is a good strategy here, just as it was for ALSA. jg I think this is a key mistake. See Al's message Of Bundling, Dao, jg I am reading lkml from an archive and I saw only the Friday night messages. I have caught up now. I agree with Al's strategy in Of Bundling, Dao, and Cowardice. Let me talk about the list-based makefiles. Long before I submitted the first list-based makefile to the kernel tree (drivers/sound/makefile), I had a whole rewrite of every makefile. These were the Dancing Makefiles and several ideas came out of them: CONFIG_SMP and list-based makefiles in particular. I never thought I'd be able to get the Dancing Makefiles adopted. I spent a whole year just getting CONFIG_SMP merged! So I came to view it as a useful laboratory project to show what kinds of things were viable or not. Then 2.1.XX developed a real problem with drivers/sound/Makefile. The if-statement based approach was not working. The if-statements changed on every patch level and new bugs came in for every patch level. I said to myself aha, list-based makefiles will solve this problem. I wrote a new drivers/sound/Makefile. Here is the important point: I did not touch Rules.make *at all*. I put some translation lines into drivers/sound/Makefile so that it would just work. Between 2.2 and 2.4, several people -- including Jeff Garzik -- converted a lot more makefiles incremenetally to the new style. This process got about 80% done incrementally. Eventually one of the old-style Makefiles developed a similar problem with new tweaks in every patch level leading to a new batch of bug reports. Linus said something like to hell with this and summarily removed support for the old-style. So ... I leapfrogged in my own work area, but I put out incremental patches that solved problems that other people wanted solved. It was also a very painful process for me. My patches got black-holed numerous times. jg It's impossible to prove that Eric's CML2 rulebase reflects a current jg CML1 rulebase, primarily for this reason. That's an important property and I haven't given enough weight to it. :-( It would be nice if: The new tool reads both CML1 and CML2. Deploy the new tool. People could convert directories to CML2 one at a time. jg Those are meta-properties. Indeed, all my criteria are meta-properties. jg CML2's syntax is not reflective of the direction of being able to plop jg down driver.c and driver.conf and having the config/make system jg magically notice it. This driver.conf idea did not exist when CML2 was invented. So it looks like there is a market opportunity here: a tool that reads CML1 files and also reads some kind of new driver.conf files, which can be written in a fresh new language. jg Would you support the replacement of in-kernel jg configure/Menuconfig/xconfig with in-kernel mconfig? I believe that mconfig is best distributed as a semi-independent package, distributed in the way that modutils is distributed today. I think that's better than in-kernel. Between the choice of in-kernel configure/menuconfig/xconfig and in-kernel mconfig, I would go for in-kernel mconfig. jg If we want to migrate to a point where all kernel configuration is jg maintained solely outside the kernel, I actually support that. But as a jg SEPARATE migration step. I do not want to drop all config tools from jg the kernel and tell people use mconfig in the same breath. My vision of the migration path was that mconfig would be distributed separately and co-exist with configure/menuconfig/xconfig. When the market share of mconfig becomes high enough( (say, 80% to 90%), then drop support for configure/menuconfig/xconfig. Michael Elizabeth Chastain mailto:[EMAIL PROTECTED] love without fear ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Disgusted with kbuild developers
Nicolas Pitre [EMAIL PROTECTED]: Show us that you're able to write a 1 for 1 functional correspondance between CML1 and CML2 and propose that for inclusion into 2.5 Eric S. Raymond [EMAIL PROTECTED]: This requirement is absurd. When someone designs a new VM, we don't demand that it crash or lock up the system in exactly the same way that the old one did before it can go into the kernel. I disagree with this statement in three different ways. [1] lkml readers are kbuild users, not kbuild developers kbuild is special. The relationship between most lkml readers and most linux kernel code (such as the VM) is the relationship of developers to a corpus of code. The relationship of most lkml readers to kbuild is the relationship of *users* to a corpus of code. I think of everybody that has not submitted patches or written code to kbuild tools as a kbuild user. Oddly enough, people behave differently in their roles as users than their roles as developers. Many people who have actually worked on menuconfig would love to shitcan that monstrosity, but people who run menuconfig don't mind the ugliness of its implementation. The first thing users want to know about a software upgrade is: is it going to break what I am doing right now. In a mature system, it really is better to leave 10 old bugs unfixed rather than introduce one new bug. I believe that is why people ask for functional equivalence, even for bugs. Users do not trust developers to decide which behaviours are bugs! In order to do my work, it has to match some internal concepts I have about correctness, elegance, robustness, all that stuff. But in order for other people to want to use my work, it has to match their concepts of what is useful to them. [2] CML1 is working in the field Your view is that CML1 is as bad as a VM that crashes or locks up. This view is rejected by a significant number of CML1 users, including a lot of influential ones. People are building kernels with CML1 every day. Even if you believe that CML1 as a language has hopeless problems, you should acknowledge that many users do not believe this. So when you show up and say here, CML2 language will solve all your CML1 language problems, you are offering a lot of people something negative or neutral to them. A month ago I was disenheartened about this. It looked like CML1 language was going to be good enough for the entire lifespan of the Linux kernel. Now it turns out that there is a new customer requirement: people want driver.conf files. A new language has the opportunity to define driver.conf files and that would be a significant advantage over CML1. [3] kernel development is highly multi-threaded with interesting locks The kernel development process involves hundreds of people across several trees. It's fundamentally different from one person writing code on one branch of one tree -- the same way that a massive multi-threaded program running on a 256-processor server is programmed differently than a single-threaded program on a uniprocessor. I believe there are development locks. I could probably write a whole essay on the nature of these locks, the atomic operations in the development process, the way that people use multi-phase protocols to get something merged without grabbing giant locks, and so on. Kbuild work has the unfortunate property that it sometimes needs big locks. I think that CML2 involves a giant lock: you want to lock every Config.in file at once, modify it from top to bottom, and commit them all at once. Okay. That's a huge lock, especially considering that at any given moment, lots of people have unmerged work-in-progress, as well as whole parallel trees. Linus can acquire a lock that big, because sometimes he just grabs the Big Kernel Development Lock, changes some interface, and relies on us mortals to patch up the loose edges. This works pretty well because it leverages his vision by letting other people share the grunt work. But I think that Linus prefers to avoid grabbing the BKDL, and it's no use pushing him. I think it would be good for you to think about the nature of this locking process (starting with: is mec onto something here or is he delusional?) Then think about how to get to the end vision of CML2 with a less severe locking strategy. Michael Elizabeth Chastain mailto:[EMAIL PROTECTED] love without fear ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
