From: Ingo Molnar <mingo@elte.hu>
To: Andreas Schwab <schwab@redhat.com>
Cc: Pekka Enberg <penberg@kernel.org>,
Jan Beulich <JBeulich@novell.com>,
"H.J. Lu" <hjl.tools@gmail.com>,
binutils@sourceware.org, linux-kernel@vger.kernel.org,
"H. Peter Anvin" <hpa@zytor.com>, Alan Modra <amodra@gmail.com>
Subject: Re: PATCH: Add --size-check=[error|warning]
Date: Mon, 14 Mar 2011 14:17:29 +0100 [thread overview]
Message-ID: <20110314131729.GB28851@elte.hu> (raw)
In-Reply-To: <m3bp1dvp3l.fsf@redhat.com>
* Andreas Schwab <schwab@redhat.com> wrote:
> Ingo Molnar <mingo@elte.hu> writes:
>
> > * Andreas Schwab <schwab@redhat.com> wrote:
> >
> >> Pekka Enberg <penberg@kernel.org> writes:
> >>
> >> > Hi Andreas,
> >> >
> >> > Pekka Enberg <penberg@kernel.org> writes:
> >> >>> So what do you suggest that testers who want to, say, build old Linux
> >> >>> kernel versions with new binutils do?
> >> >
> >> > On Mon, Mar 14, 2011 at 1:02 PM, Andreas Schwab <schwab@redhat.com> wrote:
> >> >> The same that testers have to do in order to build old Linux kernel
> >> >> versions with current versions of make.
> >> >
> >> > Are you saying it's OK to screw over binutils users because GNU Make
> >> > did that too?
> >>
> >> I'm just telling you the facts.
> >
> > And you are wrong - latest Make does not break reasonably old kernel builds such
> > as v2.6.30.
>
> This is just ridiculous.
> You are defining away facts just because they don't fit your view.
No, i actually tried out the latest released Make version (3.82) and it still builds
v2.6.30 fine:
LD arch/x86/boot/setup.elf
OBJCOPY arch/x86/boot/setup.bin
BUILD arch/x86/boot/bzImage
Root device is (8, 1)
Setup is 12364 bytes (padded to 12800 bytes).
System is 3730 kB
CRC 77bb7f2d
Kernel: arch/x86/boot/bzImage is ready (#105830)
The kernel build count is at 105830 because i build and test a lot of kernels on
this box.
And the resulting kernel boots fine on a testbox:
mercury:~> uname -a
Linux mercury 2.6.30 #105830 SMP Mon Mar 14 12:29:06 CET 2011 x86_64 x86_64 x86_64 GNU/Linux
I have built and booted over half a million Linux kernels in the past 3-4 years so i
generally have quite a bit of experience when it comes to build environment bugs and
workflow problems. Breaking the build retroactively and unnecessarily like here is
one of the worst things that can be done to testing quality and efficiency.
Thanks,
Ingo
next prev parent reply other threads:[~2011-03-14 13:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20110311165802.GA3508@intel.com>
[not found] ` <4D7A64670200007800035F4C@vpn.id2.novell.com>
[not found] ` <AANLkTikG8wa1Em0bEUddbYpYs2TzFFTDb95qWFJ3xSbv@mail.gmail.com>
[not found] ` <4D7DE39302000078000362E6@vpn.id2.novell.com>
2011-03-14 9:55 ` Ingo Molnar
2011-03-14 10:41 ` Alan Modra
2011-03-14 10:50 ` Pekka Enberg
2011-03-14 18:03 ` Alan Cox
2011-03-14 10:52 ` Jan Beulich
[not found] ` <AANLkTi=3AiLaw5Gnis8Ha4eRXirk0s-Cnk2zzN12YDpH__45869.1711457961$1300099861$gmane$org@mail.gmail.com>
2011-03-14 11:02 ` Andreas Schwab
2011-03-14 11:12 ` Pekka Enberg
2011-03-14 12:02 ` Andreas Schwab
2011-03-14 12:13 ` Ingo Molnar
2011-03-14 12:55 ` Andreas Schwab
2011-03-14 13:17 ` Ingo Molnar [this message]
2011-03-14 13:43 ` Andreas Schwab
2011-03-14 12:10 ` Ingo Molnar
2011-03-14 12:23 ` Ingo Molnar
2011-03-14 12:25 ` Ingo Molnar
2011-03-14 13:16 ` git bisect plus fixes (was: PATCH: Add --size-check=[error|warning]) Ralf Wildenhues
2011-03-14 11:02 PATCH: Add --size-check=[error|warning] Sedat Dilek
2011-03-14 11:26 ` Jan Beulich
2011-03-14 11:35 ` Ingo Molnar
2011-03-14 11:38 ` Sedat Dilek
2011-03-14 11:52 ` Sedat Dilek
2011-03-14 12:21 ` Jan Beulich
2011-03-14 12:38 ` Sedat Dilek
2011-03-14 12:51 ` Sedat Dilek
2011-03-14 15:56 ` Ian Lance Taylor
2011-03-14 18:01 ` H. Peter Anvin
2011-03-14 16:32 ` H. Peter Anvin
2011-03-14 19:24 ` Steven Rostedt
2011-03-14 19:58 ` Linus Torvalds
2011-03-14 12:56 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110314131729.GB28851@elte.hu \
--to=mingo@elte.hu \
--cc=JBeulich@novell.com \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@kernel.org \
--cc=schwab@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®