Arjan van de Ven wrote:
>
> don't.
>
> interruptible_sleep_on() is a broken interface (see the comments in the
> header) and should not be used in any new code (where "new" is "since
> the year 2000" :)
>
> Just use the wait_event() interfaces .... or just a simple semaphore
> even if what you want to do is simple and performance isn't too
> critical.
>
OK, i'll not use, but the kernel has a lot of device drivers using it, that
may present the problem explained in my message.
In my code i've try the following:
save_flags(flags); cli();
if( !rs.txdone ) {
if( arg < 0 ) arg = rs.ttimeout;
if( arg > 0 )
interruptible_sleep_on_timeout ( &rs.txwait, arg );
else
interruptible_sleep_on ( &rs.txwait );
}
restore_flags(flags);
return rs.txdone;
Before testing the flag, interrupt are closed and if the TX is not terminated,
the interruptible_sleep_on_timeout will be called with interrupt DISABLED.
This is not a problem, because the scheduler will switch to another process,
and the new process will enable again the IRQ. When the scheduler will give
back the control to my process, it will continue with interrupt disabled, and
will be reenabled before exit.
This seems to work very fine.
Calling the waiting function with IRQ enabled may expose the device driver to
the risk of infinite wait (until a signal, obvious).
Thanks
Gabriele
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
