How can a driver in priviledged mode block?
 

I am working on an embedded system that uses an ARM processor, but this question applies to others too, I think.

I am writing a driver for a device, and I want to allow blocking and non-blocking reads and writes. In my system, the driver code is executed in the supervisor mode of the processor, and the driver code is executed via a software interrupt which switches from user mode to supervisor mode in library calls.

Also, in my system a task switch cannot occur unless the CPU is in the user mode.

My question is this: if the driver is blocking, then the CPU is stuck waiting in the supervisor mode, and I can't switch processes, so how do blocking I/O's happen in this or any system in a driver which is waiting in supervisor mode?

I'm sure the answer is simple and obvious, but I'm just not seeing it.

I considered adding a routine to the library calls that polls the driver which executes only in non-blocking mode, but this seems clunky, and I haven't seen any examples or documentation where this is done.

I also considered adding wrapper functions in the driver code for user-mode access, but this again seems clunky and I haven't seen it done elsewhere.

thanks.

The main thing is the function the driver runs to wait for the event (finished transfer and so on). It should not be a simple while loop (in fact it can be, if you know that the delay will be very short). Instead, you may mark the process structure somehow (usually a flag) so it will not be waken up in a normal way. Then the function causes the system to switch process to a different one.

Your orginal process can be woken up (finish the blocking function) as a result of an interrupt (or timeout, which you have probably as interrupt). Now, the interrupt routine removes the flag. It doesn't have to switch the process, it will work as usual.

If you look into that it's not that different from nonblocking mode. In fact, it is the same, but there's just a different way of handling the situation when interesting even occurs.

Ah! of course
 

Ah, of course! Thanks very much. I'll name a volatile char after you!