Re: L4-Hurd; L4 interrupts and I/O

[Peter 'p2' De Schrijver]

Hi,

> 
> 
> 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

Yes. That's the way to go in my opinion.

> 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.  
> 

device drivers should indeed only talk to deva in the end. But deva
doesn't exist yet. So for prototyping it might make sense to go directly
to physmem.

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

Yes.

> 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?
> 

Yes. Pistachio works this way. The previous L4 version from the Karlruhe
people (Hazelnut, iirc.) did not AFAIK (I never looked in detail to the
interrupt handling in Hazelnut). It does make L4 a little more platform
dependant, as different platforms can use the same CPU but a different 
interrupt controller. 

Cheers,

Peter.

signature.asc
Description: Digital signature