Does anyone care about LSB on arm?

David Rusling david.rusling at
Tue May 31 22:32:18 UTC 2011

     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...

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:
> 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
>, 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

Lockton House
Clarendon Rd

More information about the ubuntu-devel mailing list