In message <2181.820275139@NIAGARA.NECTAR.CS.CMU.EDU> you write: 
> As noted, this is already possible on the i386.

Hmm, I must have missed that.  What should I look at to find more info?

> On the Alpha, there's no such thing as "I/O space."  Everything is
> memory-mapped.  (hey, gotta do _something_ with that big address
> space, right?  8-)  To do something like the i386 inb and outb, you

_good_ :)
IMHO it's better to let one mechanism (VM/pgtbls) perform access control
than to have two.  AFAIK, the m68k is also memory-mapped I/O as well.
Seems the ix86 is the odd man out -- no suprise there. :)

> need to map the right chunk of memory (changes per bus interface
> chipset),

This isn't too bad.

> and then do the right things in that memory space (again
> potentially bus interface chipset -dependent, and it's not even a
> 1-to-1 mapping of memory to I/O ports -- the alpha doesn't support
> byte load and store).

This makes things hard.

> It's worth noting that i don't think that user-level device drivers
> _can_ be useful w/o the ability to handle interrupts...  and there's
> currently no facility in place to allow that.  (I'm not even sure
> how one could "reasonably" allow it in BSD, for (level-sensitive) PCI

Yeah, the more I think about it, the more it seems like it would be
incompatible with standard Unix kernels.  It is, however, interesting to
find out how far Unix will stretch before you have to switch to something
else - I'm not willing to give up my coding environment just yet :)