Hi all, I would like use a FIFO to implement a pipe which use is quite the same of the /proc/fs (for example the net statistics then just read). I would like use the cat command in order to reach the information, like: Cat /path/to/pipe The problem is that cat expect the EOF of file before exit and stay blocked until that, someone know how can I solve the problem ? Many thanks, Pietro.
Hi! On Mit, 2012-11-28 at 09:43 +0000, Pietro Paolini wrote: [....]
I would like use a FIFO to implement a pipe which use is quite the same of the /proc/fs (for example the net statistics then just read).
/proc/fs is a directory hereover.
I would like use the cat command in order to reach the information, like:
Cat /path/to/pipe
The problem is that cat expect the EOF of file before exit and stay
That "problem" is the defined behaviour and all programs will behave that way.
blocked until that, someone know how can I solve the problem ?
Wherever your driver sends out the data (when user-space read(2)s it), you just return 0 (instead of sleeping/blocking the process) if you are at the end of the output. Kind regards, Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at LUGA : http://www.luga.at
Hello! Thanks for your reply, the fact is that I am not writing a device driver but just an user-space program and I would like implement a technique like /proc/ under a normal directory. Like /tmp/blahblah I have a program which take count about some statistics and I want read them "on demand" doing a cat of /tmp/blahblah, I investigate a bit and : 1) FIFO can be a solution but if I am not wrong I need two FIFO, one for say "I want read stats" and another one where write them 2) I could use inotify and write on a file the stats when file under monitoring is opened for read. In both cases I need two file, I would like instead use one, how can I do that ? Many many thanks, Pietro. -----Original Message----- From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies-bounces@kernelnewbies.org] On Behalf Of Bernd Petrovitsch Sent: mercoledì 28 novembre 2012 14:06 To: kernelnewbies@kernelnewbies.org Subject: Re: FIFO Hi! On Mit, 2012-11-28 at 09:43 +0000, Pietro Paolini wrote: [....]
I would like use a FIFO to implement a pipe which use is quite the same of the /proc/fs (for example the net statistics then just read).
/proc/fs is a directory hereover.
I would like use the cat command in order to reach the information, like:
Cat /path/to/pipe
The problem is that cat expect the EOF of file before exit and stay
That "problem" is the defined behaviour and all programs will behave that way.
blocked until that, someone know how can I solve the problem ?
Wherever your driver sends out the data (when user-space read(2)s it), you just return 0 (instead of sleeping/blocking the process) if you are at the end of the output. Kind regards, Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at LUGA : http://www.luga.at _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Thu, Nov 29, 2012 at 11:07 AM, Pietro Paolini <P.Paolini@ext.adbglobal.com> wrote:
Hello!
Thanks for your reply, the fact is that I am not writing a device driver but just an user-space program and I would like implement a technique like /proc/ under a normal directory.
Like /tmp/blahblah
I have a program which take count about some statistics and I want read them "on demand" doing a cat of /tmp/blahblah, I investigate a bit and :
1) FIFO can be a solution but if I am not wrong I need two FIFO, one for say "I want read stats" and another one where write them
2) I could use inotify and write on a file the stats when file under monitoring is opened for read.
In both cases I need two file, I would like instead use one, how can I do that ?
Many many thanks, Pietro.
I guess what you want is an asynchronous way to react to a request. A simpler way may be to install a signal handler for SIGUSR1 or SIGUSR2 and dump the stats in known place. Or if you really wanna use a pipe you can do a asynchronous read on the pipe and do the stats dumping in the callback. Regards, Victor.
-----Original Message----- From: Victor Buciuc [mailto:victor.buciuc@gmail.com] Sent: giovedì 29 novembre 2012 10:26 To: Pietro Paolini Cc: Bernd Petrovitsch; kernelnewbies@kernelnewbies.org Subject: Re: FIFO On Thu, Nov 29, 2012 at 11:07 AM, Pietro Paolini <P.Paolini@ext.adbglobal.com> wrote:
Hello!
Thanks for your reply, the fact is that I am not writing a device driver but just an user-space program and I would like implement a technique like /proc/ under a normal directory.
Like /tmp/blahblah
I have a program which take count about some statistics and I want read them "on demand" doing a cat of /tmp/blahblah, I investigate a bit and :
1) FIFO can be a solution but if I am not wrong I need two FIFO, one for say "I want read stats" and another one where write them
2) I could use inotify and write on a file the stats when file under monitoring is opened for read.
In both cases I need two file, I would like instead use one, how can I do that ?
Many many thanks, Pietro.
I guess what you want is an asynchronous way to react to a request. A simpler way may be to install a signal handler for SIGUSR1 or SIGUSR2 and dump the stats in known place. Or if you really wanna use a pipe you can do a asynchronous read on the pipe and do the stats dumping in the callback. Regards, Victor. Thanks for our answer, I am close to catch the point, that's
Or if you really wanna use a pipe you can do a asynchronous read on the pipe and do the stats dumping in the callback.
How can I do " do the stats dumping in the callback", could you provide me an example link? Pietro.
Hi! On Don, 2012-11-29 at 09:07 +0000, Pietro Paolini wrote: [...]
Thanks for your reply, the fact is that I am not writing a device driver but just an user-space program and I would like implement a
OK. Mailing on kernelnewbies@ suggests something else in my world;-)
technique like /proc/ under a normal directory.
Like /tmp/blahblah
I have a program which take count about some statistics and I want read them "on demand" doing a cat of /tmp/blahblah, I investigate a bit and :
1) FIFO can be a solution but if I am not wrong I need two FIFO, one for say "I want read stats" and another one where write them
Yes, named pipes (created with mkfifo(3) or mkfifio(1)) and unnamed pipes (created with the pipe(2) sys-call) are a solution. And these allow only unidirectional communication (if you want to keep it simple). So just use 2 of them but that implies having 2 file descriptors on both sides. If you only want to read one bunch of data, than you do not need a "command channel" since named pipes behave as follows: The first process which opens the named piped blocks until a second process opens it. So an implementation could be: You use a second thread which just opens the named pipe and writes the current data to it if it is opened. The "current data" needs locking anyways so separating that into a second process needs shared memory, an mmap(2)ed file or the like to transfer the data to the second one. You can avoid the second thread/process with non-blocking I/O BTW. But if it is that simple, the data collector can just dump the statistics into a (new) plain file and atomically rename() it - if this is timely enough. So: If you have/want/need a command channel to say "I want to reads stats", you need a second pipe (or other communication channel to the collector - like e.g. signals or ...) anyways. If you just want to `cat` the data from a "file", you cannot send such a command anyways - at least not with `cat`. Well, you can implement several pipes for several commands, data sets, whatever ....
2) I could use inotify and write on a file the stats when file under monitoring is opened for read.
That smells like a race condition if the data collector writes into a file in parallel with the reader. You would need a semaphore (or signal or ...) so that the collector can tell the reader that is has finished.
In both cases I need two file, I would like instead use one, how can I do that ?
The traditional solution is to use sockets (either TCP/IP or Unix sockets) and you have your simple bidirectional communication with only one file descriptor per process. Given the application - one collects data, another one fetches it - the collector can play the server role and the other one the client role. but with sockets, you need netcat or socat(1) .... Kind regards, Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at LUGA : http://www.luga.at
participants (3)
-
Bernd Petrovitsch -
Pietro Paolini -
Victor Buciuc