thorpej@wasabisystems.com said:
> 	* 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. 

OK, here's a counter-proposal:

1) We implement 1.6 with a *temporary* ABI, that doesn't use packed enums, 
or a TLS register.
2) We do not mark the executables (or object files) with the 
ELFOSABI_NETBSD value (we leave it at 0).
3) For 1.7 we adopt the full eABI (assuming that it really is published by 
then -- I expect it to be).
4) We continue support the 1.6 abi by using an emulation for it, as we 
would for a linux executable etc.
5) For the 1.7 ABI (or whenever we get to the final ABI) we DO set 
ELFOSABI_NETBSD, so that we can distinguish the two sets of executables.

the implications of this are that object files for 1.6 and 1.7 won't be 
compatible, but executable images will still work.  A person upgrading 
from 1.6 to 1.7 will have to install compatibility libraries, as they 
would if installing Linux support.

This would mean that eventually the need to support the incompatible ABI 
will go away and we will be left with a conforming system.  I can't be 
certain, but I suspect that the number of kernel calls affected by enums 
would be small to zero, so the overhead of supporting old applications in 
the kernel will be minimal.

Finally, we document that this is what we are doing, so nobody has the 
right to be upset after the fact...

R.