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

Alan Cox (alan@lxorguk.ukuu.org.uk)
Sun, 20 Sep 1998 20:17:40 +0100 (BST)


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

Rephrase that a little - A lot of code wants to claim multiple spin locks
with the _minimal_ local IRQ safety neccessary to realise the requirement.

Try something conceptually more like this sort of scheme. That gives you
minimal degrees of IRQ locking, and also hides the issues of irq sharing
nicely from drivers themselves.

inline int smartlock_add_irq(struct smartlock *s, int irq)
{
atomic_inc(&s->irq[irq]);
atomic_or(&s->bitmask, 1<<irq);
}

inline unsigned long smartlock_claim_irqmask(struct smartlock *s)
{
unsigned long flags;
save_flags(flags);
__local_mask_irqs(s->bitmask);
here:
if(interrupts_running[smp_this_cpu()].mask&~s->bitmask)
printk(KERN_ERR "BAD lock at %p %X %X\n",
&&here, interrupts_running[smp_this_cpu()],
s->bitmask);
spin_lock(&s->lock);
return flags;
}

> Linux very obviously already supports the "disable_irq(irq)" notion,
> and it should work correctly these days now that we understand better

What happens on a pending IRQ that is disabled. Are the semantics of
disable_irq() reliably one of 'leave pending' or 'drop' ?

Alan

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