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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
