George G. Davis wrote:
On Fri, May 15, 2009 at 02:55:57PM +0100, Ben Dooks wrote:
On Fri, May 15, 2009 at 02:51:05PM +0100, Jamie Lokier wrote:
Eek, can you say a bit more about the ARM EABI mismatch?
I would like to run a shiny modern ARM EABI kernel and userspace, but
also need to run one or two OABI binaries (from the gcc 2.95 era) on
the same kernel which I cannot recompile because they're built with
closed source libraries only supplied as OABI.
Does that not work at all?
There are a few ioctl() incompatibilities between the two ABIs, the
main problems are within the ALSA API. Mostly it will work, but there
are a couple of caveats.
Right, you can run ARM OABI binaries on an ARM eABI kernel by enabling
OABI_COMPAT. However, as Ben notes, there are (more than, IMNSHO ; )
a couple of caveats. Most of the easy ABI compatibility fixups
should be handled already via OABI_COMPAT. However, it's practically
impossible to fixup all OABI/eABI compatibility issues due to register
assignment, parameter alignment and/or packing differences between
the two ABIs. You would have to analyze all kernel and driver
user interfaces to reassign parameters to registers, align and/or
repack data structures, etc.,. In fact, some of the existing fixups
include side effects that in some cases can cause userspace code to
fail, depending on how it is using I/O parameters, e.g. in some cases,
library code may try to validate parameters which are relocated and
those tests fail due to reshuffling of parameters. It's a nasty
path to go down, quite frankly. I would not recommend trying to
support OABI binaries on an eABI kernel using OABI_COMPAT.
Structure packing: Isn't that basically the same set of fixups that
need to be done for 32-bit compatibility on 64-bit kernels? Could it
even use the same code - sneakily replacing 32 with OABI and 64
with EABI?
Register/parameter assignment: How is that relevant to the kernel
interface, if the kernel itself and modules are all EABI? The system
call interface is a fixed set of registers.
It sounds like you're saying I should use OABI kernels and userspace
even with latest kernels, if I have a single OABI binary that might
use anything interesting from the kernel, like readdir, poll, signal
context, ioctl, device read/write, or any other system calls which
take a struct that isn't all 32-bit words.
-- Jamie
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
