> As soon as a false alarm occurs, we already own the semaphore, and so we
> spin forever. Before semaphores went recursive, this wasn't the case.
I thought you got a process in D state. Better this though ;).
> I'm using semaphores rather than (say) waitqueues because I don't want to
> lose any interrupts through things like this:
Infact agreed. BTW looking at the ieee1284 code it seems we need a new
down_interruptible_timeout() ;).
> void irq_handler (...)
> {
> if (!waitqueue_active(...))
> /* Missed an interrupt. */
> return;
>
> wake_up (...);
> }
>
> If there's another atomic primitive I should be using, please let me know,
> but I kind of thought that this is what semaphores were for.
There' s a dirty way to workaround the sem-recursion in the parport case.
You are using a single threaded down() and you can have an up() at any
time and your only care is to not miss it. The dirty way knows how i386
(and hopefully other) sempahores works in pre9.
So you can do something like that (pseudocode written in some seconds):
struct semaphore sem = MUTEX_LOCKED;
tell hardware to generate irq when ready()
again:
sem->owner_depth = 0; /* invalidate myself */
/* down just care to order instructions before start for real */
down_interruptible(&sem);
if (!ready())
goto again;
After a short read of the code I think that the above should do the trick
without any risks to miss an irq on pre9 (it should be something of still
perfectly atomic). Probably it's possible to write a safe down (and
recalling the current down() to down_recursive()) (that works on the same
semaphore) with the _only_ difference that the new down() set
owner_depth to 0 as opposed to down_recursive() that instead of increase
it of 1 before start for real in the asm (lock; decl .count ...).
I had no time to reverse engeneering the crazy nibble mode of Epson Stylus
Color today too... :( but maybe I'll do that tomorrow... ;)
Andrea Arcangeli
-
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/