On 09/15/2011 01:55 PM, Jon Masters wrote:
Folks,
I've taken the liberty of inviting myself to the party :) I'm also on
IRC on Freenode, and have been following RPM development for some time
in a lurking capacity. A number of you know me from the office, but
greetings to everyone else!
Thanks for taking the time to write this, hmm, initiative. I'm not going
to pretend I have solutions at hand (I dont), so this will be just
random initial thoughts on the subject(s) which hopefully will inspire
further ideas & discussion.
We're currently engaged in bootstrapping support for "hardfp"[0] in the
Fedora Linux distribution (specifically, in release 15 thereof) for use
by systems featuring an ARM version 7 A (Application) processor or later
ARM. This is a new ABI as far as Linux is concerned, and it is parallel
installable with the older "EABI" or (loosely) "softfp" that has been
supported up until this point (for example in our ARM version 5 port, as
released in Fedora 13).
Currently, we have a hacked up RPM binary that introduces e.g.:
* armv7hl
* armv7nhl (MeeGo disagrees on this and calls it "hnl" btw)
* armv7thl [1]
I dont really have an opinion of what the umphteen ARM (and other)
architectures should call themselves. However since there is a
pre-existing naming practise in Meego, I'd like to see that used unless
there are strong arguments against it. In fact the Meego folks did
contact me on the arch naming before going on with their selection (and
I didn't have any more opinion about it than I do now), its just that I
don't recall ever receiving the patch to add them, so it went
"unreserved" from upstream POV.
Dennis has some code (he can forward) that is carried in F15 currently,
and which Panu has previously taken a look at. It uses the typical
parsing of /proc as an approach, though we agree that the "correct" way
to do that would be through AT_HWCAPS, as in here:
https://wiki.linaro.org/Resources/HowTo/DeterminingCPUFeatures
(last raised on rpm-maint@ in 2008 as it turns out :) )
I've been poking around AT_HWCAP and friends for the last couple of
days, inspired by private emails around this topic. It would seem that
AT_PLATFORM + AT_HWCAP could be used to (easily even) replace the
current hodge-podge of inline assembly magic & parsing the rather ad-hoc
arch-dependent formatted /proc/cpuinfo for arch + capability detection.
The contents of AT_* vectors are highly arch-specific, but at least the
interface to access that data is the same across architectures. And this
mechanism does exist on at least some other OS'es than just Linux,
making it a whole lot more "portable" than the current methods. (whether
anybody really actually cares about rpm on non-Linux platforms is
another question)
So far it looks like a promising path, but this is mostly just an
implementation detail and not that big a deal in itself.
All of the existing stuff assumes that if we have vfpv3 on ARMv7 we're
going to be running in hardfp. We can keep that notion around in the
very short term, but we need a longer term solution. And although we
don't necessarily plan actual parallel installs of different ABIs, it is
not technically the case that all ARMv7 systems are going to be running
the hardfp port. We may e.g. install an ARMv5 port therein.
Add to this the fact that we now have X32 (a new x86 32-bit ABI) in the
Intel world, and it's clear that RPM needs a generic way to handle
multiple possible ABIs within the same architecture. I personally favor
the "multiarch" approach being taken by Debian, but I don't really want
to espouse one particular approach here. What I do want to do is to kick
off a discussion thread in which you RPM folks can decide how you want
to handle multiple ABIs in both the ARM and non-ARM worlds that myself,
Dennis, and others occupy. I'm sure Dennis, Panu, and others can point
folks at existing patches.
...but *this* is a vast topic reaching far beyond rpm. Our Debian
friends have done a whole lot of studying (and without doubt, a whole
lot of arguing :) and documenting the issue. Regardless of what rpm ends
up in rpm, the Debian multiarch docs are well worth reading:
http://wiki.debian.org/Multiarch/TheCaseForMultiarch (more info + links
at http://wiki.debian.org/Multiarch)
What I want out of this discussion is a decision around how multiple
ABIs within an architecture will be handled in general. If you're
allergic to ARM, consider that in the Intel space there is now IA32,
X32, and X64. The former is a 32-bit architecture, and the latter are
both ABIs layered upon the 64-bit architecture. ARM and Intel aren't
alone in this, there are others out there doing similarly fun things.
Rpm does have limited provisions for multilib/multiarch of course
(that's how x86_64 etc multilib archs work on Fedora/RHEL), but what's
there is not sufficient for generic multiarch/multiabi parallel support.
To outline the issues:
1) Location of libraries and the like: the libraries for different ABI's
need to go to separate paths. Currently the non-debian world knows /lib
and /lib64, and while it's of course possible to add /libx32 and
whatnot, that gets *extremely* ugly real soon and simply does not scale
to things like cross-toolchains. The debian multiarch spec seems rather
nice in this regard: "simply" stuff it all into separate libraries in
$(prefix)/lib/$(arch)-$(abi) style distinct paths, without
differentiating between "native" and other archs/abis.
This is something that can't be decided and solved by rpm alone, the
entire distro and the compiler/linker toolchains are involved.
2) Dependencies: there needs to be a way to distinguish between
(including but not limited to) libraries with identical soname-version
but different ABI. Rpm currently only knows of two kinds of soname
dependencies: ones with ()(64bit) postfix and ones without it. This
kinda works for what it gets used now, but is full of weird wrinkles
like some 64bit architectures not getting the (64bit) marker etc, and
obviously does not scale to full-fledged multi/cross-arch dependencies.
So the autogenerated soname dependencies would need to encode full
arch+abi(+maybesomethingelsetoo) into the dependencies. The problem here
is that changing the way dependencies are encoded is a MASSIVE
backwards-compatibility breakage, and probably would need both old-style
and new-style dependencies to be generated (although some of this might
be possible to arrange at runtime) for a transition period.
For manually added dependencies %{_isa} goes a long way, but probably
not sufficient in its current form for a full-scale multiarch, multiabi
system.
Then there's the issue of dependency satisfiability across architectures
and abi's. Rpm has some provisions for this (dependency "colors"), but
its currently limited to just differentiate between 32bit vs 64bit (and
obviously "other") and there's no way to express allowed/prohibited
dependency matches across architectures.
The same coloring system is used to resolve elf-file conflicts on common
paths. This rather crazy system can be entirely avoided by better/more
fine-grained packaging: always place libraries and the like into
separate (sub)packages to eliminate conflict potential. Based on the
debian notes, dpkg apparently has issues with identical files shared
across multiple packages, but this is not an issue for rpm: it's
"always" been possible for multiple packages to share files, as long as
the files are identical.
3) Package naming & resolution: when in "multilib" mode (in rpm jargon,
"colored transaction"), packages with identical name but different
architecture can co-exist relatively peacefully. However the use of
"arch" alone is limiting from multiabi perspective, it'd require every
single different arch/abi combination to have arch of their own. Other
possibility is differentiating in the package name, but its klunky too.
I didn't (yet) see what debian is planning wrt this.
4...) Probably loads of other things that I've overlooked and/or can't
remember right now. But rather than try to write an all-encompassing
answer that eventually dies of old age unsent in my drafts folder (bad
habit of mine), I'm hitting send with this now to have something to kick
around.
Thanks for your time. I'm attaching Dennis' original patch. Just so you
can see what it does, not so that you can directly consider that as the
solution that will be necessarily eventually in upstream if you can
figure out a preferred means to generically handle multiABI.
FWIW, I'm going to have a stab at converting the existing arch-detection
(on linux) to use the auxiliary vector AT_* data. If that goes in, doing
the same for ARM should be a no-brainer (and well, can be of course be
done regardless of what other archs do)
- Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
