Dear All... > > But i have another question. So, it seems that there are at least > > two directions(ways) of kernel-userspace message exchange: > > 1) Userspace application at every iteration can ask driver for new > > events (messages) using (blocked/unblocked) pool/select mechanism > > or ioctl and other system function calls. It's a good way, because > > you don't need to care about syncronisation and you can expect at > > what time the message comes. So you don't need any IPC staff to > > control your application (i mean critical sections and semaphores), > > 2) There is another way. The kernel can inform your userspace > > application about new events (e.g. through signals), but signals > > can interrupt the application execution at any time (like Hsieh > > Steve has described with recv() function) and you can't predict it > > at all.... Or can you? > I think 2nd is much faster than 1st but 1st is also fast enough as > its related to system calls and sys_calls are very fast in execution > (CMIIW) Sorry for jumping in right in the middle of discussion. Personally, I suggest #2 solution (e.g using netlink/signal/d-bus/whatever) rather than using #1. The advantage are: 1. Saving the number of user-kernel-user switch you might trigger. 2. Free up your user space application to do something else. 3. Unless the event is "rapid", it is likely you will see no new event arrive thus wasting CPU cycle. This situation is similar with NAPI/Poll technique used on Gigabit ethernet driver. It does polling at high frequency because the driver is expected to handle data that is arrived at very high speed, something that can't be achieved if you just "wait" for the event. Just my 2 cents idea...feel free to CMIIW regards Mulyadi -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
