All of lore.kernel.org
 help / color / mirror / Atom feed
From: Khem Raj <raj.khem@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: introducing a new architecture/machine; policy ? (and a question)
Date: Wed, 23 Jun 2010 10:19:33 -0700	[thread overview]
Message-ID: <20100623171933.GB5535@gmail.com> (raw)
In-Reply-To: <AANLkTilv_BG9-Ksq5-fraEY4edmdFhfKTIgM-B2Gojq1@mail.gmail.com>

On (23/06/10 13:16), Frans Meulenbroeks wrote:
> 2010/6/23 Koen Kooi <k.kooi@student.utwente.nl>:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 23-06-10 12:07, Philip Balister wrote:
> >> On 06/23/2010 12:03 PM, Graeme Gregory wrote:
> >>> On Wed, 23 Jun 2010 11:54:21 +0200
> >>> Frans Meulenbroeks<fransmeulenbroeks@gmail.com>  wrote:
> >>>
> >>>> 2010/6/23 Graeme Gregory<dp@xora.org.uk>:
> >>>>>>>> Also I don't feel empowered to make changes in distribution
> >>>>>>>> specific files.
> >>>>>
> >>>>> Why not, chances are Angstrom maintainers would be quite happy for
> >>>>> you to patch angstrom*.conf if you ask us.
> >>>>>
> >>>>> Graeme
> >>>>
> >>>> distribution != angstrom
> >>>> There are more distributions out there.
> >>
> >> Right now, toolchain selection is done in distro files not machine
> >> files. I agree this is not the clearest approach, however adding the
> >> toolchain selection to the machine files may have unexpected side effects.
> >
> > Think of multimachine builds. What happens when someone else adds
> > *another* nios2 based machine with different toolchain versions, how do
> > I know which toolchain avahi_1.0_nios2.ipk was compiled with
> 
> If toolchain is interesting to know in ipk's it should be part of the name.
> And note that I am really in favour of an architecture specific
> solution, not a machine one.
> That is why I used an include file to contain the pinnings.
> 
> And actually the situation with nios2 is much much worse.
> As it is a soft-core people can come up with all kind of variants.
> (e.g. with/without fp). 

not new. Other arches have similar variants already in OE


> Actually nios2 adds pragma's to gcc to select
> which instructions are there and which not.

Well I would have preferred commandline options that way you could
have many variants and we could have overrides like we have arm sub-arches


> Not sure whether the latter is a good idea as it is one of the things
> that fail moving to a newer gcc.
> 
> The good news is that most of the variants used have different
> peripherals, but seem to stick to just a few cpu cores.
> (nios2 is used as a generic name for the SoC as well as the core,
> doesn't help to separate things either).
> 
> Frans
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel



  reply	other threads:[~2010-06-23 17:23 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-20  9:58 introducing a new architecture/machine; policy ? (and a question) Frans Meulenbroeks
2010-06-20 10:10 ` Frans Meulenbroeks
2010-06-20 12:35 ` Koen Kooi
2010-06-20 15:38   ` Frans Meulenbroeks
2010-06-23  8:53     ` Frans Meulenbroeks
2010-06-23  9:24       ` Koen Kooi
2010-06-23  9:36         ` Graeme Gregory
2010-06-23  9:54           ` Frans Meulenbroeks
2010-06-23 10:03             ` Graeme Gregory
2010-06-23 10:07               ` Philip Balister
2010-06-23 10:32                 ` Koen Kooi
2010-06-23 11:16                   ` Frans Meulenbroeks
2010-06-23 17:19                     ` Khem Raj [this message]
2010-06-23 19:55                       ` Frans Meulenbroeks
2010-06-23 22:20                         ` Khem Raj
2010-06-23 17:15             ` Khem Raj
2010-06-23 17:18               ` Tom Rini
2010-06-23 10:09         ` Frans Meulenbroeks
2010-06-23 10:30           ` Koen Kooi
2010-06-23 17:23           ` Khem Raj
2010-06-23 20:04             ` Frans Meulenbroeks
2010-06-23 21:55               ` Adrian Alonso
2010-06-23 22:16                 ` Khem Raj
2010-06-23 22:26               ` Khem Raj
2010-06-24  9:27               ` Koen Kooi
2010-06-24 11:23                 ` Frans Meulenbroeks
2010-06-24 15:10                   ` Khem Raj
2010-06-20 22:59 ` Khem Raj

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=20100623171933.GB5535@gmail.com \
    --to=raj.khem@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /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.