All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.