Some delays are shorter (i.e. 20us).
What (if any) taboos exist for using sleep() in a kernel ioctl
call and what
alternatives exist?
it's not a taboo. In your case, i think it's simply because you can
not reschedule because it will screw something (are you holding a lock
or something? probably some sequences of inb/outb must be done in
sequence ?). If yes, then busy wait is probably your only way to
delay.
I don't think it's due to a lock, for some of the shorter sleeps
where I just need to make sure the bit stays set for a microsecond or
more I use schedule() which even if it decides to run the current
process, the calling delay is sufficient. Basically the register is
read (readl(), bit set, then written (writel()).
I'll look into busy wait but there are some delays that should be
shorter than the system tick (1KHz) just so the process doesn't take
too long. For example, I have a FIFO to fill and I must wait 20uS
between writes. It would be nice to use a usleep() for this but
anything that has the granularity of the system tick would end up
taking too long. Of course not much else can get done on the CPU
during the 20uS sleeps anyway so spinning on the rdtscl() count is
not a total waste.
Thanks,
-Bruce
Kernel is 2.6.13 w/preemption, soon to be moving to a later version,
regards,
Mulyadi.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
