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

[Marcus Brinkmann]

On Tue, Jan 20, 2004 at 08:27:31AM -0700, Christopher Nelson wrote:
> 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.

Note that this is the plan.  In the current implementation all tasks can
access all I/O ports.  No, we should not rely on that behaviour :)
 
> 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?

Wortel owns them initially.  We can pass them through to deva at startup.

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

The DDF will _always_ go through deva for such things.  This is because the
DDF will not make use or require the Hurd capability system, which physmem
provides.

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

Well, deva can get all I/O ports mapped into it at startup, I guess.
 
> 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?

You might want to reread my previous answer.  L4 can only do what is generic
and the same on all systems, re-enable the IRQ in the IRQ controller.  But
what Peter says is that sometimes, before that, special ACKs are required
that are device specific etc.  L4 does not do that.

So a driver might need to ACK the IRQ at the device level before you
reenable the hardware interrupt.

This is straight from Peter, I am just passing it on, but all errors are
mine :)  (I rephrased it).  Thanks Peter!

Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/