So, even after much work to deal with the packed-enum issue, there are
still problems in the source tree with packed-enums.  Finding them all
is going to take a long time.

In addition, ARM still hasn't finalized the eABI.  We'd like to comply
with it, but at this point, we have no guarantees that ARM won't flip-flop
on packed-enums, thread-local-storage, etc.

I did not anticipate this much lossage when I previously advocated sticking
to the ARM eABI.

So, after discussing this situation with Ben today, I'd like to propose
the following:

	* Effectively reject the ARM eABI at this time, instead picking
	  our own sane ABI.  This means not using packed-enums (I actually
	  backed out the packed-enum change to the compiler a few minutes
	  ago), and picking our own thread-local-storage register now.

	* Mark our ELF objects/execuables as ELFOSABI_NETBSD, to distinguish
	  it from the official ARM ABI.  This is the correct use of the
	  EI_OSABI field in the ELF header.

	* When the ARM eABI is finalized, add support in our dynamic linker
	  for allowing only objects of the same EI_OSABI to be linked.
	  This allows us to support the ARM eABI in the future.

Ben pretty much agreed with this proposal.  I'd like to get buy-in on this
SOON so that we can actually release all of our ARM platforms in 1.6.

If we do decide to go this way, the only thing to do is pick the thread
local storage register... sounded like ARM was thinking of r9 or r10.
I say we just pick r10.

Comments?

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>