Messages in this thread | | | Date | Wed, 10 Nov 1999 11:23:33 +0100 (MET) | From | Roman Zippel <> | Subject | Re: linux interrupt handling problem |
| |
Hi,
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/
| |