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