> On Sat, 19 Sep 1998, Theodore Y. Ts'o wrote:
>
> > SPL's are just completely braindamaged. Linux does the only sane thing,
> ..
> > Note that all of the post-BSD 4.4 implementations have abandoned SPL's
> > as having any kind of semantics related to priority. They just keep the
> > name SPL for historical reasons.
>
> I've written a few BSD drivers, and I agree. The spl() approach is
> awkward to implement and has serious performance implications for modern
> machines. It's clear that BSD was designed for machines of a different era.
[ I may be wrong here, since I donnot consider my-self as a kernel guru ]
On architectures where consistency is maintained between Hardware
Interrupt Levels and CPU Execution Levels with regards to interruptible
code, you can design kernel data structures so that the actual execution
Level ensures integrity without additionnal synchronisation. When the
hardware does not implement such a mechanism or when SMP is not consistent
with it, you may want to implement it from software, but even, in the case
it is feasible, such an approach can only be bad for latency and
performances.
[ ... ]
> > The one thing which the BSD implementations have that we *don't* have is
> > the ability mask just one kind of interrupts (say, serial or networking
> > interrupts) during some critical section of code. The only thing we can
> > do is use cli(), which blocks all interrupts.
>
> Hmmm, I don't know if that's a valid point.
> We have busses with shared interrupt lines and multifuction boards.
> Masking and priority are no longer viable design assumptions.
[ Here is my opinion and perhaps some experience ]
The spl mechanism encourages to access data structures, assumed to belong
to a given level (or subsystem), directly across layers, without using
opaque interfaces. It also encourages to do more work than needed under
interrupt since not all interrupts are masked. I want to write that it
leads to bad designed drivers. For example, when you port some BSD kernel
code to another system that donnot have spl's, this design may lead to use
cli/sti pairs (or equivalent) that are worse.
An interrupt routine gets the driver instance as argument and shall only
assume that it will not be reentered for this instance. It should not
need to cli/sti except for serious error handling or to deal with broken
hardware. It shall access kernel data structures and services through
opaque interfaces that are required to handle appropriate synchronisation
when needed. Any kernel service callable from interrupt context must be
fast, or at least fast when it is actually called from interrupt context.
> > So one of the things which the BSD networking stack can do is to (in
> > some critical section of code), prevent network interupts from being
> > handled. If a network interrupt comes in during the critical section of
> > code, it is queued, and would be executed only after the networking code
> > had unblocked network interrupts. (However, if a disk interrupt
> > happened during the critical section, it would be handled.)
>
> This leads to a great example of my previous point. AMD and Symbios have
> multifunction SCSI+Ethernet PCI chips. 3Com has Ethernet+Modem cards.
> Both functions share a single interrupt pin. It's no longer possible to
It you are right here, these dual function boards are _not_ PCI compliant.
Function 1 shall use INTA line and function 2 shall use INTB line.
You may configure IRQ routing to share a single IRQ for the 2 functions of
a dual-function PCI device, but this is not required.
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/