Messages in this thread |  | | | Date | Sun, 26 Apr 1998 21:16:36 -0700 (PDT) | | From | Linus Torvalds <> | | Subject | Re: [patch] io-apic-2.1.98-B |
| |
On Sun, 26 Apr 1998, David S. Miller wrote: > > I'd like to have the self-IPI part, but I would _really_ really > prefer to not have the counter, until somebody convices me that it > has to be there (and that implies giving a reason other than "some > ne2000 card has problems", because the problems you see sound like > they might be problems for other people regardless of any io-apic > issues). > > Ok, but one question, to a clueless driver developer, what should we > expect him to think that:
Note that the counter I was talking about was the "counter of delayed interrupts", ie the counter that tells us how many interrupts happened during processing of another interrupt or during "disable_irq()". I think that counter should not be a counter at all, but a single bit of information, because that is how the hardware does it for all other cases where we disable interrupts.
> disable_irq(x); > ... some stuff ... > disable_irq(x); > ... > enable_irq(x); > ... some stuff ... > enable_irq(x);
The nesting of disable/enable_irq() is a totally different issue, although there too I think that the counter is (a) not very useful and (b) not how it has ever beed done before.
However, for this case I don't actually care all that much, because nobody should be using nesting anyway, and as such I prefer it to not be a counter.
> does? On the Sparc we treat it the way you think it should work > (enable_irq() turns it on and no depth checking is done) however our > case is different since we've written and maintain all our drivers and > like to not think of ourselves as clueless driver developers ;-)
Just wait for when the Sparc enters the real world instead of the little sheltered play-pen of Sun.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
|  |