[lsb-discuss] notes on LSB architecture addition

[Wichmann, Mats D]

I promised to write some notes on the addition and what to look at,
and then got swamped, then stuck in an email transition that caused
me to lose track of the message I was going to reply to - sorry!
I'm just sending this to lsb-discuss, I know some of the calls for
participation have been rather widely disseminated, pass this on if
needed (or it should end up in the mailing list archive)

So...  the heart of all of the stuff is the LSB database.  This has its own
web page, so you can read as little or as much as you like about it:

http://ispras.linuxfoundation.org/index.php/LSB_Database_Home

<http://ispras.linuxfoundation.org/index.php/LSB_Database_Home>There's a
description of the schema, and the tables that are mostly
involved are join tables that have "Arch" in them, as this is where
a generic description is mapped into specifics for a particular
architecture.  There are a few others (TypeMember and TypeMemberExtras)
as well.

There's a patch file (sql instructions) which attempts to add ARM
http://bzr.linuxfoundation.org/unofficial/arm/add_arm.sql
This isn't a branch so loggerhead is hiding it, I should move it
somewhere else I guess.  The patch is done with no knowledge
applied, just brute-force duplication of sets of existing records.

You don't need to set up the database to get started:
there are two sets of files that have been generated from this -
the bzr branches build_env and misc-test.

build_env knows how to build in LSB mode, so it includes a compiler
wrapper, "stub" (link-time-only) libraries, and headers.  In the header
directory there are ordinary headers, and files suffixed .defs, those
are used when the actual specification document is generated
(defs for "data definitions") but are not interesting at this stage, they're
basically single-architecture instances of the headers, with some
other changes that are not worth describing, so if the headers are
right, the defs will almost certainly also be right.

so the main job is to understand whether the headers (structure
layouts, constants, data types and sizes) are correct, and whether
the symbol versioning (embedded in the stub libraries) is correct.

two tools can help with this... both live in the other branch,
misc-test.  The first is libchk, this is a checker for the presence of
required symbols and libraries, and for those cases where symbol
versioning is used, for the correct symbol versions.  So running
a "make" in misc-test inside an ARM build enviroment (native,
or I suppose cross would also work) will hopefully build an
appropriate binary, then in libchk run "./lsblibchk" to generate a
report.   With such a report we would have information to update
the database, then continue to iterate until it's correct.

the second tool is devchk... in misc-test/devchk/ts/devchk.
this is a bunch of generated checks for each LSB library, and
it's built in two modes:  using the native compiler, so that we can
see if the descriptions in the database are aligned with the native
headers for that architecture, then a second time with the LSB
SDK (the stuff from build_env) so that it can check if things are
self-consistent between the LSB headers and other information.
Getting the native-build version clean is a pretty big job, it does
generate sql instructions but the tool is not of high enough quality
that these can just be applied verbatim.  We have a long list of
wish-list items for devchk to improve it, but unfortunately nobody
to work on making those improvements.   The main thing it gets
wrong is rather relevant here:  it operates in isolation, and does not
have knowledge of other architectures while it's working (irritating
since the information is there, but #ifdef'd out), so it will often propose
wrong -
update FOO with details for Arch=1 (All) rather than with details
for Arch=4 (ARM).



For browsing the database for details, we suggest the LSB Navigator,
which also has a web page:
http://ispras.linuxfoundation.org/index.php/LSB_DB_Navigator

the hosted instance of this does not have the experimental elements
in it, but it's not too hard to set up a local instance (it's a bunch
of php code, which connects to a mysql database instance, and
there's really only two places you need to configure - password/name/
other details of the db instance for navigator, and then whatever
webserver setup is needed to actually allow access to the navigator).
I imagine Linux Foundation could also host such an instance, but
that's not mine to promise :)

There are conceptually two parts to the database, "LSB Elements"
(which are things describing the ABI), and "Community Data"
(which are captured details about distributions and applications
that let developers understand more about where things are common
and where they aren't).   As things evolve, it will be useful to scan
some ARM-based distributions and add them to the Community
Data, just so information will be available.  There's a tool for that,
and it has a page on the wiki as well.


I think that's enough detail for the moment... questions welcome of course.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20110604/0a38c945/attachment.htm