Re: Today Linus redesigns the networking driver interface (was Re: tulip driver in ...)

Richard Gooch (rgooch@atnf.csiro.au)
Mon, 21 Sep 1998 12:03:03 +1000


Doug Ledford writes:
> Richard Gooch wrote:
>
> > > As I wrote to someone else, most device drivers are multi-kernel drivers.
> > > In that scenario, it doesn't help to change things. It doesn't solve the
> > > 2.0.35 IRQ conflicts when this type of thing happens.
> >
> > 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.
>
> No, I fully agree with you that we shouldn't chain ourselves to
> something, I was just pointing out that there is an actual reason to
> argue over the correct usage of SA_INTERRUPT in 2.0.x since many of
> us are still maintaining drivers there. My original arguments were
> basically that I don't think SA_INTERRUPT really buys a SCSI driver
> anything so I personally thought Gerard should take it out of his
> driver since doing so would solve other problems. However, if the
> ncr cards can generate as many as 10,500 interrupts per second,
> maybe his driver does need the SA_INTERRUPT flag :)

Or a mechanism to say "don't run BH when I'm done". Having
SA_INTERRUPT=0 in 2.1.x or 2.3.x would be safe if we can throttle BH
processing, right?

> > 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.
>
> We haven't been :) After all, we have the new_eh code in there :)

Erm, I assume you mean "new_bh"? Or is "new_eh" something I've missed?

> > > 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?
>
> Sorry, I should clarify that. The code is headed in the direction of
> SA_INTERRUPT being meaningless. Not that something else has been put in
> place to replace it. It no longer does a lot of the things it used to do.

Ah, OK. So do you feel that a mechanism in BH processing to
self-throttle is a good approach?
If so, a patch for 2.3.x may turn up...

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/