Re: File I/O wrapper?

[Eric Bambach <eric@cisu.net>]

On Tuesday 25 January 2005 10:45 am, Dan Gary wrote:
> I originally avoided fifos because I couldn't figure out how to tell
> my program when to switch modes from read to write on the fifo.
>
> I need this to be able to dump data back out the "pipe" when a read is
> done, to be able to use this as a dropin replacement for log files,
> and potentially config files.

Maybe im misunderstanding you, but I have no clue as to the purpose of what 
you're trying to accomplish. You are writing a program that can act as a 
config file to be read by one program, while acting as a logfile to be 
written to by another?

Im not a programming guru, but I doubt this will work as a "drop in" 
replacement for programs as you cant get enough data from a read or a write 
call to know what kind of data the program is expecting or what it will be 
writing. You either need the sending/receiving program to identify itself to 
you (sockets, two-way pipe), or you need to snoop pretty hard on the 
reader/writer which is a trick in itself. 

You probably will need a kernel module, or an interesting new filesystem.

Perhaps you can enlighten me further, as this sounds interesting, even if its 
not feasable as a generic "drop in" replacement.

> And I really didn't want the i/o blocking, and although I've heard
> about ways to limit that I haven't seen a good example.
>
>
> I never thought about a char device though, might be the ticket.
>
> > What comes to my mind is a fifo also. Why do you say its not suitable?
> > Perhaps you are looking at it wrong. Please explain why you can't dont
> > want to use a FIFO and perhaps it will help us think of an alternative.
> >
> > Anything you can do on a file you can do with a FIFO. Perhaps you dont
> > want the SIGPIPE problem and blocking reads/writes?
> >
> > Sockets would be better but require the original program know about them.
> >
> > Perhaps registering a character device with the kernel and having the
> > original program write on /dev/mylog and your program receiving it.
> >
> > Heres a neat link on an example device driver chardev.c Not sure if its
> > for 2.4 or 2.6, but its a good place to start if you will actually need
> > to write a kernel module to shunt some data for you.
> >
> > http://www.faqs.org/docs/kernel/x571.html
> >
> > ----------------------------------------
> > --EB
> >
> > > All is fine except that I can reliably "oops" it simply by trying to
> > > read from /proc/apm (e.g. cat /proc/apm).
> > > oops output and ksymoops-2.3.4 output is attached.
> > > Is there anything else I can contribute?
> >
> > The latitude and longtitude of the bios writers current position, and
> > a ballistic missile.
> >
> >                 --Alan Cox LKML-December 08,2000
> >
> > ----------------------------------------

-- 
----------------------------------------
--EB

> All is fine except that I can reliably "oops" it simply by trying to read
> from /proc/apm (e.g. cat /proc/apm).
> oops output and ksymoops-2.3.4 output is attached.
> Is there anything else I can contribute?

The latitude and longtitude of the bios writers current position, and
a ballistic missile.

                --Alan Cox LKML-December 08,2000 

----------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html