>>>>> "Markus W" == mw  <mw@eunet.ch> writes:

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

Markus W> The one thing I think is pretty hairy in this approach is
Markus W> that level-6 (thus pretty important, at least for the clock)
Markus W> interrupts should be indirectly caused by lowest-level
Markus W> interrupts (softint).

I've been on holiday for a few days and thought some more on this
matter.  I've decided to implement something like this:  First,
register EXTER interrupt handlers in any of six linked lists, one for
each IPL starting from IPL 1.  Then, in the INT6 handler:

	Save interrupted IPL in saved_IPL (a global)
	Block EXTER interrupts
	for (level = 6; level > saved_IPL; level--, spln(level))
		walk registered ISRs for this level
	if there are not registered ISRs at or below saved_IPL
		saved_IPL = 0
		unblock EXTER interrupts

In splx, prepend code like this

	if (saved_IPL)
		level = saved_IPL
		saved_IPL = wanted IPL
		for (; level > saved_IPL; level--, spln(level))
			walk registered ISRs for this level
		if there are not registered ISRs at or below saved_IPL
			saved_IPL = 0
			unblock EXTER interrupts

This ought to handle all situation "the right way" (tm), unless I've
made some serious oversight.  Sure, it adds some cycles here and
there, but I can live with that (remember, noone needs to adopt my
implementation).

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

Maybe, but if you look at my scheme and considers the case that there
are no ISRs registered at level five or six, there won't be too many
cycles spent before lowering the IPL to 4.  I suggest you try my
implementation when I have finished it, to see if I've broken your
serial baby :-)
>> >> slight optimization, but it also makes things simpler in the
>> >> source.  I also like to start a discussion on how a new interrupt

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

Oh yes!  Remember the source I use is almost plain i386/isa drivers
like com.c, lpt.c, if_ed.c etc.  Esp. in the if_ed.c source it's not
entirely clear on how much state from the NIC that need to be saved
and posted to the sicallback.  I really want to get into the edintr
routine at splimp!!!

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

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

This would require even more tweaking of the if_ed.c source I think.
Is that polling rate really enough for a network card with 8K of
buffer space (or was it 16)?

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

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

But you do, you run hardclock below your serial receiver...  That
might make your clock drift, no?  I meant I don't need to run
hardclock at IPL 6 neither, I happily run it at IPL 4, like you, but I
*do* like the possibility to configure my drivers to run at any level
*I* like.

Anyway, I'll soon have something to try out, stay tuned.

Niklas