From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Tony Breeds <tony@bakeyournoodle.com>,
linux-kernel@vger.kernel.org, dank@kegel.com
Subject: Re: [PATCH 00/11] jump label v7
Date: Wed, 28 Apr 2010 10:09:02 -0400 [thread overview]
Message-ID: <20100428140902.GB4662@Krystal> (raw)
In-Reply-To: <20100428020819.GN12389@ozlabs.org>
* Tony Breeds (tony@bakeyournoodle.com) wrote:
> On Tue, Apr 27, 2010 at 09:49:41PM -0400, Mathieu Desnoyers wrote:
>
> > The crosstool package from Dan Kegel did a good job for this. Not sure
> > it's currently maintained though. It was a very useful project, it's a
> > shame if it does not live on. It would be good to have up-to-date and
> > tested compilers for various architectures available on kernel.org,
> > ideally with access to a package that helps building compilers for
> > various architectures.
>
> Trimmed the CC' as this is a bit of a tangent.
>
> Crosstool did a good job but seems to be less current than we'd like for the
> kernel[1].
Ouch. The build failure ratio is surprisingly high.
> When using crosstool in the past I found a lot of the complexity
> was in *libc to the toolcahins I've built don';t have a libc so they're only
> helpful for kernel (or similar) builds.
So maybe we could do something more specialized for kernel needs, e.g. a
kcrosstool ? It could be a "simplified" crosstool.
Personally, I built a set of cross-compilers with crosstool 0.43 a while
ago, but must now do a lot of trial and error to find new correct compiler
and toolchain versions for each architecture. It would be good to have a
kcrosstool git repository that would:
- Have scripts and documentation specialized for Linux kernel build.
- Contain an updated list of "working" and "non-working" toolchain
versions for each arch.
- Could be easily updated; people would just have to report
success/failure of their config so these could be added to the git
repository. The build could probably prepare a report automatically to
lessen the reporter job (I'm even thinking about a scheme that would
give the option to report automatically).
- Optionally contain documentation on how to set up a cron job to
automatically fetch a git tree and do a distributed multi-architecture
build each day.
I think have this kind of updated tool would be of great value for
testing.
Thanks,
Mathieu
>
> In terms of "testing", I build a kernel for each toolchain but I don't boot
> them and in the past I think blackfin said that what I had wouldn't actually be
> runable. Last time I looked the wasn't a non-intel cross-toolchain for blackfin.
>
> I shoudl also mention that a subset of these compilers are used to build test
> linux-next daily.
>
> Yours Tony
>
> [1] http://www.kegel.com/crosstool/crosstool-0.43/buildlogs/
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2010-04-28 14:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-16 15:24 [PATCH 00/11] jump label v7 Jason Baron
2010-04-16 15:24 ` [PATCH 01/11] jump label: notifier atomic call chain notrace Jason Baron
2010-04-16 15:24 ` [PATCH 02/11] jump label: base patch Jason Baron
2010-04-16 15:24 ` [PATCH 03/11] jump label: x86 support Jason Baron
2010-04-16 15:24 ` [PATCH 04/11] jump label: tracepoint support Jason Baron
2010-04-16 15:24 ` [PATCH 05/11] jump label: add module support Jason Baron
2010-04-16 15:24 ` [PATCH 06/11] jump label: move ftrace_dyn_arch_init to common code Jason Baron
2010-04-16 15:24 ` [PATCH 07/11] jump label: sort jump table at build-time Jason Baron
2010-04-16 15:24 ` [PATCH 08/11] jump label: initialize workqueue tracepoints *before* they are registered Jason Baron
2010-04-16 15:24 ` [PATCH 09/11] jump label: jump_label_text_reserved() to reserve our jump points Jason Baron
2010-04-16 15:24 ` [PATCH 10/11] sparc64: Add jump_label support Jason Baron
2010-04-16 15:25 ` [PATCH 11/11] jump label: add docs Jason Baron
2010-04-22 23:17 ` [PATCH 00/11] jump label v7 David Miller
2010-04-28 0:58 ` David Miller
2010-04-28 1:39 ` Tony Breeds
2010-04-28 1:49 ` Mathieu Desnoyers
2010-04-28 2:08 ` Tony Breeds
2010-04-28 2:13 ` Mike Frysinger
2010-04-28 14:09 ` Mathieu Desnoyers [this message]
2010-04-28 21:53 ` H. Peter Anvin
2010-04-29 18:15 ` Jason Baron
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=20100428140902.GB4662@Krystal \
--to=mathieu.desnoyers@efficios.com \
--cc=dank@kegel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tony@bakeyournoodle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.