Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Wayne.Brown]

I have nothing against it being faster -- *as long as nothing about the way I
use it changes.*  Most of my kernel upgrades are done while I'm at work,
programming, doing Solaris system admin, sitting in meetings, making phone
calls, or any of the other things my employer is paying me to do.  I have a cron
job that checks kernel.org periodically and pops up a message on my screen when
a new kernel patchset appears there.  When that happens, I quickly switch to
another virtual console, ftp the patch, and then:

zcat patch-X.Y.Z.gz | patch -p1 -s -E
mv .config ..
make mrproper
mv ../.config .
make oldconfig
make dep && make bzlilo modules modules_install

Then I go back to work.  When the compile finishes I stop long enough to reboot,
then start working again, and unless there's a problem, don't give another
thought to it until the next patchset is ready.

I have all this down to a science.  All these commands are in my bash command
history so I can pull them up with a couple of keystrokes.  I've done them all
so many times that I can type them from scratch almost without thinking about
them.  I've gone through this whole process while in the midst of business
conversations without anyone even noticing that I'm doing it.  (Of course, if
there are compile errors it's another story, and I have to deal with those
later, but often I can go through several upgrades in a row without any errors.)
Anything that changes this process -- new commands, new syntax, whatever --
takes extra time and disrupts whatever else I'm doing.

Different people have different needs.  I don't care how many new bells and
whistles the developers add for their own use, but it would be nice if those of
us who just want to apply patches and recompile with a minimum of fuss could
keep our old user interfaces.





Nicolas Pitre <nico@cam.org> on 05/17/2002 05:09:20 PM

To:   Wayne Brown/Corporate/Altec@Altec
cc:   linux-kernel@vger.kernel.org

Subject:  Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3




But even if you recompile *everything* _everytime_, kbuild 2.5 is "faster".

What do you have against that?


Nicolas

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Robert Love]

On Fri, 2002-05-17 at 15:59, Wayne.Brown@altec.com wrote:

> I have nothing against it being faster -- *as long as nothing about the way I
> use it changes.*  Most of my kernel upgrades are done while I'm at work,
> programming, doing Solaris system admin, sitting in meetings, making phone
> calls, or any of the other things my employer is paying me to do.  I have a cron
> job that checks kernel.org periodically and pops up a message on my screen when
> a new kernel patchset appears there.  When that happens, I quickly switch to
> another virtual console, ftp the patch, and then:

So we should curb progress in the name of you not spending 2 minutes
rewriting your bash scripts or repopulating your bash history with new
commands?

Bah go away.  I and most other people here are the exact opposite - give
us new features, less bugs, or innovation and we will surely change. 
Otherwise we would still be in the stone age.

	Robert Love

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Horst von Brand]

Wayne.Brown@altec.com said:

[Long explanation on routine kernel compilation elided]]

> I have all this down to a science.  All these commands are in my bash
> command history so I can pull them up with a couple of keystrokes.

Guess what... after the first time you do it the newfangled way the
new commands will be in .bash_history too!

>                                                                    I've
> done them all so many times that I can type them from scratch almost
> without thinking about them.

If you do it _that_ often, then you'll get it the same automation in no
time with any strange new commands. Or find a way to integrate them with
your cron job that downloads patches (Heck... I update gcc from CVS
nightly, build it and run its testsuite from cron). But just compiling any
random kernel that shows up is not enough...
--
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Diego Calleja]

On Fri, 17 May 2002 17:59:28 -0500
Wayne.Brown@altec.com escribió:

> I have all this down to a science.  All these commands are in my bash
> command history so I can pull them up with a couple of keystrokes.  I've
> done them all so many times that I can type them from scratch almost
> without thinking about them.  I've gone through this whole process while
> in the midst of business conversations without anyone even noticing that
> I'm doing it.  (Of course, if there are compile errors it's another
> story, and I have to deal with those later, but often I can go through
> several upgrades in a row without any errors.) Anything that changes
> this process -- new commands, new syntax, whatever -- takes extra time
> and disrupts whatever else I'm doing.

oh, please, you don't have to learn 666 new commands. I'd like to 
think that we've enought intelligence to learn a few new command.

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Mike Galbraith]

>Why?  Because I didn't mention who said it?  OK, it was Giacomo Catenazzi.  You
>can read the original article yourself at
>http://marc.theaimsgroup.com/?l=linux-kernel&m=100748835520343&w=2 if you wish.
>In case you don't here's the relevant part.  I had asked what the differences
>were between the old and new versions, and Giacomo replied with this:
>
>
>>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).
>
>
>Satisfied now?  Or did you mean I should have installed kbuild2.5 and found out
>for myself?  If I had any interest in using it that would be reasonable.  But
>all I wanted was to find out how bad things are going to be after I eventually
>get stuck with it.  So I asked for information from someone who already knew
>about it.  Do you ever take anyone else's word for anything, or do you always
>have to try everything out for yourself?

I meant precisely this:  Given that you have obviously not tried kbuild 2.5, your comments are utterly meaningless.  The fact that you are satisfied with the old kbuild has absolutely nothing to do with kbuild 2.5 or it's being ready for integration into the 2.5 kernel  (clue: the development tree.. where things change/improve).

>This is my last post on this subject.  There doesn't seem to be anyone here who
>understands the concept of being satisfied with a tool and seeing no need to
>improve it.  If I'm not satisfied with something, I'll expend large amounts of
>time, effort and money to achieve even trivial improvements.  But if I *am*
>satisfied with something, then I don't want to spend even a trivial amount of
>effort trying to achieve "improvements" that I don't need.
>
>I never expected everyone to abandon their own needs to satisfy mine.  It would
>be nice if they tried to accomodate my needs while satisfying their own, but I
>didn't expect that either.  What I expect is that kbuild 2.5 (and eventually
>CML2) will show up in the kernel sooner or later, and I'll just have to live
>with it.  All my original message on this subject was intended to do was to
>point out that not everyone was happy with the situation.  The rest of you have
>reacted as if you're afraid Linus might listen to me and do it my way.  Well,
>relax, I doubt he cares any more about what I want than the rest of you do.  At
>least he didn't feel the need to jump down my throat about it.

I did not jump down your throat, I carefully molded my reply to be as accurate as possible, and aimed it at your head.   Unfortunately, your buttocks seem to have also been in the line of fire.

>I don't need the new kbuild.  I don't want the new kbuild.  But I'm going to be
>stuck with it, and there's nothing I can do to stop it.  So for those of you who
>DO want it, why is it such a burden hear that not everyone thinks the way you
>do?  

You're right..  we do think differently.

I don't want the existing problems with the kernel build process to continue forever, and that Keith is doing something about them.  I think that's great.

	-Mike

>"Mike Galbraith" <EFAULT@gmx.de> on 05/18/2002 05:25:11 AM
>
>To:
>cc:    (bcc: Wayne Brown/Corporate/Altec)
>
>Subject:  Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3
>
>
>
>>Someone said here on the list a few months ago that "make bzlilo" was replaced
>>by "make install" and that it was necessary to configure the "install" option's
>>behavior.
>
>Someone said?  Your opinion on this subject just lost all of it's value.
>
>     -Mike

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Mike Galbraith]

>Someone said here on the list a few months ago that "make bzlilo" was replaced
>by "make install" and that it was necessary to configure the "install" option's
>behavior.

Someone said?  Your opinion on this subject just lost all of it's value.

	-Mike


>David Lang <david.lang@digitalinsight.com> on 05/18/2002 12:23:10 AM
>
>To:   Wayne Brown/Corporate/Altec@Altec
>cc:   linux-kernel@vger.kernel.org
>
>Subject:  Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3
>
>
>
>Wayne, the only change (other then better, faster functions) is the
>elimination of steps.
>
>if it will satisfy you you can continue to do a make mproper and make dep
>and just ignore the 'no target found' messages.
>
>David Lang
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Wayne.Brown]

Why?  Because I didn't mention who said it?  OK, it was Giacomo Catenazzi.  You
can read the original article yourself at
http://marc.theaimsgroup.com/?l=linux-kernel&m=100748835520343&w=2 if you wish.
In case you don't here's the relevant part.  I had asked what the differences
were between the old and new versions, and Giacomo replied with this:


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


Satisfied now?  Or did you mean I should have installed kbuild2.5 and found out
for myself?  If I had any interest in using it that would be reasonable.  But
all I wanted was to find out how bad things are going to be after I eventually
get stuck with it.  So I asked for information from someone who already knew
about it.  Do you ever take anyone else's word for anything, or do you always
have to try everything out for yourself?

This is my last post on this subject.  There doesn't seem to be anyone here who
understands the concept of being satisfied with a tool and seeing no need to
improve it.  If I'm not satisfied with something, I'll expend large amounts of
time, effort and money to achieve even trivial improvements.  But if I *am*
satisfied with something, then I don't want to spend even a trivial amount of
effort trying to achieve "improvements" that I don't need.

I never expected everyone to abandon their own needs to satisfy mine.  It would
be nice if they tried to accomodate my needs while satisfying their own, but I
didn't expect that either.  What I expect is that kbuild 2.5 (and eventually
CML2) will show up in the kernel sooner or later, and I'll just have to live
with it.  All my original message on this subject was intended to do was to
point out that not everyone was happy with the situation.  The rest of you have
reacted as if you're afraid Linus might listen to me and do it my way.  Well,
relax, I doubt he cares any more about what I want than the rest of you do.  At
least he didn't feel the need to jump down my throat about it.

I don't need the new kbuild.  I don't want the new kbuild.  But I'm going to be
stuck with it, and there's nothing I can do to stop it.  So for those of you who
DO want it, why is it such a burden to hear that not everyone thinks the way you
do?






"Mike Galbraith" <EFAULT@gmx.de> on 05/18/2002 05:25:11 AM

To:
cc:    (bcc: Wayne Brown/Corporate/Altec)

Subject:  Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3



>Someone said here on the list a few months ago that "make bzlilo" was replaced
>by "make install" and that it was necessary to configure the "install" option's
>behavior.

Someone said?  Your opinion on this subject just lost all of it's value.

     -Mike

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Tomas Szepe]

> Satisfied now?  Or did you mean I should have installed kbuild2.5 and found out
> for myself?  If I had any interest in using it that would be reasonable.  But
> all I wanted was to find out how bad things are going to be after I eventually
> get stuck with it.

'get stuck' is really some good wording here I have to say.

> This is my last post on this subject.  There doesn't seem to be anyone here who
> understands the concept of being satisfied with a tool and seeing no need to
> improve it.

The point of most of the ones who angrily replied to your original post was,
I believe, that you're obviously not in a position to make remarks about the
quality of the new build system.

Sorry, but the opinion of someone who complains about having to switch to
"make install" instead of "make oldconfig dep clean bzImage modules" (the
new command even being much simpler for chrissakes) and admits that that's
the only problem they can see, isn't of much value here.

> If I'm not satisfied with something, I'll expend large amounts of time,
> effort and money to achieve even trivial improvements.  But if I *am*
> satisfied with something, then I don't want to spend even a trivial amount
> of effort trying to achieve "improvements" that I don't need.

Just a side note:
Why exactly are you upgrading your kernel every time a new release is out,
when you don't have a need to do so? I honestly doubt you're waiting for
a particular fix.

> I don't need the new kbuild.  I don't want the new kbuild.  But I'm going to be
> stuck with it, and there's nothing I can do to stop it.  So for those of you who
> DO want it, why is it such a burden to hear that not everyone thinks the way you
> do?

Man, no offense meant here, but has it ever occurred to you that the clock won't ever
stop and one has to keep learning new things every day? From what you have written
it seems you can be in serious trouble each time your favorite grocery store closes
down and you have to go round one more corner to get your bread and butter.


Tomas

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[DervishD]

    Hello Wayne :)

>I don't need the new kbuild.  I don't want the new kbuild.  But I'm
>going to be stuck with it, and there's nothing I can do to stop it. 
>So for those of you who DO want it, why is it such a burden to hear
>that not everyone thinks the way you do?

    Independently of my opinion about the subject, you have send a
polite and very sensible answer to all the attacks you have received
(some of them very out of common sense, I must say...).

    Congratulations for your message. I was thinking that people are
more concerned of defending decisions that to really make
improvementes... Just look at the messages last week: many people
took a big effort to attack you verbally, but my patch to a nasty
(but maybe harmless) but have totally gone ignored...

    Keep on like that, Wayne ;)

    Raúl

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Mike Fedyk]

On Sat, May 18, 2002 at 12:32:25PM -0500, Wayne.Brown@altec.com wrote:
> I never expected everyone to abandon their own needs to satisfy mine.  It would
> be nice if they tried to accomodate my needs while satisfying their own, but I
> didn't expect that either.  

IIRC, Kbuild-2.5 already silently accepts all of the old kbuild-2.4 commands
without problems.

As long as you end up running "make install" the rest of the old commands
will be ignored.  You can go on with all of the old commands, if you want
without any trouble.  This will allow you to use the same commands with
kbuild-2.4 and kbuild-2.5, in case you decide to switch between both kernels
and want to use the same commands.

Also kbuild-2.5 does have features that allow you to call scripts from "make
install", but it's not mandatory.

Kieth, can you confirm that all of the old kbuild-2.4 commands have been
wrapped in kbuild-2.5 commands?

Thanks,

Mike

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Albert D. Cahalan]

Mike Fedyk writes:
> On Sat, May 18, 2002 at 12:32:25PM -0500, Wayne.Brown@altec.com wrote:

>> I never expected everyone to abandon their own needs to satisfy mine.
>> It would be nice if they tried to accomodate my needs while satisfying
>> their own, but I didn't expect that either.  
>
> IIRC, Kbuild-2.5 already silently accepts all of the old kbuild-2.4
> commands without problems.
>
> As long as you end up running "make install" the rest of the old commands
> will be ignored.  You can go on with all of the old commands, if you want
> without any trouble.

Well, not everybody trusts "make install" to do something useful.
I'd do something like this:

make clean
bzip2 -dc ../foo.bz2 | patch -E -s -p1
make menuconfig
time script build-log
make vmlinux && make modules && make modules_install && exit
cp vmlinux /boot/vmlinux-2.5.16
cp System.map /boot/System.map-2.5.16
cp .config /boot/config-2.5.16
sync
su -
joe /etc/yaboot.conf
sync
exit

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Keith Owens]

On Mon, 20 May 2002 01:09:36 -0400 (EDT), 
"Albert D. Cahalan" <acahalan@cs.uml.edu> wrote:
>Well, not everybody trusts "make install" to do something useful.
>I'd do something like this:
>
>make clean
>bzip2 -dc ../foo.bz2 | patch -E -s -p1
>make menuconfig
>time script build-log
>make vmlinux && make modules && make modules_install && exit
>cp vmlinux /boot/vmlinux-2.5.16
>cp System.map /boot/System.map-2.5.16
>cp .config /boot/config-2.5.16
>sync
>su -
>joe /etc/yaboot.conf
>sync
>exit

Then you will be pleased to hear that kbuild 2.5 supports precisely
that model.  It has an install menu which lets you specify the name of
the install kernel, whether to install System.map and .config, and the
names to install them under.  It even has an config entry for a
post-install script.

After setting up these variables (only needs to be done once)

CONFIG_INSTALL_KERNEL_NAME=/boot/vmlinux-KERNELRELEASE
CONFIG_INSTALL_SYSTEM_MAP=y
CONFIG_INSTALL_SYSTEM_MAP_NAME=/boot/System.map-KERNELRELEASE
CONFIG_INSTALL_CONFIG=y
CONFIG_INSTALL_CONFIG_NAME=/boot/config-KERNELRELEASE
CONFIG_INSTALL_SCRIPT=y
CONFIG_INSTALL_SCRIPT_NAME=joe /etc/yaboot.conf

Your build process collapes to

  make -j defconfig installable && sudo make install

It does not get any simpler than that!

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Juan Quintela]

>>>>> "albert" == Albert D Cahalan <acahalan@cs.uml.edu> writes:

albert> Mike Fedyk writes:
>> On Sat, May 18, 2002 at 12:32:25PM -0500, Wayne.Brown@altec.com wrote:

>>> I never expected everyone to abandon their own needs to satisfy mine.
>>> It would be nice if they tried to accomodate my needs while satisfying
>>> their own, but I didn't expect that either.  
>> 
>> IIRC, Kbuild-2.5 already silently accepts all of the old kbuild-2.4
>> commands without problems.
>> 
>> As long as you end up running "make install" the rest of the old commands
>> will be ignored.  You can go on with all of the old commands, if you want
>> without any trouble.

albert> Well, not everybody trusts "make install" to do something useful.
albert> I'd do something like this:

albert> make clean
albert> bzip2 -dc ../foo.bz2 | patch -E -s -p1

albert> make menuconfig
albert> time script build-log
albert> make vmlinux && make modules && make modules_install && exit

this is standard

albert> cp vmlinux /boot/vmlinux-2.5.16
albert> cp System.map /boot/System.map-2.5.16
albert> cp .config /boot/config-2.5.16
albert> sync
albert> su -
albert> joe /etc/yaboot.conf
albert> sync
albert> exit

You can put that thing in /sbin/install and actual build system will
do what you want.  Here we modify grub || lilo in x86 in that script,
it is not difficult to automatize.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Keith Owens]

On Sun, 19 May 2002 21:31:01 -0700, 
Mike Fedyk <mfedyk@matchmail.com> wrote:
>Kieth, can you confirm that all of the old kbuild-2.4 commands have been
>wrapped in kbuild-2.5 commands?

make *config	- same
make dep	- kbuild 2.5 says 'nothing to do'.
make [b]zImage	- Replaced by 'installable', with the kernel type
		  specified in .config.
make modules	- Replaced by 'installable'.
make bzlilo	- All install targets have been subsumed by 'install'.

'make installable' is the default target if nothing else is specified.
kbuild 2.5 moves the type of kernel to build into .config, it is no
longer specified on the command line.  This makes it even easier to
build from a previous kernel, copy .config and

 make -j defconfig installable && sudo make -j install

There is no need for separate passes for kernel and modules.  Building
kernel and modules separately has always been a potential source of
human error, kbuild 2.5 delivers a complete and accurate set of
installable files.  Because kbuild 2.5 only rebuilds what is necessary,
collapsing the two passes into one actually saves build time.

'make install' uses .config entries to determine what to install, where
to install it, whether or not you want to install System.map or .config
and where they are installed.  Again, this makes it much easier to
reuse a previous config.  It also makes life easier for people doing
cross compiles, set one config variable to a directory and everything
is installed relative to that directory, instead of relative to /.

Another config entry specifies an install script to be run after
install.  You are no longer restricted to a hard coded script name.
kbuild 2.5 deliberately does not include any interfaces to lilo, grub,
syslinux, etc., nor to apt, rpm, tarballs etc., they are all handled by
the post-install script.  Sample scripts are provided, if you don't
like them you can modify to suit or write your own post-install
scripts.  This is more flexible than "everything goes through
/sbin/install".

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Wayne.Brown]

Someone said here on the list a few months ago that "make bzlilo" was replaced
by "make install" and that it was necessary to configure the "install" option's
behavior.





David Lang <david.lang@digitalinsight.com> on 05/18/2002 12:23:10 AM

To:   Wayne Brown/Corporate/Altec@Altec
cc:   linux-kernel@vger.kernel.org

Subject:  Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3



Wayne, the only change (other then better, faster functions) is the
elimination of steps.

if it will satisfy you you can continue to do a make mproper and make dep
and just ignore the 'no target found' messages.

David Lang

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[John Weber]

Wayne.Brown@altec.com wrote:
> 
> Someone said here on the list a few months ago that "make bzlilo" was replaced
> by "make install" and that it was necessary to configure the "install" option's
> behavior.
> 

Actually, the "install behavior" is quite nice.  I wrote a script that 
installs the kernel and sets it up in the right way for my 
non-kbuild-2.5 kernel... much of this script is doing stuff like getting 
the current kernel version, etc... the new kbuild allows you to specify 
the install script you want to use and exports a bunch of variables that 
make this script easier to write.  Moreover, I believe there is a 
default install that mimicks that of the current kernel so that the 
changing of install's behavior is not mandatory.

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Wayne.Brown]

Gee, what a tolerant attitude.  I state my preference -- not a demand, just a
preference -- that the old interfaces be retained IN ADDITION to whatever new
features are added, and you say "Bah go away."  I'm sorry, I must have missed
the rule that says only people who agree with you are allowed to post their
opinions on lkml.

The current system works just fine for my needs.  I've never seen the point of
trying to "improve" things that are already good enough.  But now that you've
explained it to me so politely, I understand.  My top priority is supposed to be
what YOU want, even though you don't care anything at all about what I want.

So, in the spirit of your oh-so-helpful message, let me say this:  Get stuffed,
jerk.





Robert Love <rml@tech9.net> on 05/17/2002 06:14:45 PM

To:   Wayne Brown/Corporate/Altec@Altec
cc:   linux-kernel@vger.kernel.org

Subject:  Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3




So we should curb progress in the name of you not spending 2 minutes
rewriting your bash scripts or repopulating your bash history with new
commands?

Bah go away.  I and most other people here are the exact opposite - give
us new features, less bugs, or innovation and we will surely change.
Otherwise we would still be in the stone age.

     Robert Love

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[David Lang]

Wayne, the only change (other then better, faster functions) is the
elimination of steps.

if it will satisfy you you can continue to do a make mproper and make dep
and just ignore the 'no target found' messages.

David Lang

On Sat, 18 May 2002 Wayne.Brown@altec.com wrote:

> Date: Sat, 18 May 2002 00:09:19 -0500
> From: Wayne.Brown@altec.com
> To: linux-kernel@vger.kernel.org
> Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3
>
>
>
> Gee, what a tolerant attitude.  I state my preference -- not a demand, just a
> preference -- that the old interfaces be retained IN ADDITION to whatever new
> features are added, and you say "Bah go away."  I'm sorry, I must have missed
> the rule that says only people who agree with you are allowed to post their
> opinions on lkml.
>
> The current system works just fine for my needs.  I've never seen the point of
> trying to "improve" things that are already good enough.  But now that you've
> explained it to me so politely, I understand.  My top priority is supposed to be
> what YOU want, even though you don't care anything at all about what I want.
>
> So, in the spirit of your oh-so-helpful message, let me say this:  Get stuffed,
> jerk.
>
>
>
>
>
> Robert Love <rml@tech9.net> on 05/17/2002 06:14:45 PM
>
> To:   Wayne Brown/Corporate/Altec@Altec
> cc:   linux-kernel@vger.kernel.org
>
> Subject:  Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3
>
>
>
>
> So we should curb progress in the name of you not spending 2 minutes
> rewriting your bash scripts or repopulating your bash history with new
> commands?
>
> Bah go away.  I and most other people here are the exact opposite - give
> us new features, less bugs, or innovation and we will surely change.
> Otherwise we would still be in the stone age.
>
>      Robert Love
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Diego Calleja]

On Sat, 18 May 2002 00:09:19 -0500
Wayne.Brown@altec.com escribió:
> The current system works just fine for my needs.  I've never seen the point
> of trying to "improve" things that are already good enough.  But now that
> you've

A years ago, having a car engine of about 50 Cv/litre and all though it was the
best.

...now we have some engines like the bmw m3's 3.3 engine of about 103 Cv/litre,
or Honda S2000, 2.0, about 120 Cv/litre, Audi S3 1.8  turbo 122 cv/litre, audii
rs4 twin turbo about 140 cv/litre...

I think that evolution uses to be a good thing ;)

Diego Calleja

DiegoCG@teleline.es

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Wayne.Brown]

I'm not sure I understand what you're saying here.  Yes, the build system is
mostly the same across all these versions -- that's my point.  I want it to STAY
the same as long as possible.  What's the relationship between kbuild and the
size of the kernel source?  Are you saying a new build system would make the
kernel smaller?  Or do you mean that it would be faster, or would require
recompiling smaller portions of the kernel after patching?  That wouldn't help
me, because I'll never trust *any* build system -- even good ol' "make" itself
-- to make the right determination of what to recompile after applying one of
Linus's or Alan's patch sets.  I *always* "make mrproper" and recompile
*everything* after patching.  (Back in my Minix days I usually didn't stop with
recompiling the kernel, but recompiled everything -- libraries, user-space
programs like "cat" and "ls," etc. -- after applying patches.  Minix upgrades
frequently took me 10 hours or more on my 8088 system.)  As for speed, my
Pentium II laptop compiles 2.5.15 a lot faster than my old 486 desktop compiled
0.99pl13 (my first kernel).





Dave Jones <davej@suse.de> on 05/17/2002 03:09:22 PM

To:   Wayne Brown/Corporate/Altec@Altec
cc:   linux-kernel@vger.kernel.org

Subject:  Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3




Compare and contrast..

-rw-r--r--    1 davej    users     31426560 Jan  9  2001 linux-2.0.39.tar
-rw-r--r--    1 davej    users     85442560 Nov  6  2001 linux-2.2.20.tar
-rw-r--r--    1 davej    users    131727360 Feb 25 20:15 linux-2.4.18.tar
-rw-r--r--    1 davej    users    152524800 May 10 00:11 linux-2.5.15.tar

Spot the pattern? Exponential growth. not only that, but for the most
part, the build system is the same across all of these. If we continue
growing at the current rate without doing something about the build
process, we're all going to be needing 8-way Opterons with several
GB of memory to get any work done.

If kbuild2.5 is faster, and produces the same end result (or better
still, more accurate builds), there's no valid reason to ignore it
that I can see.

    Dave.
--
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Andrew Morton]

Wayne.Brown@altec.com wrote:
> 
> I'm not sure I understand what you're saying here.  Yes, the build system is
> mostly the same across all these versions -- that's my point.  I want it to STAY
> the same as long as possible.  What's the relationship between kbuild and the
> size of the kernel source?  Are you saying a new build system would make the
> kernel smaller?  Or do you mean that it would be faster, or would require
> recompiling smaller portions of the kernel after patching?  That wouldn't help
> me, because I'll never trust *any* build system -- even good ol' "make" itself
> -- to make the right determination of what to recompile after applying one of
> Linus's or Alan's patch sets.  I *always* "make mrproper" and recompile
> *everything* after patching.  (Back in my Minix days I usually didn't stop with
> recompiling the kernel, but recompiled everything -- libraries, user-space
> programs like "cat" and "ls," etc. -- after applying patches.  Minix upgrades
> frequently took me 10 hours or more on my 8088 system.)  As for speed, my
> Pentium II laptop compiles 2.5.15 a lot faster than my old 486 desktop compiled
> 0.99pl13 (my first kernel).
> 

That's you. On May 15 and May 16 I rebuilt the kernel over
150 times.

The deteriorating performance of gcc and the tendency of
the current build system to needlessly recompile stuff are
acute problems.  ccache saves me probably one hour per day.

-

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[William Lee Irwin III]

On Fri, May 17, 2002 at 02:14:38PM -0700, Andrew Morton wrote:
> That's you. On May 15 and May 16 I rebuilt the kernel over
> 150 times.

Nice build system.

On Fri, May 17, 2002 at 02:14:38PM -0700, Andrew Morton wrote:
> The deteriorating performance of gcc and the tendency of
> the current build system to needlessly recompile stuff are
> acute problems.  ccache saves me probably one hour per day.

A build on my laptop takes well over an hour. This is not useful
for actually getting things done. I'm all for mitigating build
time in such cases, by kbuild-2.5 and perhaps other methods.


Cheers,
Bill

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Kai Germaschewski]

On Fri, 17 May 2002, William Lee Irwin III wrote:

> On Fri, May 17, 2002 at 02:14:38PM -0700, Andrew Morton wrote:
> > The deteriorating performance of gcc and the tendency of
> > the current build system to needlessly recompile stuff are
> > acute problems.  ccache saves me probably one hour per day.
> 
> A build on my laptop takes well over an hour. This is not useful
> for actually getting things done. I'm all for mitigating build
> time in such cases, by kbuild-2.5 and perhaps other methods.

I suppose you want ccache then. kbuild-2.5 may save two minutes of your
one hour build. The current kbuild's problem is not that it recompiles too
many files, but rather too few sometimes (in particular with modversions).

(And yes, ccache won't work too well if you move your trees around, since 
*both* build systems use absolute paths. That needs fixing)

--Kai

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[William Lee Irwin III]

On Fri, 17 May 2002, William Lee Irwin III wrote:
>> A build on my laptop takes well over an hour. This is not useful
>> for actually getting things done. I'm all for mitigating build
>> time in such cases, by kbuild-2.5 and perhaps other methods.

On Fri, May 17, 2002 at 05:16:22PM -0500, Kai Germaschewski wrote:
> I suppose you want ccache then. kbuild-2.5 may save two minutes of your
> one hour build. The current kbuild's problem is not that it recompiles too
> many files, but rather too few sometimes (in particular with modversions).
> (And yes, ccache won't work too well if you move your trees around, since 
> *both* build systems use absolute paths. That needs fixing)

Hmm. That kind of blows. Well, someone else's problem (or is it?). I'll
take it for what it can do now and plod along.


Cheers,
Bill

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Larry McVoy]

On Fri, May 17, 2002 at 03:34:31PM -0700, William Lee Irwin III wrote:
> On Fri, May 17, 2002 at 05:16:22PM -0500, Kai Germaschewski wrote:
> > I suppose you want ccache then. kbuild-2.5 may save two minutes of your
> > one hour build. The current kbuild's problem is not that it recompiles too
> > many files, but rather too few sometimes (in particular with modversions).
> > (And yes, ccache won't work too well if you move your trees around, since 
> > *both* build systems use absolute paths. That needs fixing)
> 
> Hmm. That kind of blows. Well, someone else's problem (or is it?). I'll
> take it for what it can do now and plod along.

In the for what it is worth department, we like ccache here at BitMover and
converted the CVS tree to BK just for fun.

	http://ccache.bkbits.net

-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Oliver Xymoron]

On Fri, 17 May 2002, Kai Germaschewski wrote:

> On Fri, 17 May 2002, William Lee Irwin III wrote:
>
> > On Fri, May 17, 2002 at 02:14:38PM -0700, Andrew Morton wrote:
> > > The deteriorating performance of gcc and the tendency of
> > > the current build system to needlessly recompile stuff are
> > > acute problems.  ccache saves me probably one hour per day.
> >
> > A build on my laptop takes well over an hour. This is not useful
> > for actually getting things done. I'm all for mitigating build
> > time in such cases, by kbuild-2.5 and perhaps other methods.
>
> I suppose you want ccache then. kbuild-2.5 may save two minutes of your
> one hour build.

That's assuming you have to build from scratch. The whole point is to
reduce the need to do that by making dependencies more accurate.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Nicolas Pitre]

On Fri, 17 May 2002 Wayne.Brown@altec.com wrote:

> I'm not sure I understand what you're saying here.  Yes, the build system is
> mostly the same across all these versions -- that's my point.  I want it to STAY
> the same as long as possible.  What's the relationship between kbuild and the
> size of the kernel source?  Are you saying a new build system would make the
> kernel smaller?  Or do you mean that it would be faster, or would require
> recompiling smaller portions of the kernel after patching?  That wouldn't help
> me, because I'll never trust *any* build system -- even good ol' "make" itself
> -- to make the right determination of what to recompile after applying one of
> Linus's or Alan's patch sets.  I *always* "make mrproper" and recompile
> *everything* after patching.

But even if you recompile *everything* _everytime_, kbuild 2.5 is "faster".

What do you have against that?


Nicolas

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Oliver Xymoron]

On Fri, 17 May 2002 Wayne.Brown@altec.com wrote:

> That wouldn't help me, because I'll never trust *any* build system --
> even good ol' "make" itself -- to make the right determination of what
> to recompile after applying one of Linus's or Alan's patch sets.
> I *always* "make mrproper" and recompile *everything* after patching.

And the new kbuild will do that faster - what the problem again? For those
of us who actually trust the makefile concept, if not the current
makefiles, the new kbuild also happens to be designed to do the right
thing after a patch.

More importantly, it makes the make system manageable again.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Wayne.Brown]

Constructive comments would be appropriate if I wanted to help construct a new
kbuild.  The truth is that I'm quite happy with the current kbuild and don't
want it replaced with *anything* at all.  (That's the same reason I'm glad no
one's been talking about CML2 lately.)  The new one wouldn't bother me if the
user interface were *exactly* identical to the old one; i.e., if I could keep
typing exactly the same commands to build a kernel and get exactly the same
results and not be able to tell that anything had changed in the build process.

Personally, I wish that the only changes anybody made were to the kernel itself
(new drivers added, existing performance improved, etc.) and that all the
supporting tools and utilities just could be left alone.  I know that's not
going to happen, but anything that slows down changes in those extraneous things
is fine with me.  I'd be perfectly happy if *years* from now I was compiling
Linux 45.10.12 with the same kbuild, CML, gcc and everything else that I'm using
right now.





Adam Kropelin <akropel1@rochester.rr.com> on 05/17/2002 12:37:18 PM

To:   linux-kernel@vger.kernel.org
cc:    (bcc: Wayne Brown/Corporate/Altec)

Subject:  Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3



On Fri, May 17, 2002 at 09:21:12AM -0500, Wayne.Brown@altec.com wrote:
>
>
> OTOH, those of us who are not looking forward to kbuild 2.5 are grateful for
any
> delays we can get.

...and what would your beefs (beeves?) with kbuild-2.5 be? I searched the
archives
for the last 12 months and I don't see anythinng from you relevant to
kbuild-2.5.
Keith has been addressing concerns quite regularly; I should think if you have
constructive comments, he'd surely listen.

You *do* have constructive comments, right?

--Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Dave Jones]

On Fri, May 17, 2002 at 02:51:57PM -0500, Wayne.Brown@altec.com wrote:
 > Personally, I wish that the only changes anybody made were to the kernel itself
 > (new drivers added, existing performance improved, etc.) and that all the
 > supporting tools and utilities just could be left alone.  I know that's not
 > going to happen, but anything that slows down changes in those extraneous things
 > is fine with me.  I'd be perfectly happy if *years* from now I was compiling
 > Linux 45.10.12 with the same kbuild, CML, gcc and everything else that I'm using
 > right now.

Compare and contrast..

-rw-r--r--    1 davej    users     31426560 Jan  9  2001 linux-2.0.39.tar
-rw-r--r--    1 davej    users     85442560 Nov  6  2001 linux-2.2.20.tar
-rw-r--r--    1 davej    users    131727360 Feb 25 20:15 linux-2.4.18.tar
-rw-r--r--    1 davej    users    152524800 May 10 00:11 linux-2.5.15.tar

Spot the pattern? Exponential growth. not only that, but for the most
part, the build system is the same across all of these. If we continue
growing at the current rate without doing something about the build
process, we're all going to be needing 8-way Opterons with several
GB of memory to get any work done.

If kbuild2.5 is faster, and produces the same end result (or better
still, more accurate builds), there's no valid reason to ignore it
that I can see.

    Dave.
-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Diego Calleja]

On Fri, 17 May 2002 22:09:22 +0200
Dave Jones <davej@suse.de> escribió:

> Spot the pattern? Exponential growth. not only that, but for the most
> part, the build system is the same across all of these. If we continue
> growing at the current rate without doing something about the build
> process, we're all going to be needing 8-way Opterons with several
> GB of memory to get any work done.

Well. If a miracle doesn't happen, i'll have to start thinking how to buy a 8-way Opteron....
> 
> If kbuild2.5 is faster, and produces the same end result (or better
> still, more accurate builds), there's no valid reason to ignore it
> that I can see.
> 
>     Dave.
> -- 
> | Dave Jones.        http://www.codemonkey.org.uk
> | SuSE Labs
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Paul P Komkoff Jr]

Replying to Wayne.Brown@altec.com:
> Personally, I wish that the only changes anybody made were to the kernel itself
> (new drivers added, existing performance improved, etc.) and that all the
> supporting tools and utilities just could be left alone.  I know that's not
> going to happen, but anything that slows down changes in those extraneous things
> is fine with me.  I'd be perfectly happy if *years* from now I was compiling
> Linux 45.10.12 with the same kbuild, CML, gcc and everything else that I'm using
> right now.

It seems like you stuck with existing toys forever, which can somewhat
indicate that your learning factor is extremely low

History knows many applications of such behavior. In short, it stops
improvements and breaks progress. And in a few words more, you can now
compile linux 2.2.(something) with egcs (something), and you will be able to
live in underground cave with stoneage tools *years* from now too.

-- 
Paul P 'Stingray' Komkoff 'Greatest' Jr // (icq)23200764 // (irc)Spacebar
  PPKJ1-RIPE // (smtp)i@stingr.net // (http)stingr.net // (pgp)0xA4B4ECA4

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[James Bottomley]

> Along the same lines, we have James Bottomly attempting to  get
> support for the NCR Voyager architecture added to the kernel.  His
> original submission post was sent 2001-12-23: http://
> marc.theaimsgroup.com/?l=linux-kernel&m=100913508007485&w=2 The latest
> submission attempt was sent 2002-05-11: http://marc.theaimsgroup.com/
> ?l=linux-kernel&m=102115570805131&w=2

> It seems to me that adding a new architecture probably doesn't impact
> the rest of the kernel much, so I am not sure way  acceptance would be
> so long delayed.  I have noticed that  there has been minimal feedback
> to James, which he appears to have responded to quickly and well.  I
> tend to think that any tweaks needed could be accomplished as easily
> once the code has been accepted into the kernel tree.

> Is there some justification for the delay that I have somehow
> overlooked?

Actually, the major criticism was that a new architecture can't be wedged into 
the arch/i386 directory without changing an awful lot of critical files, which 
is true (and also undesirable from a QA standpoint).

I addressed that by doing the i386 subarchitecture rework (which allows me to 
slide all the voyager stuff in to the side). However, that still does a 
hatchet job on arch/i386.  There are also several other people working on 
related issues in arch/i386, so it has become a slow job.  The current status 
is

- PCI rework - In Linus Kernel
- setup/cpu rework - in DJ kernel

I get to wait until the setup/cpu rework makes it to the Linus kernel so I can 
slot in the arch subdivisions around it.

James

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Wayne.Brown]

OTOH, those of us who are not looking forward to kbuild 2.5 are grateful for any
delays we can get.





Tomas Szepe <szepe@pinerecords.com> on 05/16/2002 10:30:56 PM

To:   Linus Torvalds <torvalds@transmeta.com>
cc:   linux-kernel@vger.kernel.org (bcc: Wayne Brown/Corporate/Altec)

Subject:  Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3



> > Third and final attempt.  Original sent on May 2, second mail sent on
> > May 14, still no response from Linus.
>
> Linus is a bastard.  Did you forget?

This is getting ridiculous all right.

Linus, what makes you ignore Keith's work?

Would you tend to think he's worked on kbuild25 this long
to end up having to send a linus-dammit-would-you-have-
-a-look-at-last-i'm-not-going-to-keep-asking-forever msg?

Sorry for a slightly offensive post; I can't stand to
see such impoliteness.

T.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Adam Kropelin]

On Fri, May 17, 2002 at 09:21:12AM -0500, Wayne.Brown@altec.com wrote:
> 
> 
> OTOH, those of us who are not looking forward to kbuild 2.5 are grateful for any
> delays we can get.

...and what would your beefs (beeves?) with kbuild-2.5 be? I searched the archives
for the last 12 months and I don't see anythinng from you relevant to kbuild-2.5.
Keith has been addressing concerns quite regularly; I should think if you have
constructive comments, he'd surely listen. 

You *do* have constructive comments, right?

--Adam

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Robert Love]

On Fri, 2002-05-17 at 10:37, Adam Kropelin wrote:

> On Fri, May 17, 2002 at 09:21:12AM -0500, Wayne.Brown@altec.com wrote:
> > 
> > OTOH, those of us who are not looking forward to kbuild 2.5 are grateful
> > for any delays we can get.
> 
> ...and what would your beefs (beeves?) with kbuild-2.5 be? I searched the
> archives for the last 12 months and I don't see anythinng from you
> relevant to kbuild-2.5. Keith has been addressing concerns quite regularly;
> I should think if you have constructive comments, he'd surely listen. 

I have not seen much complaints over kbuild-2.5, and what I have seen
(i.e. it was slower) Keith has done a very good job of addressing (i.e.
now it is faster).  Whatever items come up in the future, I suspect
Keith is committed to fixing.  Right now, however, it is certainly hard
for him to maintain kbuild-2.5 against a moving kernel tree and work on
new features.  Keith knows I will stop sending him Christmas cards if
kbuild-2.5 was merged and he did not follow up on issues - I suspect
that will not happen. :)

Fwiw, I like kbuild-2.5 and want it in.

> You *do* have constructive comments, right?

Probably not.  Like most of the noise on lkml these days, non-developers
seem to have an opinion on everything yet offer little value.  Code
talks and ...

	Robert Love

kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Keith Owens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

Third and final attempt.  Original sent on May 2, second mail sent on
May 14, still no response from Linus.

Linus, kbuild 2.5 is ready for inclusion in the main 2.5 kernel tree.
It is faster, better documented, easier to write build rules in, has
better install facilities, allows separate source and object trees, can
do concurrent builds from the same source tree and is significantly
more accurate than the existing kernel build system.

The current state is

  kbuild-2.5-core-14		Fits any 2.4 and 2.5 kernel.
  kbuild-2.5-common-2.5.15-4	2.5.15 arch independent files.

There are several arch dependent files for 2.5.15 or earlier kernels.

  kbuild-2.5-i386-2.5.15-2
  kbuild-2.5-sparc64-2.5.15-1
  kbuild-2.5-s390-2.5.15-1
  kbuild-2.5-s390x-2.5.15-1
  kbuild-2.5-ppc-2.5.14-1
  kbuild-2.5-sh-2.5.12-1 (also fits 2.5.13)
  kbuild-2.5-ia64-2.5.10-020426-1 (last Mosberger patch)

That covers most of the architectures that currently build on 2.5.


This version has only been tested on CML1.  kbuild 2.5 has support for
an older version of CML2 but it has not been tested on newer versions
of CML2.

Before I send you the kbuild 2.5 patch, how do you want to handle it?

* Coexist with the existing kernel build for one or two releases or
  delete the old build system when kbuild 2.5 goes in?

  Coexistence for a few days gives a backout, just in case.  It also
  gives a kernel release where the old and new code can be compared,
  useful for architectures that have not been converted yet.

  Deleting the old system at the same time means that unconverted
  architectures cannot build.  OTOH many architectures are already
  broken in the 2.5 kernel.

* I need a quiet period of 24-48 hours (no changes at all) after a new
  kernel release to bring kbuild 2.5 up to the latest release, before
  sending you the complete patch.  Which kernel release do you want
  kbuild 2.5 against?

I would like kbuild 2.5 to go in in the near future.  Keeping up to
date with kernel changes is a significant effort, Makefiles change all
the time, especially when major subsystems like sound and usb are
reorganised.  There are also some changes to architecture code to do it
right under kbuild 2.5 and tracking those against kernel changes can be
painful.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999

iD8DBQE85DXKi4UHNye0ZOoRAsRyAJwP52HqsmJhZKNIiJKQUScLjD/cOgCffzTc
Uj1qHkvIszUfOYQtInekCYY=
=sxcO
-----END PGP SIGNATURE-----

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Nicolas Pitre]

On Fri, 17 May 2002, Keith Owens wrote:

> Third and final attempt.  Original sent on May 2, second mail sent on
> May 14, still no response from Linus.

Linus is a bastard.  Did you forget?


Nicolas

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Tomas Szepe]

> > Third and final attempt.  Original sent on May 2, second mail sent on
> > May 14, still no response from Linus.
> 
> Linus is a bastard.  Did you forget?

This is getting ridiculous all right.

Linus, what makes you ignore Keith's work?

Would you tend to think he's worked on kbuild25 this long
to end up having to send a linus-dammit-would-you-have-
-a-look-at-last-i'm-not-going-to-keep-asking-forever msg?

Sorry for a slightly offensive post; I can't stand to
see such impoliteness.

T.

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Russell King]

On Fri, May 17, 2002 at 05:30:56AM +0200, Tomas Szepe wrote:
> Linus, what makes you ignore Keith's work?

I'm not going to answer for Linus, except to say that Linus is taking
patches to fix and improve the existing kbuild in 2.5.

Maybe the right thing to do is to let Linus and others try to fix the
existing kbuild, and when/if it doesn't work we have something that
does work.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Miles Lane]

On Thu, 2002-05-16 at 20:30, Tomas Szepe wrote:
> > > Third and final attempt.  Original sent on May 2, second mail sent on
> > > May 14, still no response from Linus.
> > 
> > Linus is a bastard.  Did you forget?
> 
> This is getting ridiculous all right.
> 
> Linus, what makes you ignore Keith's work?
> 
> Would you tend to think he's worked on kbuild25 this long
> to end up having to send a linus-dammit-would-you-have-
> -a-look-at-last-i'm-not-going-to-keep-asking-forever msg?
> 
> Sorry for a slightly offensive post; I can't stand to
> see such impoliteness.

Along the same lines, we have James Bottomly attempting to 
get support for the NCR Voyager architecture added to the
kernel.  His original submission post was sent 2001-12-23:
http://marc.theaimsgroup.com/?l=linux-kernel&m=100913508007485&w=2
The latest submission attempt was sent 2002-05-11:
http://marc.theaimsgroup.com/?l=linux-kernel&m=102115570805131&w=2

It seems to me that adding a new architecture probably doesn't
impact the rest of the kernel much, so I am not sure way 
acceptance would be so long delayed.  I have noticed that 
there has been minimal feedback to James, which he appears
to have responded to quickly and well.  I tend to think
that any tweaks needed could be accomplished as easily once
the code has been accepted into the kernel tree.

Is there some justification for the delay that I have somehow
overlooked?

	Miles

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Dave Jones]

On Fri, May 17, 2002 at 01:42:44AM -0700, Miles Lane wrote:
 > Along the same lines, we have James Bottomly attempting to 
 > get support for the NCR Voyager architecture added to the
 > kernel.  His original submission post was sent 2001-12-23:
 > http://marc.theaimsgroup.com/?l=linux-kernel&m=100913508007485&w=2
 > The latest submission attempt was sent 2002-05-11:
 > http://marc.theaimsgroup.com/?l=linux-kernel&m=102115570805131&w=2

The best solution for niche x86 architectures is to get x86-subarch
support merged first (See how arch/arm is laid out for an example)
James also has patches to do this, but there are a few other bits
pending in this area right now, such as Patrick Mochels work to split
up some of the larger parts. The bigger chunk of this is in my tree,
and has proven to be ok, so I'm pushing that to Linus sometime real
soon.

With that out of the way, the only remaining work in that area
is of small enough scale (apart from ACPI perhaps) that merging
the subarch support should be a logical progression.
And with that merged, things like Voyager, NUMAQ, and other weirdo
x86en can follow on without disrupting any of the common x86 code
that 99.9% of people will be running.

So it's not being ignored, it's just that trying to fit together
a puzzle whilst all the players want to put a piece in the same
place needs an element of coordination.

    Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Denis Vlasenko]

On 17 May 2002 01:30, Tomas Szepe wrote:
> > > Third and final attempt.  Original sent on May 2, second mail sent on
> > > May 14, still no response from Linus.
> >
> > Linus is a bastard.  Did you forget?
>
> This is getting ridiculous all right.
> Linus, what makes you ignore Keith's work?
>
> Would you tend to think he's worked on kbuild25 this long
> to end up having to send a linus-dammit-would-you-have-
> -a-look-at-last-i'm-not-going-to-keep-asking-forever msg?

People sometimes ignore your messages repeatedly, right? 
And Linus is _human too_. Why _demand_ him to answer?

But we can _ask nicely_. :-) I'd put it this way:

Hi Linus!

I want to inform you that lots of folks here
would like to know what do you think about kbuild25:
* "I'll merge it soon"  or
* "I'll merge it later, not now"  or
* "I won't merge it because ....."  or
* other?
--
vda

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Tomas Szepe]

> > > > Third and final attempt.  Original sent on May 2, second mail sent on
> > > > May 14, still no response from Linus.
> > >
> > > Linus is a bastard.  Did you forget?
> >
> > This is getting ridiculous all right.
> > Linus, what makes you ignore Keith's work?
> >
> > Would you tend to think he's worked on kbuild25 this long
> > to end up having to send a linus-dammit-would-you-have-
> > -a-look-at-last-i'm-not-going-to-keep-asking-forever msg?
> 
> People sometimes ignore your messages repeatedly, right? 

That's very difficult to find out, you see. :)

> And Linus is _human too_. Why _demand_ him to answer?
> But we can _ask nicely_. :-) I'd put it this way:

I believe Keith did precisely that three times already.

> I want to inform you that lots of folks here
> would like to know what do you think about kbuild25:
> * "I'll merge it soon"  or
> * "I'll merge it later, not now"  or
> * "I won't merge it because ....."  or
> * other?

Reminds me of the form Bender filled in in "the 30% Iron Chef."
If you've seen that episode. (Only it had the "[ ] and this time
I mean it" checkbox as its last entry.)


T.

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Denis Vlasenko]

On 17 May 2002 06:17, Tomas Szepe wrote:
> > And Linus is _human too_. Why _demand_ him to answer?
> > But we can _ask nicely_. :-) I'd put it this way:
>
> I believe Keith did precisely that three times already.

One can ask Linus to do something as many times as one wants.
Linus, just like everyone else, may ignore such requests.

You may not like it, but you have to live with it.

It's not about Linus, it's about freedom.
You'd like to be free, right? Then allow others to be free,
even to be free to ignore you. :-)
--
vda

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[jeff millar]

Keith...

will any of the other kernels (dj, ml, ???) incorporate your system?

I'm about ready to try something else.

jeff
----- Original Message ----- 
From: "Keith Owens" <kaos@ocs.com.au>
To: <linux-kernel@vger.kernel.org>
Cc: <torvalds@transmeta.com>
Sent: Thursday, May 16, 2002 6:42 PM
Subject: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Content-Type: text/plain; charset=us-ascii
> 
> Third and final attempt.  Original sent on May 2, second mail sent on
> May 14, still no response from Linus.

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Keith Owens]

On Thu, 16 May 2002 21:50:46 -0400, 
"jeff millar" <wa1hco@adelphia.net> wrote:
>will any of the other kernels (dj, ml, ???) incorporate your system?

Once Linus takes the patch, everybody else will follow.

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Dave Jones]

On Thu, May 16, 2002 at 09:50:46PM -0400, jeff millar wrote:
 > will any of the other kernels (dj, ml, ???) incorporate your system?
 > I'm about ready to try something else.

I've thought it over a few times over the last few weeks, and tbh
inclusion in any tree other than Linus' doesn't really make much sense
other than perhaps to get some more 'early adopter' testers.

The current kbuild2.5 patches will apply cleanly against my tree, but
due to things like the new input layer still not being completely merged
in Linus' tree, some files are in different places, so the Makefile.in's
in kbuild2.5 point to the wrong places.

Sure, I could merge it, but tbh it's not worth the effort right now
of fixing up those files until Linus actually says yay or nay.

    Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Kenneth Johansson]

On Fri, 2002-05-17 at 00:42, Keith Owens wrote:

> Before I send you the kbuild 2.5 patch, how do you want to handle it?

Why do you not just make a patch the way that makes most sens to you and
sent it to him. 

If you asked me I think it's working so good that you can just rip out
the old one. 


Ps. The only strange thing left that I could find was that I could not
skip the makefile gen when I only wanted to run a config front.

make NO_MAKEFILE_GEN=1 xconfig

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Nicolas Pitre]

On 17 May 2002, Kenneth Johansson wrote:

> On Fri, 2002-05-17 at 00:42, Keith Owens wrote:
> 
> > Before I send you the kbuild 2.5 patch, how do you want to handle it?
> 
> Why do you not just make a patch the way that makes most sens to you and
> sent it to him. 

I suggested exactly that to Keith.  but he, too, apparently decided to
exercise his freedom to ignore me.


Nicolas

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Tomas Szepe]

> > > Before I send you the kbuild 2.5 patch, how do you want to handle it?
> > 
> > Why do you not just make a patch the way that makes most sens to you and
> > sent it to him. 
> 
> I suggested exactly that to Keith.  but he, too, apparently decided to
> exercise his freedom to ignore me.

I can't see any point in sending a patch w/o first negotiating
its acceptance. After all, it can be ignored just like anything
else that comes in thru TCP port 25.

t.


-- 
"when you do things right, people won't be sure you've done anything at all."
- god to bender

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Nicolas Pitre]

On Fri, 17 May 2002, Tomas Szepe wrote:

> > > > Before I send you the kbuild 2.5 patch, how do you want to handle it?
> > > 
> > > Why do you not just make a patch the way that makes most sens to you and
> > > sent it to him. 
> > 
> > I suggested exactly that to Keith.  but he, too, apparently decided to
> > exercise his freedom to ignore me.
> 
> I can't see any point in sending a patch w/o first negotiating
> its acceptance.

If that is not what Keith tried to do for the third time please tell me what 
it is.

> After all, it can be ignored just like anything else that comes in thru
> TCP port 25.

Of course.

Keith gets ignored.  He receives suggestions for alternative ways which he 
ignores too.  I therefore intend to ignore his work as well.

Wonderful!


Nicolas

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Keith Owens]

On Fri, 17 May 2002 11:42:26 -0400 (EDT), 
Nicolas Pitre <nico@cam.org> wrote:
>Keith gets ignored.  He receives suggestions for alternative ways which he 
>ignores too.  I therefore intend to ignore his work as well.

I ignore stupid comments, yours falls into that category.  I have good
reason for asking for Linus's OPINION before sending the patch.  Note I
am not asking Linus to take the patch right now, I am asking for some
guidance.  Unless you have something useful to contribute, I will
continue to ignore you.

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Nicolas Pitre]

On Sat, 18 May 2002, Keith Owens wrote:

> On Fri, 17 May 2002 11:42:26 -0400 (EDT), 
> Nicolas Pitre <nico@cam.org> wrote:
> >Keith gets ignored.  He receives suggestions for alternative ways which he 
> >ignores too.  I therefore intend to ignore his work as well.
> 
> I ignore stupid comments, yours falls into that category.  I have good
> reason for asking for Linus's OPINION before sending the patch.  Note I
> am not asking Linus to take the patch right now, I am asking for some
> guidance.  Unless you have something useful to contribute, I will
> continue to ignore you.

Well the above was a stupid comment made on purpose to cynically depict the
current situation.  But this answer from you just shows that you don't
necessarily ignore stupid comments...

It just looks like you are failing to obtain guidance from Linus so _maybe_
submiting multiple small patches that can be reviewed from within a mailer
might be easier for someone who already stated his preferences for that
matter.

No offense intended. Really.


Nicolas

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Keith Owens]

On Fri, 17 May 2002 22:11:10 -0400 (EDT), 
Nicolas Pitre <nico@cam.org> wrote:
>It just looks like you are failing to obtain guidance from Linus so _maybe_
>submiting multiple small patches that can be reviewed from within a mailer
>might be easier for someone who already stated his preferences for that
>matter.

You still don't get it.  Read my mail.

 "Before I send you the kbuild 2.5 patch, how do you want to handle it?".
 
I am seeking Linus opinion on the next step, not sending the patch yet.

--

Those that can, do.  Those that can't, troll on linux-kernel.

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Diego Calleja]

On Fri, 17 May 2002 08:42:18 +1000
Keith Owens <kaos@ocs.com.au> escribió:


So we have a good patch that can make life better for developers and users.

Not to apply it is a *bad* decision. Linus, soon or later, you'll have to
replace the existing kbuild and you know that (it seems you're taking patches about it).

You must have some conflict with Keith, but i don't care about it. So,
if you have to replace the existing kbuild, why re-do it if it's done yet?.

<my suggestions, this doesn't means it's right>

Linus, please tell Keith that he changes kbuild just as you wants, and now. linux
is yours, and you've the right to take this kid of decisions. Leaders are for that.

And Keith, just try to do kbuild just like Linus wants. We'll help you, too. 

But please, we're not to be fools and re-do all the work again. kbuild 2.5 _is_ good
and all of us know that. So, please, please....don't let me think we're being so idiot....



Diego calleja
DiegoCG@teleline.es

Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 3

[Pavel Machek]

Hi!

> Third and final attempt.  Original sent on May 2, second mail sent on
> May 14, still no response from Linus.

In some unrelated thread (something about fixing "BUG()" macro) he
said he'd want it merged in pieces.
									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