Hi! On 01:34 Sat 04 Apr , Peter Teoh wrote: > Thank you Michael, > > In general I must agree with a lots of points below, other times, I > cannot, because there is nothing to disagree with. (ie....pending > lots of other unknown variable...nothing affirmative can be asserted). .. > And workqueue ....yes, it should be used. Mainly reason is because > it is sleepable. Another is that it execute in the process context > of the caller. So it can return any error condition and this will go > direct to the userspace application that call it. (as mentioned in > article below, it is also THE ONLY option if u want your bottom half > to execute in the process context - any other option/context u CANNOT > return any error condition, as it will go to nowhere) > > http://www.linuxjournal.com/article/6916 This does not make any sense to me. 1) Workqueue context is sleepable, but you should not sleep too long or you might delay other workqueue users. However, kernel thread context is also sleepable and you can sleep for as long as you want. Workqueues are actually implemented using kernel threads and you can ever create your own private thread (pools) for your own private workqueues. System call context is also sleepable. It this case the user space process is put to sleep and the _interruptable functions should be used, if you might for a long time. This is done e.g. for blocking read() and write() system call to wait until data arrives. System calls can return error codes, but workqueue/kernel thread function cannot. What should the workqueue/kernel thread implememtation do with this codes? > As for ERESTARTSYS or EAGAIN or EINTR etc....it all depends on WHICH > bottomhalf interrupt handler function u can talking, and more > important, whether u are returning to userspace or to another part in > the kernel (eg, VFS layer seemed to be responsible for handling > ERESTARTSYS). The standards (which is your point Michael dear) > seemed to be captured in this remark: > > (started from http://www.linuxtv.org/pipermail/linux-dvb/2005-August/004018.html) > > /* > * These should never be seen by user programs. To return one of ERESTART* > * codes, signal_pending() MUST be set. Note that ptrace can observe these > * at syscall exit tracing, but they will never be left for the debugged user > * process to see. > */ > > in include/linux/errno.h. > > So yes, Michael is right, ERESTARTSYS should not be returned if the > path of processing is back to the userspace. This looks quite interesting. But let me explain EAGAIN: You have a user space process which does a read() system call and do data can currently be read, because buffer are empty. In this case there are 2 possible behaviours: - blocking: put the process to sleep, wait until data arrives, then copy the data to userspace and return - non-blacking: return immediately with EAGAIN if the buffer in empty; copy data only if it can be done immediately without putting the process to sleep File descriptors are opened in blocking mode, except you pass O_NONBLOCK to open or fcntl. non-blocking mode is often used together with io multiplexers like epoll. See the manpages of open fcnl and epoll > hmmmm......i never knew these before.....not sure if there exists a > POSIX/SystemV standard for these definition? > > Looking through all the samples in drivers directory.....many are > using each of these different error conditions (ERESTARTSYS, EAGAIN, > EINTR etc)......I have yet to fully understood them. The valid error conditions are defined per-systemcall. You can find them in the manpages. > PS: after writing all these, just read that mutex == binary > semaphore!!!! (from Wolfgang) so yes, mutex is much simpler, but it is > also a semaphore. :-). Basically yes, but mutexes are not wrappers around semaphores. They have their own (faster) implementation. -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
