> I see, maybe we can check what the IPL was before the INT6 in order to
> protect us from this.  Things get hairy then, if we are not to lose
> interrupts.  We need to schedule a delayed INT6 interrupt which could be
> issued by an si_callback.  Like this: custom.intreq = INTF_SETCLR | INTF_EXTER;

The one thing I think is pretty hairy in this approach is that level-6 (thus
pretty important, at least for the clock) interrupts should be indirectly
caused by lowest-level interrupts (softint). I don't know whether that's a
possible scenario, but imagine:
  ... running at spltty ...
  s = splclock();
  .. do something hairy in here ..
  <--- gets hit by a clock interrupt, your code detects it was interrupting
       a high-level interrupt and will reschedule itself by softint
  s = splx(s);
  ... running at spltty ...
now, as long as that code is within spltty, your callback will never be
executed, and you'll miss the interrupt. By using the indirection interrupt,
you'll wind up in the interrupt handler as soon as the IPL is lowered enough,
just like it should be.

Otherwise, the only objection I have against the dispatcher is my fear that
it might be too much burden for a level-6 handler, causing the serial driver
to miss characters again (there's not much time allowed to steal from the
serial interrupt until it starts losing characters). 

Sorry if I might sound a bit silly about the serial port, but I'm REALLY happy
this baby works as fine as it does now, and I don't want to lose that again:-)

> Of course this prevents drivers wanting to run at IPL 1 but I can live

Sure:-)

> >> slight optimization, but it also makes things simpler in the
> >> source.  I also like to start a discussion on how a new interrupt

Eh, you don't claim the above approach is simpler? It might look more
elegant, but I'd severly doubt it's simpler :-)

> >> flexible to use at a driver level?  Suppose, we still want some
> >> INT6 device preempt the serial interface, but lower most other INT6
> >> devices.  Think about it, I will.  I may volunteer to write
> >> something, but I would like a consensus on what needs to be done.

I'd think a more general interface could be useful, but could we run this
at IPL4 please? :-)

> Why I bother is that I want to retain splimp at spl3 but still run
> network devices of INT6 without resorting to saving state and doing an

Might be a cruel idea, but why don't you poll those interrupt registers
in a VBL-handler? VBL runs off spl3 ... In fact, there might even be some
facility like si_callback's already implemented for the vbl-handler, I'd
have to check...

> use i386 ISA drivers without big source changes.  I really don't need
> anything running at IPL 6, I don't even mind clock skew...

Hm, I think the clock is something pretty central, and I wouldn't like the
idea of skrewing with it...

-Markus
-- 
EUnet Switzerland   Tel:     +41 1 291 45 80	Markus Wild
Zweierstrasse 35    Hotline: +41 1 291 45 60	mw@eunet.ch
CH-8004 Zuerich	    Fax:     +41 1 291 46 42	S=mw;P=EUnet;A=EUnet;C=CH
>Solaris 2 is not an upgrade from Solaris 1. They just want you to THINK it is.