L4-Hurd; L4 interrupts and I/O

[Christopher Nelson]

>> The information about low-level hardware in a PC system is somewhat 
>> dated. It is no longer the case that a PC has two 8259 interrupt 
>> controllers, and has not been the case for some time. Instead, there 
>> is an integrated I/O controller that can APPEAR to behave like to
8259's.
>> In any case, why do we care about that? L4 handles all that sort of 
>> stuff and reflects interrupts back to user space.

>As far as I am aware, it does not acknowledge them for you at the
CPU/device level, which is what the paragraph you 
>refer to is concerned about. I can not verify what this part of the
document says, but if you are concerned about it, 
>please start a new subject, and maybe include address@hidden (Peter 'p2' De
Schrijver) and address@hidden (Daniel Wagner).



Under I/O ports in the L4 v.5 spec, it says that:

On ia32 processors, IO-ports are handled as fpages. IO fpages can be
mapped, granted, and unmapped like memory
fpages. Their minimal granularity is 1. An IO-fpage of size 2s0 has a
2s0 -aligned base address p, i.e. p mod 2s0=0.

IO-ports can only be mapped idempotently, i.e., physical port x is
either mapped at IO address x in the task's IO address
space, or it is not mapped at all.

So does this mean that the deva "owns" all I/O ports until requested by
some device driver to hand-off responsibility for that port?  It would
seem to be a good way to manage resource control and contention.  It
would also make sense to have device drivers go through deva instead of
the physmem server directly b/c deva could implement policy decisions if
it wanted to.  

Does this also mean that deva still has to ask wortel to perform the
operation for it?

Also, 7.2 Interrupt Protocol says:

Interrupts are delivered as an IPC call to the interrupt handler thread
(i.e., the pager of the interrupt thread). The interrupt is disabled
until the interrupt handler sends a re-enable message. 

So L4 seems to handle all the dirty issues of interrupts for us.  It
seems to me that it would be strange for the kernel to NOT handle
interrupts for us, since then some software would have to know a lot
more about the architecture that it's being run on that it ought.  Isn't
that the kernel's job?

        -={C}=-