>>>>> "Timothy" == Timothy Newsham <newsham@aloha.net> writes:

>> system should look like.  Many of us have been aware that we need a
>> 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

Timothy> Why do we need registration possiblities?  (I dont doubt that
Timothy> its needed, I'm just wondering what for).

Loadable device drivers.  You have yourself written onesuch but that
was a bit special since it replaced another system supplied handler.
Normally a driver handling some board wants to chain into a sequence
of interrupt handlers.  Now, when you add an INT6-handling device
driver, you also need to alter locore.s in order to ensure your
interrupt handler will be called.

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

Timothy> Couldn't you make a queue of interupt jobs and then have
Timothy> handlers which just determine what the type is and then
Timothy> schedule their job on the queue?  When interupt jobs start
Timothy> running they could raise the spl to whatever level they
Timothy> choose and then lower it when they see fit.  It would be
Timothy> fairly easy to implement although less optimized than the
Timothy> current scheme.

I have played around with this (it's called si_callbacks in the Amiga
port of NetBSD) and found it to have a few problems.  One is that in
order to make the queue dynamic, malloc's spl level must be raised.
Another (the important fact for me) is that porting of i386-drivers
need to have the interrupt handlers rewritten as state must be saved
before scheduling the job on the queue.  This has proven to be
error-prone.  Markus' way of actually blocking the higher interrupts
through Amiga's hardware has enabled me to run without si_callbacks
which in turn made the original interrupt handler code just work
(well, not quite, I also raised splimp to spl4, but this could be
circumvented by a slight redesign of the scheme used).  Maybe this
could have been achieved without Markus' changes by raising splimp to
spl6, but then serial input would have suffered even more than today.
I think a small interrupt poll routine for each driver could be used
to identify which driver needs servicing and then each interrupt
routine could be run at the correct spl with INTF_EXTER blocked.  That
way state need not be saved.  Like this:

INT6 entry
	save regs
	for all INT6 devices
		if this device needs servicing
			put into a priority queue based on wanted spl
	block INTF_EXTER
	for all devices needing service in priority order
		set spl for the current device
		run the handler
	raise to spl6 again
	unblock INTF_EXTER
	restore regs
	exit interrupt frame

Someone got something to say about this proposal?  I'm willing to
implement something like this if we get a consensus.

Niklas