Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   Does anyone care about LSB on arm? (http://www.linux-archive.org/debian-development/533171-does-anyone-care-about-lsb-arm.html)

Wookey 05-31-2011 04:22 PM

Does anyone care about LSB on arm?
 
[Apologies for the wide distibution of this mail (Debian, Ubuntu and
Fedora main+arm dev lists, plus linaro and lsb) but it's useful to
catch people who care about this issue enough to do some work. Do
please bear the distribution in mind when replying, focussing any
detailed discussion on linaro-dev please. I'll post a summary at the
end if there is material input]

---------------

The subject of the Linux Standards Base (LSB) and ARM came up at the
recent Linaro Dev summit.

During discussion of standardisation of ABI across distributions (Ubuntu,
Debian, Fedora etc) it was suggested that maybe the LSB was a useful
place to specify some kind of agreed minimum.

It turns out that the LSB supports 7 architectures, but does not
include ARM, beyond the catch-all 'generic'. This seemed an odd
omission so I contacted the LSB people who were very helpful, and I
found that they would like to support ARM but a) there was not a clear
binary ABI standard to support in the past (there were lots of
variants) and b) no-one really stepped up to do the work of porting
the LSB docs and tools.

It came up on the LSB list too:
https://lists.linux-foundation.org/pipermail/lsb-discuss/2011-May/006828.html

As I say in that thread, I think a) has been dealt with in that there
is now an agreed base with wide-enough support that we could usefully
specify (the armv7, VFP-D16 ('hard-float'), little-endian ABI, as used
by Debian 'armhf', Ubuntu 'armhf', Fedora 'armv7hl', and also Meego
'armv7hl'). That fits with what Linaro is supporting too.

Mats D Wichman kindly gave some idea of how much work in needed to
'port' the LSB in the above thread:

-------------
in that range of options [week, month, year, 6 years], it's closer to
a year than to any of the others.

The spec work isn't hard by itself if there's a reasonable
processor-level ABI document available, which unless something
has changed, is the case for ARM: like the psABI documents
that exist for other architectures, reference is made to such
a base document (or set) for things like register assignments,
calling conventions, exception processing, etc. so it doesn't
have to be written - maybe just pinning down where the base
document offers choices, that the LSB ABI does it this way.

In addition to the spec, there's a great deal of code around
LSB, which all has to be adapted. It's obviously portable
code since it works for seven architectures already, of
varying wordsizes, endian-ness, etc. Where there are details
specific to a processor architecture, we actually have all of
the details stored in a database (which can be browsed at
http://dev.linuxfoundation.org/navigator), and the biggest
task actually becomes populating the database with data for
this new architecture. There are some fairly reasonable tools
for scanning a distribution which would provide a useful
starting point, but then someone has to validate that things
are all correct. Some of the validation happens by building
and running iteratively various checkers which are part of the
software suite anyway. That will require adjusting a number of
makefiles, populating new trees under arch-specific names, etc.
but that part is easy enough, just manual work. It has been
rather a long time since a new architecture was added, I
think PPC64 and S390X were added at about the same time and
it was many years ago), so the procedure hasn't really been
tested out recently.

Then there are a bunch of test suites which need to run to
validate that a distribution conforms, and in my experience,
this ends to be where new issues show up that break the assumption
that everything's clean and portable, so there may well be
extra debugging here.
------------------

As this is a non-trivial amount of work, the question then arises,
does anyone care about this enough to actually do the work? Linaro is
an obvious organisation that could expend some engineering effort on
this, but to do that it needs some indication that it's more than a
'would-be-nice'.

Who actually uses the LSB for making widely-distributed binaries? Would
anyone do so on ARM if it was specced? Is it important to make ARM a
'real' architecture alongside the others, e.g. especially in server space?

In my experience anyone distributing binaries actually picks a small
set of distros and builds for those explicitly, rather than relying
on the LSB. Does that mean that it's not actually useful in the real
world? I guess in a sense this posting is to the wrong lists; we're
all free software people here who have little use for the LSB. Where
do the proprietary software distributors hang out :-)

It's easy to think of potential use-cases, and I think ultimately,
unless the LSB is in fact entirely irrelevant, this work will get done
everntually. But should we get on with that now, rather than whatever
else we might be fixing, and if so, who is volunteering to get
involved?

( Jon Masters and I have both expressed interest but are not exactly
brimming over with spare time. Any more for any more?)

Opinions welcome.

Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110531162239.GG5028@dream.aleph1.co.uk">http://lists.debian.org/20110531162239.GG5028@dream.aleph1.co.uk

David Rusling 05-31-2011 10:32 PM

Does anyone care about LSB on arm?
 
Wookey,
the short answer is 'yes'. The next question is 'who?'. Maybe
this can be bolted onto the hard float work, I'll let Konstantinos and
Steve respond...

Dave

On 06/01/11 01:22, Wookey wrote:

[Apologies for the wide distibution of this mail (Debian, Ubuntu and
Fedora main+arm dev lists, plus linaro and lsb) but it's useful to
catch people who care about this issue enough to do some work. Do
please bear the distribution in mind when replying, focussing any
detailed discussion on linaro-dev please. I'll post a summary at the
end if there is material input]

---------------

The subject of the Linux Standards Base (LSB) and ARM came up at the
recent Linaro Dev summit.

During discussion of standardisation of ABI across distributions (Ubuntu,
Debian, Fedora etc) it was suggested that maybe the LSB was a useful
place to specify some kind of agreed minimum.

It turns out that the LSB supports 7 architectures, but does not
include ARM, beyond the catch-all 'generic'. This seemed an odd
omission so I contacted the LSB people who were very helpful, and I
found that they would like to support ARM but a) there was not a clear
binary ABI standard to support in the past (there were lots of
variants) and b) no-one really stepped up to do the work of porting
the LSB docs and tools.

It came up on the LSB list too:
https://lists.linux-foundation.org/pipermail/lsb-discuss/2011-May/006828.html

As I say in that thread, I think a) has been dealt with in that there
is now an agreed base with wide-enough support that we could usefully
specify (the armv7, VFP-D16 ('hard-float'), little-endian ABI, as used
by Debian 'armhf', Ubuntu 'armhf', Fedora 'armv7hl', and also Meego
'armv7hl'). That fits with what Linaro is supporting too.

Mats D Wichman kindly gave some idea of how much work in needed to
'port' the LSB in the above thread:

-------------
in that range of options [week, month, year, 6 years], it's closer to
a year than to any of the others.

The spec work isn't hard by itself if there's a reasonable
processor-level ABI document available, which unless something
has changed, is the case for ARM: like the psABI documents
that exist for other architectures, reference is made to such
a base document (or set) for things like register assignments,
calling conventions, exception processing, etc. so it doesn't
have to be written - maybe just pinning down where the base
document offers choices, that the LSB ABI does it this way.

In addition to the spec, there's a great deal of code around
LSB, which all has to be adapted. It's obviously portable
code since it works for seven architectures already, of
varying wordsizes, endian-ness, etc. Where there are details
specific to a processor architecture, we actually have all of
the details stored in a database (which can be browsed at
http://dev.linuxfoundation.org/navigator), and the biggest
task actually becomes populating the database with data for
this new architecture. There are some fairly reasonable tools
for scanning a distribution which would provide a useful
starting point, but then someone has to validate that things
are all correct. Some of the validation happens by building
and running iteratively various checkers which are part of the
software suite anyway. That will require adjusting a number of
makefiles, populating new trees under arch-specific names, etc.
but that part is easy enough, just manual work. It has been
rather a long time since a new architecture was added, I
think PPC64 and S390X were added at about the same time and
it was many years ago), so the procedure hasn't really been
tested out recently.

Then there are a bunch of test suites which need to run to
validate that a distribution conforms, and in my experience,
this ends to be where new issues show up that break the assumption
that everything's clean and portable, so there may well be
extra debugging here.
------------------

As this is a non-trivial amount of work, the question then arises,
does anyone care about this enough to actually do the work? Linaro is
an obvious organisation that could expend some engineering effort on
this, but to do that it needs some indication that it's more than a
'would-be-nice'.

Who actually uses the LSB for making widely-distributed binaries? Would
anyone do so on ARM if it was specced? Is it important to make ARM a
'real' architecture alongside the others, e.g. especially in server space?

In my experience anyone distributing binaries actually picks a small
set of distros and builds for those explicitly, rather than relying
on the LSB. Does that mean that it's not actually useful in the real
world? I guess in a sense this posting is to the wrong lists; we're
all free software people here who have little use for the LSB. Where
do the proprietary software distributors hang out :-)

It's easy to think of potential use-cases, and I think ultimately,
unless the LSB is in fact entirely irrelevant, this work will get done
everntually. But should we get on with that now, rather than whatever
else we might be fixing, and if so, who is volunteering to get
involved?

( Jon Masters and I have both expressed interest but are not exactly
brimming over with spare time. Any more for any more?)

Opinions welcome.

Wookey



--
David Rusling, CTO
http://www.linaro.org

Linaro
Lockton House
Clarendon Rd
Cambridge
CB2 8FH


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DE56C72.7050702@linaro.org">http://lists.debian.org/4DE56C72.7050702@linaro.org

Luke Kenneth Casson Leighton 06-01-2011 11:25 AM

Does anyone care about LSB on arm?
 
On Tue, May 31, 2011 at 5:22 PM, Wookey <wookey@wookware.org> wrote:

> In my experience anyone distributing binaries actually picks a small
> set of distros and builds for those explicitly, rather than relying
> on the LSB. Does that mean that it's not actually useful in the real
> world? I guess in a sense this posting is to the wrong lists; we're
> all free software people here who have little use for the LSB. Where
> do the proprietary software distributors hang out :-)

the proprietary software distributors hang out around USA lawyer
offices, where they get advice on how to perform tivoisation without
anybody noticing. they then ship TVs and even 3G modems with embedded
linux kernels and custom OSes... and nobody notices.

my take on this is that ARM is still just emerging from the
"uselessness" of sub-600mhz ARM9s and ARM11s as far as general-purpose
computing is concerned [laptop / desktop etc. *not* true embedded
purposes obviously: don't get upset, ARM employees, because "mr LKCL
said your processors were quotes useless quotes" - read it again: it's
a *conditional* description]. also, the sheer diversity of SoCs plays
directly, psychologically, against anyone "joining forces" on things
like LSB. thus the majority of proprietary software distributors up
until recently have been doing custom-built from scratch software
stacks [using e.g. buildroot, openembedded] and thus LSB was and still
is completely useless to them.

even android is custom-built, and everything (except the
highly-optimised apps - for ARM - which are becoming more common) is a
java app.

that having been said, 500mhz+ Dual-Core Cortex A9s already out which
knock the stuffing out of 1.6ghz Intel Atoms (yes, saw the youtube
video) mean that could just be about to change, completely.

sooo... although the situation *right now* is that nobody in the
commercial world is the slightest bit interested in LSB because they
all do "custom builds" of complete software stacks, it could be said
that *if* the free software community just dropped ready-to-go LSB
standards in front of their noses, they'd quite likely use it.

you have to remember that the majority of these companies could not
put two lines of code together to save their lives. they literally
have to be spoon-fed (in some cases even to the point of being told
where to put the screws, let alone the software). they are usually
spoon-fed by the CPU manufacturer [and in the case of MStar Semi, they
won't even let *you* violate the GPL, they do it entirely for you].

so in that regard, i think it's more a case of "if the free software
community provides LSB across ARM, it'll get used".

so in _that_ regard, the question becomes: "are the efforts of the
free software community better off being spent elsewhere"? and "what
benefit is there *TO THE FREE SOFTWARE COMMUNITY* of doing LSB for
ARM"? forget the proprietary junkies, they'll suck anything from us
that moves and not give a dime in return.

l.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTimigcU991sPdORnpBH0zBnUT+nDoQ@mail.gmail.com ">http://lists.debian.org/BANLkTimigcU991sPdORnpBH0zBnUT+nDoQ@mail.gmail.com

Steve McIntyre 06-01-2011 01:36 PM

Does anyone care about LSB on arm?
 
On Wed, Jun 01, 2011 at 07:32:18AM +0900, David Rusling wrote:
>On 06/01/11 01:22, Wookey wrote:
>
>>As this is a non-trivial amount of work, the question then arises,
>>does anyone care about this enough to actually do the work? Linaro is
>>an obvious organisation that could expend some engineering effort on
>>this, but to do that it needs some indication that it's more than a
>>'would-be-nice'.
>
>Wookey,
> the short answer is 'yes'. The next question is 'who?'.

Absolutely, yes. It makes a lot of sense for the growing number of
people looking to collaborate here to pool their efforts in an
existing central spec/location.

>Maybe this can be bolted onto the hard float work, I'll let
>Konstantinos and Steve respond...

Ah, I guess I've just volunteered myself haven't I? :-)

/me goes to subscribe to the LSB lists and start reading things.

Cheers,
--
Steve McIntyre
steve.mcintyre@linaro.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110601133626.GE6788@linaro.org">http://lists.debian.org/20110601133626.GE6788@linaro.org

Jeff Licquia 06-01-2011 03:00 PM

Does anyone care about LSB on arm?
 
On 06/01/2011 07:25 AM, Luke Kenneth Casson Leighton wrote:

so in _that_ regard, the question becomes: "are the efforts of the
free software community better off being spent elsewhere"? and "what
benefit is there *TO THE FREE SOFTWARE COMMUNITY* of doing LSB for
ARM"? forget the proprietary junkies, they'll suck anything from us
that moves and not give a dime in return.


That seems to be my cue to provide the community case for the LSB.

The LSB provides several things to the community:

- a framework for allowing Linux distributions to pool their userbase
and work together as one platform instead of multiple platforms, one per
distro


- test suites which identifies both compatibility problems and
outright bugs to be detected and fixed


- a method for targeting builds at multiple distributions at once,
both proprietary and free


- reporting tools for finding portability problems in built apps,
again for both proprietary and free apps


We currently provide all of this for 7 architectures. ARM benefits
indirectly (for example, many of the compatibility breaks detected on,
say, x86_64 will affect all archs equally), but indirect support doesn't
include the tools we've developed, and often compatibility issues are
arch-specific.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DE653FD.5080208@licquia.org">http://lists.debian.org/4DE653FD.5080208@licquia.org

Jeremiah Foster 06-01-2011 03:29 PM

Does anyone care about LSB on arm?
 
On Wed, Jun 1, 2011 at 1:25 PM, Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
> On Tue, May 31, 2011 at 5:22 PM, Wookey <wookey@wookware.org> wrote:
>
>> In my experience anyone distributing binaries actually picks a small
>> set of distros and builds for those explicitly, rather than relying
>> on the LSB. Does that mean that it's not actually useful in the real
>> world? I guess in a sense this posting is to the wrong lists; we're
>> all free software people here who have little use for the LSB. Where
>> do the proprietary software distributors hang out :-)

They are starting to hang out in all the familiar Free Software places. :-)


> *sooo... although the situation *right now* is that nobody in the
> commercial world is the slightest bit interested in LSB because they
> all do "custom builds" of complete software stacks, it could be said
> that *if* the free software community just dropped ready-to-go LSB
> standards in front of their noses, they'd quite likely use it.

Circumspect and balanced as always Mr. Leighton. :)

I've been to the "commercial world" on a temporary visa and they do in
fact care about things like standards. In fact I would go so far as to
say that this LSB proposal for ARM would significantly improve life
for consortia like GENIVI which has members from the ARM and Intel
camp.

> *you have to remember that the majority of these companies could not
> put two lines of code together to save their lives. *they literally
> have to be spoon-fed (in some cases even to the point of being told
> where to put the screws, let alone the software). *they are usually
> spoon-fed by the CPU manufacturer [and in the case of MStar Semi, they
> won't even let *you* violate the GPL, they do it entirely for you].
>
> *so in that regard, i think it's more a case of "if the free software
> community provides LSB across ARM, it'll get used".

I agree.

> *so in _that_ regard, the question becomes: "are the efforts of the
> free software community better off being spent elsewhere"? *and "what
> benefit is there *TO THE FREE SOFTWARE COMMUNITY* of doing LSB for
> ARM"? *forget the proprietary junkies, they'll suck anything from us
> that moves and not give a dime in return.

In my experience there are dimes to be had, you just have to ask nicely.

Regards,

Jeremiah


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTikx_3kfVh=0poP=bs_1CcmYERTxLg@mail.gmail.com ">http://lists.debian.org/BANLkTikx_3kfVh=0poP=bs_1CcmYERTxLg@mail.gmail.com

Jesse Barker 06-01-2011 03:30 PM

Does anyone care about LSB on arm?
 
At the risk of overstating the obvious, there are also ABI guarantees
at stake here, which in my mind are architecture agnostic. OpenGL
applications need to know which bits (API functions) of which core
versions can be expected to be resolved during load time and which
must be queried through GetProcAddress. LSB specifies this and makes
it unambiguous.

cheers,
Jesse

On Wed, Jun 1, 2011 at 8:00 AM, Jeff Licquia <jeff@licquia.org> wrote:
> On 06/01/2011 07:25 AM, Luke Kenneth Casson Leighton wrote:
>>
>> *so in _that_ regard, the question becomes: "are the efforts of the
>> free software community better off being spent elsewhere"? *and "what
>> benefit is there *TO THE FREE SOFTWARE COMMUNITY* of doing LSB for
>> ARM"? *forget the proprietary junkies, they'll suck anything from us
>> that moves and not give a dime in return.
>
> That seems to be my cue to provide the community case for the LSB.
>
> The LSB provides several things to the community:
>
> *- a framework for allowing Linux distributions to pool their userbase and
> work together as one platform instead of multiple platforms, one per distro
>
> *- test suites which identifies both compatibility problems and outright
> bugs to be detected and fixed
>
> *- a method for targeting builds at multiple distributions at once, both
> proprietary and free
>
> *- reporting tools for finding portability problems in built apps, again for
> both proprietary and free apps
>
> We currently provide all of this for 7 architectures. *ARM benefits
> indirectly (for example, many of the compatibility breaks detected on, say,
> x86_64 will affect all archs equally), but indirect support doesn't include
> the tools we've developed, and often compatibility issues are arch-specific.
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTin3xg2OhzpJNKLHM9w9xA-e7V5Jag@mail.gmail.com">http://lists.debian.org/BANLkTin3xg2OhzpJNKLHM9w9xA-e7V5Jag@mail.gmail.com

David Rusling 06-01-2011 08:59 PM

Does anyone care about LSB on arm?
 
Steve,
thanks, have a poke around and tell me / OCTO what it means to join
in, what the costs and benefits are etc...


Dave

On 06/01/11 22:36, Steve McIntyre wrote:

On Wed, Jun 01, 2011 at 07:32:18AM +0900, David Rusling wrote:

On 06/01/11 01:22, Wookey wrote:


As this is a non-trivial amount of work, the question then arises,
does anyone care about this enough to actually do the work? Linaro is
an obvious organisation that could expend some engineering effort on
this, but to do that it needs some indication that it's more than a
'would-be-nice'.

Wookey,
the short answer is 'yes'. The next question is 'who?'.

Absolutely, yes. It makes a lot of sense for the growing number of
people looking to collaborate here to pool their efforts in an
existing central spec/location.


Maybe this can be bolted onto the hard float work, I'll let
Konstantinos and Steve respond...

Ah, I guess I've just volunteered myself haven't I? :-)

/me goes to subscribe to the LSB lists and start reading things.

Cheers,



--
David Rusling, CTO
http://www.linaro.org

Linaro
Lockton House
Clarendon Rd
Cambridge
CB2 8FH


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DE6A82D.6050402@linaro.org">http://lists.debian.org/4DE6A82D.6050402@linaro.org

Jon Masters 06-04-2011 05:32 AM

Does anyone care about LSB on arm?
 
On Wed, 2011-06-01 at 12:25 +0100, Luke Kenneth Casson Leighton wrote:

> sooo... although the situation *right now* is that nobody in the
> commercial world is the slightest bit interested in LSB because they
> all do "custom builds" of complete software stacks, it could be said
> that *if* the free software community just dropped ready-to-go LSB
> standards in front of their noses, they'd quite likely use it.

The reason we're discussing this is because a new architecture isn't
going to be supported in standards like LSB overnight. It might take
some time, and by that time, things may have changed with respect to the
adoption of ARM systems. But if we don't think ahead, we're forced to be
reactionary and try to do this (probably less effectively) later on.

Nobody will be forced to adopt LSB, but general purpose distributions
can benefit from having compatibility at the software level. Is this an
issue for deeply embedded platforms? Not so much. Is it bad that Android
rebuilds the Universe? It's their decision to make. I think we need to
distinguish between traditional embedded uses of ARM parts, which will
continue, and those of larger parts running general a purpose OS. I
don't expect to see Fedora running on my cellphone, but I do have it
running on a netbook quite nicely - the latter needs LSB more.

I'll leave the rest of the rhetoric alone :)

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Jon Masters 06-04-2011 05:32 AM

Does anyone care about LSB on arm?
 
On Wed, 2011-06-01 at 12:25 +0100, Luke Kenneth Casson Leighton wrote:

> sooo... although the situation *right now* is that nobody in the
> commercial world is the slightest bit interested in LSB because they
> all do "custom builds" of complete software stacks, it could be said
> that *if* the free software community just dropped ready-to-go LSB
> standards in front of their noses, they'd quite likely use it.

The reason we're discussing this is because a new architecture isn't
going to be supported in standards like LSB overnight. It might take
some time, and by that time, things may have changed with respect to the
adoption of ARM systems. But if we don't think ahead, we're forced to be
reactionary and try to do this (probably less effectively) later on.

Nobody will be forced to adopt LSB, but general purpose distributions
can benefit from having compatibility at the software level. Is this an
issue for deeply embedded platforms? Not so much. Is it bad that Android
rebuilds the Universe? It's their decision to make. I think we need to
distinguish between traditional embedded uses of ARM parts, which will
continue, and those of larger parts running general a purpose OS. I
don't expect to see Fedora running on my cellphone, but I do have it
running on a netbook quite nicely - the latter needs LSB more.

I'll leave the rest of the rhetoric alone :)

Jon.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1307165537.27070.835.camel@constitution.bos.jonmas ters.org">http://lists.debian.org/1307165537.27070.835.camel@constitution.bos.jonmas ters.org


All times are GMT. The time now is 12:55 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.