On 28.09.2011, at 12:50, Steve McIntyre wrote:
> On Tue, Sep 27, 2011 at 06:31:51PM +0200, Alexander Graf wrote:
>> On 27.09.2011, at 18:19, Steve McIntyre wrote:
>>>
>>> Out of curiosity, what are you using as a triplet for your hard-float
>>> port? The discussion at LPC focussed on this to some extent:
>>>
>>> http://lists.linaro.org/pipermail/cross-distro/2011-September/000054.html
>>
>>
>> Ah, nice. I didn't find that mail before. I only found one where the
>> discussion on the target names "armhf" and "armv7hl" was raised, so
>> we named the target "armv7hl" to be compatible with Fedora and Meego.
>
> Fair enough, the internal name doesn't matter much. :-)
Well, it actually does matter because rpm compares it with the output of uname to check if the architecture is compatible. However, if we call it "armv7hl", we are incompatible with armv7l which logically would be missing VFP capabilities. Now, uname unfortunately only emits armv7l (see arch/arm/mm/proc-v7.S), so we never know if our host is capable of running armv7hl code.
So we can either build our packages against armv7hl, breaking the assumption that we can find the machine type from uname (basically adding a hack that armv7hl is compatible to armv7l).
Or we could build our packages against armv7l which is what the kernel emits (good!), but would diverge from how Fedora and Meego call their packages.
We're currently not sure which path would be the better one to walk down on. What's the rationale from the other distro folks here?
Alex
Please coordinate with Jon Masters at RedHat/Fedora and Adam Conrad at
Ubuntu/Debian on this. (Cc'ing the cross-distro list, through which the
recent ARM summit at Linux Plumbers was organized.)
Cheers,
- Michael
On Sep 16, 2011 8:41 AM, "David Gilbert" <david.gilbert(a)linaro.org> wrote:
> OK, so we seem to have agreement here that what we want is autodetect
> for eglibc and
> forget about the triplet; well technically that probably makes my life
> easier, and I don't
> think it's too hard a sell.
>
> Dave
>
> _______________________________________________
> linaro-toolchain mailing list
> linaro-toolchain(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Folks,
I want to let you know I have some notes from LPC that I will be sending
out. I didn't get to this on Friday, so I plan to have it out first
thing Mon. I'll followup to this thread once I have that taken care of.
Jon.
Jon Masters <jcm(a)edison.jonmasters.org> wrote:
>---begin log---
>jonmasters [19:14:43] <infinity:#linaro-armhf> lool: jonmasters took
>pretty comprehensive notes, not sure if he's sent them anywhere yet.
>jonmasters [19:14:59] <infinity:#linaro-armhf> jonmasters: ^
>---end of log---
I will send notes later. Before Mon anyway.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Folks,
A couple of things from me. Split into two sections:
Dialin
------
IRC: #linaro-armhf (irc.freenode.net)
Time: 8pm Pacific tonight.
I have had a special line setup on the Red Hat Conference system. To
dial into this, use one of the following country-specific codes with the
access code of 6177591337 (which is my US cellphone number btw).
Global Network Access
Toll-Free Dial-in Numbers:
Australia : 1800337169
Brazil : 08008921002
Finland : 0800117116
France : 0805632867
Germany : 08006647541
United Kingdom: 08006948057
United States: 18004518679
Agenda
------
(Steve already sent out a comprehensive agenda)
To Steve's other point around topics for tonight, I agree that the only
things (being brutally honest also here) I really care about is
hardfloat and standardization. I think we should collectively consider
at the start of the meeting whether it makes sense (IMO it does) to
confine our discussion to topics we can make progress on in the limited
time that we have. I also suggest seeing if we can find another time to
followup tomorrow that we can all agree on. For those of us here in
person, I assume there can be dinner/beverages after. I am open to
grabbing a late dinner if anyone else is interested too.
Topics I would like to specifically include in the discussion:
1. Agree that all the distros want hard float. And what that means (just
refer to the AAPCS stuff we all already know). Basically a statement "we
the assembled Linux community will be supporting a common definition of
hardfloat in our distributions", etc. I have people asking me on and off
about hardfloat thinking every distro is doing its own thing...which
actually is far worse than reality. So, let's fix this with a generic
fluffy media-friendly statement.
2. Cross standardization. Not just LSB but how are we going to keep
these discussions going? There is the hardfloat IRC channel, etc. but I
think this is bigger than HF. I want an ongoing cross-distro discussion
around ARM standards. That can be cross-distro, but it *must* actually
have some agreed framework, with regular syncups. I would go as far as
to say we need a regular phone call (can be once a month) just to force
us all to keep this collective ball rolling.
Thanks!
Jon.
P.S. Please forward this information to anyone else who should dial in.
I am not yet certain this will actually work given that this isn't a
regular LF event so the folks I would usually ask for assistance hooking
this up (an actual, non-cell phone with some kind of speakerphone that
will work, etc.) but I'm pinging folks now.
David:
On Wed, Aug 24, 2011 at 6:55 PM, <david(a)lang.hm> wrote:
> ARM is currently in worse shape than the PC market ever was in this aspect,
> but in this case it's less a matter of getting the hardware guys to change
> what they do than it is to get better documentation of what the hardware is
> really doing and not duplicating drivers for cases where the right answer is
> just replacing a constant with a variable (just as an example of the very
> common case where the same component is wired to a different address)
I agree.
Maybe Linaro or an equivalent organization could provide a "ARM kernel
janitor" service to the community, where they refactor existing ARM
platform/driver code to make it more common. This is something that's
difficult for a single person with experience in only one or two SoCs
to do, but it would be pretty straightforward work for a team of three
or four people with broad coverage of the SoC devices the kernel
supports now.
As such refactoring consolidated larger and larger chunks of kernel
code, new designs would gravitate towards those consolidated
implementations because they would be the dominant references.
b.g.
--
Bill Gatliff
bgat(a)billgatliff.com
