lkml.org 
[lkml]   [1998]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Today Linus redesigns the networking driver interface (was Re: tulip driver in ...)


On Sun, 20 Sep 1998, Donald Becker wrote:

> On Sun, 20 Sep 1998, Gerard Roudier wrote:
> > On Sun, 20 Sep 1998, Donald Becker wrote:
> >
> > > And you can fill in my usual flame about people writing drivers that use
> > > SA_INTERRUPT on shared interrupt lines. (Perhaps if they would have been
> > > called "ugly interrupt" instead "fast interrupt"...)
> >
> > There is no semantic problem for a driver to tell the kernel its interrupt
> > code is fast when it is _actually_ fast.
> > On the other hand, the fact that an IRQ may be shared is an hardware
> > requirement for PCI and a kernel not allowing this sharing is broken.
>
> Once the interrupt line is shared with PCI semantics, the handler chain no
> longer qualifies as "fast".

This FAST irq semantic is just shit. Any PCI interrupt handler is required
to be fast. In the irq handling specsless semantic FAST means that the
interrupt routine will be entered with interrupt disabled. I have seen the
change you mention in the 2.1 linux code. Note that this has been the good
effect to get rid of save_flags/cli/restore_flags on some SCSI drivers
that now uses some cleanly encapsulated verbs to protect internal data
structures.

> > Seems to me you are blaming SCSI low-level drivers without naming them.
> > The IRQ latency problem we observe in the SCSI layer is not the fault of
> > SCSI low-level drivers. Their _own_ interrupt code is generally _fast_,
> > as all interrupt code is required to be on a serious O/S.
>
> Yes, SCSI drivers are prime offenders. Many SCSI drivers use "fast"
> interrupt handlers and then do a bunch of work in the interrupt handler.
> (SCSI bus resets, disconnects, etc.)

Most donnot explicitaly in the interrupt routine. But the SCSI layer has
(had?) no real handle on the actual context it calls driver's entry
points. (At least in 2.0).

> The SCSI drivers have been a big support headache for me. Since they are
> initialized first they grab the interrupt with SA_INTERRUPT. Most people
> don't understand the resulting error, and those that do blame the Ethernet
> driver for not being willing to share the interrupt.

You were writing network drivers in the early time of the Linux network
code. Imagine people that want to port or write a SCSI driver for Linux,
once the specsless SCSI layer had been written.
The only way to know how things are to be done is to look into existing
drivers. Imagine that all (or most of them) are using SA_INTERRUPT). In
the early time I have ported the BSD driver I believed SA_INTERRUPT was a
requirement and even if it were not I did'nt want to do different.

So, you perhaps did'nt misanalyze the technical problem, but you were
barking at the wrong tree accusing low-level drivers instead of pointing
out the SCSI sub-system problem.

> > Your flames about IRQ handling hasn't have the effect you expected for the
> > simple reason they were not targetted to the right persons. It was a
> > kernel architecture issue and a SCSI generic layer driver issue and you
> > flames always were against the low-level drivers that were exactly the
> > _wrong_ target with regards to the problem.
>
> ??? I don't see that -- I still see it as a low-level driver issue. Don't
> use SA_INTERRUPT. The higher level issue is that you might want to restructure
> everything into a SCSI_BH manner. But even then, don't use SA_INTERRUPT.

I donnot care about SA_INTERRUPT. If I request a PCI interrupt I assume
that it may be shared by other PCI devices. If the kernel donnot want the
IRQ to be shared, it is a kernel bug or mis-design, IMO. I want to request
a PCI interrupt without any flags, since PCI IRQ sharing is a
_requirement_. In 2.1, it seems to me that this flags is properly ignored
when an IRQ is shared.
About the SCSI_BH, I already have reponded to you in my previous mail.


Regards,
Gerard.


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.240 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site