kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
* FIFO
@ 2012-11-28  9:43 Pietro Paolini
  2012-11-28 13:05 ` FIFO Bernd Petrovitsch
  0 siblings, 1 reply; 6+ messages in thread
From: Pietro Paolini @ 2012-11-28  9:43 UTC (permalink / raw)
  To: kernelnewbies

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* FIFO
  2012-11-28  9:43 FIFO Pietro Paolini
@ 2012-11-28 13:05 ` Bernd Petrovitsch
  2012-11-29  9:07   ` FIFO Pietro Paolini
  0 siblings, 1 reply; 6+ messages in thread
From: Bernd Petrovitsch @ 2012-11-28 13:05 UTC (permalink / raw)
  To: kernelnewbies

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 at petrovitsch.priv.at
                     LUGA : http://www.luga.at

^ permalink raw reply	[flat|nested] 6+ messages in thread

* FIFO
  2012-11-28 13:05 ` FIFO Bernd Petrovitsch
@ 2012-11-29  9:07   ` Pietro Paolini
  2012-11-29  9:25     ` FIFO Victor Buciuc
  2012-11-29 10:44     ` FIFO Bernd Petrovitsch
  0 siblings, 2 replies; 6+ messages in thread
From: Pietro Paolini @ 2012-11-29  9:07 UTC (permalink / raw)
  To: kernelnewbies

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 at kernelnewbies.org] On Behalf Of Bernd Petrovitsch
Sent: mercoled? 28 novembre 2012 14:06
To: kernelnewbies at 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 at petrovitsch.priv.at
                     LUGA : http://www.luga.at


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 6+ messages in thread

* FIFO
  2012-11-29  9:07   ` FIFO Pietro Paolini
@ 2012-11-29  9:25     ` Victor Buciuc
  2012-11-29  9:29       ` FIFO Pietro Paolini
  2012-11-29 10:44     ` FIFO Bernd Petrovitsch
  1 sibling, 1 reply; 6+ messages in thread
From: Victor Buciuc @ 2012-11-29  9:25 UTC (permalink / raw)
  To: 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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* FIFO
  2012-11-29  9:25     ` FIFO Victor Buciuc
@ 2012-11-29  9:29       ` Pietro Paolini
  0 siblings, 0 replies; 6+ messages in thread
From: Pietro Paolini @ 2012-11-29  9:29 UTC (permalink / raw)
  To: kernelnewbies



-----Original Message-----
From: Victor Buciuc [mailto:victor.buciuc at gmail.com] 
Sent: gioved? 29 novembre 2012 10:26
To: Pietro Paolini
Cc: Bernd Petrovitsch; kernelnewbies at 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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* FIFO
  2012-11-29  9:07   ` FIFO Pietro Paolini
  2012-11-29  9:25     ` FIFO Victor Buciuc
@ 2012-11-29 10:44     ` Bernd Petrovitsch
  1 sibling, 0 replies; 6+ messages in thread
From: Bernd Petrovitsch @ 2012-11-29 10:44 UTC (permalink / raw)
  To: kernelnewbies

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 at petrovitsch.priv.at
                     LUGA : http://www.luga.at

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-11-29 10:44 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-28  9:43 FIFO Pietro Paolini
2012-11-28 13:05 ` FIFO Bernd Petrovitsch
2012-11-29  9:07   ` FIFO Pietro Paolini
2012-11-29  9:25     ` FIFO Victor Buciuc
2012-11-29  9:29       ` FIFO Pietro Paolini
2012-11-29 10:44     ` FIFO Bernd Petrovitsch

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).