Long ago, Acorn decreed that the top four bits of a (24-bit) SWI number
should indicate which operating system the SWI was for.  RISC OS set this
field to 0, and RISC iX set it to 8.  Later, Linux used 9, and ARM use F
for OS-independent SWIs.  Until now, NetBSD/arm has used 0, but I'd like
to change this.

My main reason for wanting this change is to make it sensibly possible to
do RISC OS binary emulation.  Riscose[1] is a project to do this, and it
relies on a process's being able to trap RISC OS SWIs called from its own
address space, and remap them into Unix system calls.  Obviously, this is
a lot easier if RISC OS and native SWIs don't overlap.

The actual changes required to implement this change are minimal.
syscall() would need to allow the new SWI base alongside the old, and
lib/libc/arch/arm/SYS.h would need to be changed to generate the new one.
Obviously to allow RISC OS emulation, a process would need some means to
switch off support for the old base, but this isn't so immediately
necessary.

Anyone have any objection to this?  If not, we just need to pick a base to
use.  I'm not sure if anyone's still allocating them, but if not, I'd
propose B (for BSD, of course).

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>