> 
> 
> The goals of this proposal are to:
> 
> 0) Define a machine-independent mechanism for handling soft
> interrupts.
> 
> 1) Generalize soft interrupts so that they can be used *any* time a
> low-priority callback is needed.
> 
> 2) Allow dynamic registration of soft interrupts, for loadable drivers
> and protocol stacks.
> 
> 3) Allow prioritization and fair queueing of soft interrupts.
> 
> 4) Keep the run-time cost minimal while still meeting the above goals.
> 
> 5) Permit, where applicable, handling soft interrupts via the same
> mechanism as hard interrupts, to reduce code complexity.

Sounds good, and the implimentation sounds reasonable.

I only have two questions:

1) On systems, like mac68k, where we use silos for tty input, wouldn't
it then be appropriate to define spltty == SPL_SOFTSERIAL? I think
so, but just wanted to ask.

2) How would such a setup relate to an SMP system? I realize we
don't support SMP now, but I think it's a good eventual goal (especially
as MP machines are getting more common w/ PowerMacs - they're still rare,
but not as rare, and if you've got one, you'd really like to use it).
If we're eventually going to support SMP, then shouldn't we be thinking
about it now, just so we don't impliment things which are quite painful
to undo later?

> The rationale for allowing softintr_register() to not execute the
> interrupt immediately is as follows: Soft interrupts are used as
> callbacks for hard interrupts.  Since a soft interrupt is always
> registered from a hard interrupt routine, it is always blocked at the
> time it is registered.  Therefore, softintr_register() will always be
> used when the interrupt is already blocked, and doesn't need to check
> this case.

Sounds quite reasonable.

Take care,

Bill