Hi, I have encountered the same problem ,too
(I mean, notify userspace app some event occurring form kernel space code)
AFAIK, the kernel can nofity a userspace app by signal or netlink
in my case, the netlink is not conpiled in, so the only way left is signal
Is there other way for kernel to notify a userspace actively??
and Why is it a bad idea to use signal in such a case?
BTW, I have another question about signal,
in my case , a process is forked to do some auth protocol handshaking
the process wake up , perform handshake (might be blocked in recv() or select() system call)
when a systemV msg sent to it,
And a signal handler is registered to this process to recv some notification from kernel,
All that signal Handler to do is just add msg to process's msg queue
I find that : when the process blocked at recv() and the signal comes, the signal handler add msg to process's msg queue .and then it also wake up the process even through the recv() not get a ready packet!!
I solve this problem by masking the signal before invoking recv(). and unmask it when recv() retuen a packet.....
Why??
Steve.
2006/1/12, MHD.Tayseer Alquoatli <idoit.ief@xxxxxxxxx>:
On 1/12/06, Sergey Semenov < sergey.semionov@xxxxxxxxx> wrote:Hi,
Thank you for fast reply.
On 1/12/06, Thomas Petazzoni < thomas.petazzoni@xxxxxxxx> wrote:
> > I've implemented driver, which waits for some event from external
> > device. When this event comes, i should notify ASAP my user-space
> > application from kernel to achieve the fastest reaction. Now i am
> > using only signals and i don't know what i can do else. Can you advice
> > me something ? Thank you!
>
> If your application is waiting an event from a device, then it means
> that it called something like read(), write() or ioctl() which are then
> implemented in the kernel space driver. These functions can sleep in the
> kernel space driver until the event occurs. Then, they are unblocked and
> the userspace process can continue its execution.
Yes, exactly! But im my case, user-space application does another
background work everytime. It has own timetable with some events. In
infinite loop this application checks for next point execution time
and executes corresponding events.
My driver is working concurrently with this application. Driver is
waiting for some external events, and if they occure, it informs the
application about this event using signal. When the application
catches this signal, it asks for driver about occured event using
ioctl function, schedules this event in own timetable and continues
execution.
Sorry for such careless description, but i hope you'll understand what
i mean. Thus i can't use the blocking IO operations like you offered
above. And i don't know how to make this communication faster and in
more efficient way.
you can use poll/select mechanisms to assure that such a blocking operations will not block your calls
you can probe for events from your device and continue to do your background job if there is no events to serve then probe again later.. and you can use timeout as well if your background job has a periodic nature
see:
http://www.die.net/doc/linux/man/man2/poll.2.html
http://www.die.net/doc/linux/man/man2/select.2.html
hope it helps
MHD.Tayseer
Thank you!
With best regards,
Sergey Semionov
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
