From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Darren Hart <dvhart@linux.intel.com>
Cc: yocto@yoctoproject.org
Subject: Re: More useful generic-x86 machine
Date: Wed, 13 Jun 2012 17:09:17 -0400 [thread overview]
Message-ID: <4FD9017D.6050805@windriver.com> (raw)
In-Reply-To: <4FD8FF5D.5060205@linux.intel.com>
On 12-06-13 05:00 PM, Darren Hart wrote:
>
>
> On 06/13/2012 01:55 PM, Bruce Ashfield wrote:
>> On 12-06-13 04:52 PM, Ross Burton wrote:
>>> On Wednesday, 13 June 2012 at 21:47, Darren Hart wrote:
>>>> Seems reasonable to me. We should probably have 32b and 64b of this
>>>> machine as well.
>>>
>>> And x32… :)
>>
>> From the kernel point of view, these are just configuration extensions
>> to a base, which is where this discussion started (the kernel, I'm
>> excluding userspace on purpose). So this should be one machine with
>> these as overlays, not three different machines.
>
> I would have thought the three different architectures would have called
> for three different machines. How would this work from the KMACHINE
> meta-data perspective?
I've had dual endian machines for ages for MIPS. This is no
different. You use a common machine, and then just trigger fragments
that change the few options that are different like endianess, etc.
So there's a single KMACHINE definition with additions.
Granted, this was more important when there was a strict 1:1 branch ->
machine mapping. But it still makes sense to keep things as small
as possible. We can do the same thing with three KMACHINE definitions
that include a common base, and that's nominally three machines, but
the slippery slope is that they start to diverge .. since they are
described by three different top level options.
I'm splitting a hair, I just wanted to point out that I wouldn't
call word size, endianess or other ABI differences big differences
in a machine definition.
Cheers,
Bruce
>
> --
> Darren
>
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Ross
>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
next prev parent reply other threads:[~2012-06-13 21:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-13 20:44 More useful generic-x86 machine Ross Burton
2012-06-13 20:47 ` Darren Hart
2012-06-13 20:52 ` Ross Burton
2012-06-13 20:55 ` Bruce Ashfield
2012-06-13 21:00 ` Darren Hart
2012-06-13 21:09 ` Bruce Ashfield [this message]
2012-06-13 20:49 ` Bruce Ashfield
2012-06-13 22:50 ` Stewart, David C
2012-06-14 0:39 ` Darren Hart
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=4FD9017D.6050805@windriver.com \
--to=bruce.ashfield@windriver.com \
--cc=dvhart@linux.intel.com \
--cc=yocto@yoctoproject.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.