[kbuild-devel] Re: Announce: Kernel Build for 2.5, Release 2.1 is available
On Tuesday 23 April 2002 01:00, Keith Owens wrote: > On Sun, 21 Apr 2002 16:32:35 +0200, > Daniel Phillips <[EMAIL PROTECTED]> wrote: > >On Sunday 21 April 2002 09:43, Keith Owens wrote: > >> Content-Type: text/plain; charset=us-ascii > >> > >> Release 2.1 of kernel build for kernel 2.5 (kbuild 2.5) is available. > >> http://sourceforge.net/projects/kbuild/, Package kbuild-2.5, download > >> release 2.1. > > > >Have you got an update on first-time build performance? > > 30% faster than the existing kernel build system. Egad. And we're waiting for what, exactly? > >By the way, is there a reason for not providing a single bzip of all the > >2.4 + 2.5 files? Not that the slight inconvenience matters all that much, > >since hopefully it will all be in mainline soon. > > Everybody needs different bits (2.4 vs 2.5, i386 vs ia64) and each bit > is being updated separately. Forget I said *anything at all* above. You can do no wrong. -- Daniel ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Announce: Kernel Build for 2.5, Release 2.1 is available
On Sunday 21 April 2002 09:43, Keith Owens wrote: > Content-Type: text/plain; charset=us-ascii > > Release 2.1 of kernel build for kernel 2.5 (kbuild 2.5) is available. > http://sourceforge.net/projects/kbuild/, Package kbuild-2.5, download > release 2.1. Hi Keith, Have you got an update on first-time build performance? Not that I'm all that worried about it, incremental performance is *way* more important to me, however, first-time performance seems to be something of a predictor of when your work will get into mainline. I'm marking each day that kbuild 2.5 isn't in mainline on the wall of my little cave here, as every day kbuild 2.bad.old continues find some way of wasting my time. By the way, is there a reason for not providing a single bzip of all the 2.4 + 2.5 files? Not that the slight inconvenience matters all that much, since hopefully it will all be in mainline soon. Downloaded, installing... -- Daniel ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Disgusted with kbuild developers
On February 19, 2002 09:04 am, Giacomo Catenazzi wrote: > 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. Under the GPL Having exclusive copyright just means that you can relicense later stuff if you want. I'm not clear on why FSF considers it so important but for Linux it just means that nobody, not even Linus, can ever release under a new license (e.g., the BSD license). So actually, having multiple copyright holders is a good thing for you, it protects your investment in GPL capital better. I say, if Microsoft employees want to contribute to Linux, the more the merrier. Heck, even billg is going to wake up on day (with a start, in the middle of the night) and realize which way the wind is blowing. Steve Jobs did. > I think nobody in Linux have done that, Great. > thus we can expect some more troubles and microsoft is a large > troubles-maker Oh yes... -- Daniel ___ 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
Re: [kbuild-devel] Re: CML2-2.1.3 is available
On January 22, 2002 12:11 am, Daniel Phillips wrote: > On January 21, 2002 06:05 pm, Giacomo Catenazzi wrote: > > Daniel Phillips wrote: > > > > > > I detect a slight lack of symmetry here, shouldn't it be "make > > > autoconfig"? Pardon me if this has been beaten to^W^W discussed above. > > > > Yes. It should be "make autoconfig", for symmterty reasons :-) > > I called the files and the project autoconfigure, because > > 'autoconfig' is already an utility made by GNU. (not related > > to kernel) > > This is kernel autoconfig, different namespace, same idea. I don't think > you have a problem. Besides, last time I checked, autoconfig wasn't > copyrighted. Oh wait, the 'real autoconf' is called autoconf, not autoconfig (duh) so there is no reason at all to avoid 'make autoconfig'. -- Daniel ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: pte-highmem-5
On January 23, 2002 06:38 am, Hugh Dickins wrote: > First half agreed, second half not sure. Maybe no series at all. > Could it be worked with just the one serie, Pardon me, but what is a serie? It's not an english word: http://www.m-w.com/dictionary.htm -- Daniel ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2-2.1.3 is available
On January 21, 2002 06:05 pm, Giacomo Catenazzi wrote: > Daniel Phillips wrote: > > > > > I detect a slight lack of symmetry here, shouldn't it be "make > > autoconfig"? Pardon me if this has been beaten to^W^W discussed above. > > > Yes. It should be "make autoconfig", for symmterty reasons :-) > I called the files and the project autoconfigure, because > 'autoconfig' is already an utility made by GNU. (not related > to kernel) This is kernel autoconfig, different namespace, same idea. I don't think you have a problem. Besides, last time I checked, autoconfig wasn't copyrighted. -- Daniel ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
On January 15, 2002 08:37 pm, Rob Landley wrote: > On Tuesday 15 January 2002 03:25 pm, Russell King wrote: > > On Tue, Jan 15, 2002 at 02:53:24PM -0500, Eric S. Raymond wrote: > > > * The `vitality' flag is gone from the language. Instead, the > > > autoprober detects the type of your root filesystem and forces > > > its symbol to Y. > > > > This seems like a backwards step. What's the reasoning for breaking the > > ability to configure the kernel for a completely different machine to the > > one that you're running the configuration/build on? > > He didn't. If you want to do that, run "make menuconfig" instead of "make > autoconfigure". I detect a slight lack of symmetry here, shouldn't it be "make autoconfig"? Pardon me if this has been beaten to^W^W discussed above. -- 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 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 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
