On Tue, 9 Nov 1999, Linus Torvalds wrote:
> > That's the software version of priorities, on m68k this can be realized in
> > hardware with 7 levels,
>
> No it isn't, and no it can't.
>
> The local vs global is much more than interrupt levels, it's really about
> conditional code where "sti()" behaves very fundamentally differently
> inside an interrupt handler.
>
> The m68k irq levels are just another interrupt controller. A very stupid
> one, admittedly, but an interrupt controller none-the-less.
No, it's definitly not stupid, it was only developed at a time Linux
didn't exist yet... and you can still use an external interrupt
controller, but there is no standard for this m68k machines as there is
on intel machines.
Anyway, what worries me is the portability issue, without the need for us
to add lots of portability code. I would like to change the definition of
a portable interrupt handler. Most important it shouldn't change the
interrupt context, except with save_flags()/cli()/restore_flags() (or the
appropriate spinlock variant). Everything else should only be a _hint_ to
the architecture depend interrupt code, which can decide (and usally
knows it better), if and how something is possible.
Possible hints could be:
- This interrupt handler has tight interrupt constraints (SA_INTERRUPT)
- timing critical interrupt code follows (former cli() e.g. in the ide
driver)
- non-timing criting interrupt code follows (former sti())
This would have the nice sideeffect that interrupt tuning could be done at
a central, architecture dependent place, it's not hardwired in the drivers
anymore and we could develop a single tool to tune interrupts (and not to
put in other tools like hdparm). That means it would give the advanced
user the possibility to tune his system for every interrupt and it
wouldn't change anything for the normal user as we would use the hints
from the drivers.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/