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@xxxxxxxxxxxxxxxxxxx
LUGA : http://www.luga.at
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
