[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
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
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
( Jon Masters and I have both expressed interest but are not exactly
brimming over with spare time. Any more for any more?)