On the other hand, if 2.0.x is fundamentally broken in this regard,
then with 2.1.x (or at least) 2.3.x we don't want to chain ourselves
to a broken interface. We may be faced with the necessity of having an
incompatible interface. FS code has had to live with a changing API, I
don't see why SCSI or network drivers should be treated differently.
That said, however, you can read "remove SA_INTERRUPT" as:
#define SA_INTERRUPT 0
and that shouldn't break any drivers, right? Ignoring the corner-case
where a slow CPU is killed by tons of interrupts, and for that the BH
limiting scheme below should solve this.
Does that sound like a reasonable approach?
> > return a flag indicating that it doesn't want bottom halves called?
> > The semantics could be either:
> >
> > - I didn't do anything that requires a BH
> >
> > or:
> > - I'm being called so fast that BH processing may kill the machine.
> >
> > With the latter semantic perhaps an alternative would be for the core
> > interrupt handling and dispatch system to take note of interrupt
> > flooding and start dropping BH processing. If the code to implement
> > this can be fast enough, would this be the answer to SA_INTERRUPT?
>
> I think this is the path Linus is headed down in 2.1 already. It just isn't
> all the way there yet.
Really? Looking at kernel/softirq.c I don't see that. Where should I
cast my gaze?
Regards,
Richard....
-
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/