If you make this sort of change to cli(), it can cause other problems.
There are times when a driver really needs to stop ALL interrupts on the
current CPU. This is where I've been using sti() and cli().
I've got a case in the driver I'm working on. I have two operations to the
device that must occur within ~45 uSeconds of each other. The closer they
are spaced, the better. If I get interrupted between the two operations,
this code will fail. The operation almost always takes less than 6 uSeconds,
maximum of 50 uSeconds.
In this case, I would have to lock out even the RT stuff, since that could
easily exceed the ~30-40 uSeconds of slop I have.
If we go back to the original code example:
spin_lock_irqsave(...)
Sit around
spin_unlock_irqrestore(...)
The problem with this is that when you make the spin lock, you never
indicate what IRQ level the lock has to protect against. If you initialized
the spin lock with it's interrupt number, the M68K and SPARC code could do
the IRQ save based on that. Everything would run better on these systems.
Unfortunately, all spinlock creation code would have to change.
Instead of:
spin_lock_init(&lock);
you would do:
spin_lock_init(&lock, (struct pci_dev *)->irq)
or it's equivilent. Use an interrupt number of 0 to indicate it is never
called from interrupt.
On the good side, this would allow you to make spin_lock() automatically
decide if it should be spin_lock() or spin_lock_irqsave(). We could get rid
of the spin_lock_irqsave() and spin_unlock_irqrestore() routines by making
spin_lock() and spin_unlock() look at if the mutex can be called from
interrupt or not.
BTW: This is what Solaris basically did when they got rid of spl(). They use
an interrupt cookie, but the idea is the same.
-Bret
-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity
Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.com
-------------------------------------------------------------
-
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/