Subject: Re: I/O maps and user-level device drivers
To: Travis Hassloch x231 <travis@EVTECH.COM>
From: None <Chris_G_Demetriou@NIAGARA.NECTAR.CS.CMU.EDU>
List: tech-kern
Date: 12/29/1995 17:12:19
> In message <9512090904.AA00970@bunya.awadi> you write: 
> > According to Travis Hassloch:
> > The granuality of the I/O permission map is on a byte level.  Each bit
> 
> > I think a system call would be the best way - not sure if you want to
> > make the caller specify the entire permission map they want or have a
> 
> Anyone feel strongly either way about adding this?

As noted, this is already possible on the i386.

However, I will add something new to this discussion:

the way it's done on the i386 is inadequate.

In particular, some DEC Alpha systems have multiple _primary_ PCI
busses, and the notion of 'inb' and 'outb' with their current
arguments just Don't Work in that case.  (Additionally, they're _very_
badly named; why are bus-specific functions named after the
instructions that implement them on one particular architecture?)

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
need to map the right chunk of memory (changes per bus interface
chipset), 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).

Thus far, the best thought i've had on how to do this sanely are to
have ISA, etc., busses provde "/dev/isa0", etc., device nodes, which
one can then access in a variety of ways...


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
busses, unless the user-supplied interrupt handler ran with some or
all interrupts blocked...  "yech.")



chris