On 1/26/06, Sergey Semenov <sergey.semionov@xxxxxxxxx> wrote: > > On 1/26/06, Hsieh Steve <stevecfhsieh@xxxxxxxxx> wrote: > > Thank alot for your replying!! > > Besides, > > Is there other way except to signal for kernel to notify a userspace > > actively? > > I think that another way exists. But i don't know what i can recommend > you else =) > You can use netlink sockets for generating event from kernel for user space and for two way communication between kernel and user space ! > 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? > > So, it was a small introduction =) My question is about: which > solution is faster? The first way is very good, but if you want to > achieve a good perfomance and fast message procceding, i think that > the second way is more reasonable. Am i right? > 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) -- Fawad Lateef -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
