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

>> It was config.new that was busted!  In my config.new/sem.c there
>> are uses of the constant "8" instead of MAXPARTITIONS.  When I
>> found this and changed it everything worked OK!  I wonder if this
>> is fixed in -current?  I'm still at 941225 sources.

Markus W> Hm, I'm running off 941221 sources, but I think I should
Markus W> have noticed such a problem as well??? I'll have a look at
Markus W> it at home..

Perhaps your root is on sd0 or generic?  Then you wouldn't notice, I
think.  My root is on sd1a and swap on sd1b and sd2b.

>> travelling without net-connectivity until Monday).  One thing I
>> thought about: Is it really necessary to schedule an AUD3 int?
>> Wouldn't it just suffice to block INTF_EXTER, pop the saved a0,
>> keep the interrupt frame we have and lower the PSL directly
>> instead.  A

Markus W> I thought about that as well, problem is: the level-6 int
Markus W> will interrupt any code running at lower priority, thus if
Markus W> some code segment tries to do this:

Markus W>      x = splclock(); do something atomic splx(x);

Markus W> you'll defeat the meaning of raising the IPL, since you WILL
Markus W> interrupt that code segment with a level 6 interrupt,
Markus W> lowering IPL to 4 afterwards will not make that go away
Markus W> unless you uncouple the two interrupts truely. That's why
Markus W> I'm generating a fake level 4 interrupt.

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;
This way the scheme comes to look like:

INT6 entry
	save regs
	for all INT6 devices
		if this device needs servicing at an IPL above the one
		in use before this INT6 were trapped
			put into a priority queue based on wanted IPL
	block INTF_EXTER
	for all devices in the queue above in priority order
		set spl for the current device
		run the handler
	raise to spl6 again
	unblock INTF_EXTER
	if there are devices left wanting to run at an IPL equal to or
	below the one in use outside this frame
		schedule a si_callback, where the callback does an
		custom.intreq = INTF_SETCLR | INTF_EXTER;
	restore regs
	exit interrupt frame

Comments?

Of course this prevents drivers wanting to run at IPL 1 but I can live
with that!  This also requires the si_callback to use a constant pool
(I use this today anyway) or running malloc of IPL 6 which will affect
other archs, thus not a good idea.  Anything more I haven't thought
about?

>> slight optimization, but it also makes things simpler in the
>> source.  I also like to start a discussion on how a new interrupt
>> handling system should look like.  Many of us have been aware that
>> we need a

Markus W> A new one? Oh, is there one right now...? :-) Yeah, we
Markus W> definitely need one...

Good!

>> registration possibility, but Markus' changes also shows of the
>> interrupt remapping potential, could we make this somewhat more
>> 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.

Markus W> Problem is (pretty specific to the serial interrupt) that
Markus W> you can't have almost anything reasonable at ipl-6 without
Markus W> considerably bothering the serial-driver. One possible
Markus W> approach I could see for drivers like the serial driver, but
Markus W> running off ipl-6, would be to do the thing you suggested at
Markus W> the beginning, have the ipl-6 handler lower ipl to 4, and
Markus W> execute the driver with the interrupt itself being
Markus W> blocked. Note that you do this ONLY with interrupts that
Markus W> don't interact with the rest of the system, as the rest of
Markus W> the system won't know how to protect itself against
Markus W> interruption from such a driver.

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
si_callback.  The state saving is really a problem to me as I want to
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...

Niklas