A few random questions

[rdos]

I agree that many devices need to use small delays (but I have no example yet of a device that needs a nanosecond interval sleep). Common sense (but not Linux apparently) would implement both ms_delay and us_delay to call the scheduler to postpone (block) the task at least until the delay has expired. Busy-polling has no place in a kernel except in spinlocks.

Another similar problem is with devices that have set/reset pins memory mapped. The specifications often doesn't give time intervals for how long it might take until the device returns the proper bit settings. If a device driver busy-polls such bits it could end up hanging up the kernel a very long time (possibly even indefinitely). When I write device drivers for such hardware I always use a ms-interval delay before polling the device again.

[Luis]

Thank you very much for the input guys. That will help me to design a nice improvement to implement in my scheduler.


Cheers,

Luís