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, Geert Uytterhoeven wrote:
> > Almost every cli in the kernel is in fact really
> >
> > block_interrupt(dev->irq)
> > something
> > unblock_interrupt(dev->irq)
> >
> > Where dev->irq is the device irq.
>
> #ifdef __i386__
> #define block_interrupt(irq) save_flags(flags); cli();
> #define unblock_interrupt(irq) restore_flags();
> #else
> #define block_interrupt(irq) sane_block_interrupt(irq);
> #define unblock_interrupt(irq) sane_unblock_interrupt(irq);
> #endif

No, this really is basically broken. It's broken for two major reasons:

- a lot of code wants to block _multiple_ interrupts. And they really
shouldn't know about that. For example, the networking code would have
to block interrupts from all network devices that could be implicated,
in addition to blocking the timers.

And trust me, it's too easy to get wrong.

Linux very obviously already supports the "disable_irq(irq)" notion,
and it should work correctly these days now that we understand better
how the silly IO-APIC works (and most other architectures have much
saner interrupt controllers that are better documented). So the above
feature really does exist already.

However, that feature is really meant more to be used by device drivers
etc for their internal use, rather than for "generic" code.

- generic code really shouldn't care about issues like what interrupts
handle networking. More importantly, as Donald Becker pointed out,
there really _is_ no sense of "one interrupt, one device". That's a
notion from the 70s, we've gone past that. And I don't want to have
Linux to have a broken architecture that doesn't match reality.

So how to do this? The only sane answer is, and has always been, to just
minimize the critical regions. People who want "[un]block_interrupt()"
just want to write bad code. The real solution is to just make sure that
you do 99% of all your work using completely "local" resources, and then
there is a very small and well-defined critical section where global
resources are handled. And then you use spinlocks or similar
synchronization means.

The Linux netowkring use of a bottom half handler is extremely efficient:
it allows for very simple locking constraints, and the only problems I see
are really (a) SMP scalability (and quite frankly, I suspect people talk
more about this than is true - I doubt it's really an issue for us right
now, and won't be until we scale better in other areas) and (b) suboptimal
implementation.

Linus


-
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.136 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site