Hi All, On Thu, Jun 27, 2013 at 6:47 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Thu, Jun 27, 2013 at 05:44:52PM +0800, Chinmay V S wrote: >> Hi All, >> >> Recently i have implemented fairly simple IPC between two processes by >> mmap-ing the same file in both. >> >> To send an "event" from one process to the other i thought of using msync() >> and inotify. I found that there is no inotify event that can be triggered >> upon msync() on a mmap-ed file. >> >> Luckily i was able to patch the kernel and add a new watch to inotify that >> is triggered upon msync. >> >> https://gist.github.com/TheCodeArtist/5874669 >> >> This is derived from a previous work by Simo Sorce(wayyy back in 2009) >> http://osdir.com/ml/linux-kernel/2009-03/msg13455.html >> >> This is NOT part of the mainline kernel yet. >> Does this approach have any technical "gotchas"? >> _OR_ >> is there a far simpler approach i am missing? > > What's wrong with the myriad of socket based options? Use a named pipe or unix > socket? > The system design requirements are as follows: a. Single data "writer" process that acquires the data from peripheral hardware. b. Many "reader" processes. Each needs to be notified of every single event. i.e. each time the writer obtains new set of values, the set needs to be broadcast and each "reader" needs to obtain a copy. c. Writer and reader process are not parent/child and no pre-determined order of execution. d. File-backed for system-stability. Events may NOT be dropped. Even if any process crashes, the executable will be launched again and it should be able to continue processing from the last event. stackoverflow.com/questions/17123108/notify-signal-when-memory-mapped-file-modified Considering all these limitations (trust me it IS NOT a contrived example, but an actual requirement on this particular embedded device design i am working on currently), implementing IPC using an mmap-ed file across all the processes is working pretty well so far. I was surprised that its would be so difficult to implement such a design. Then again i thought i might be missing some very obvious simpler way to achieve the same. [1] In either case, please let me know any prior experiences/suggestions and design flaws that you can see. [2] Also considering that inotify is *THE* "goto framework" for monitoring the filesystem, would the patch to add support to inotify for tracking msync() mmap-ed files be mainlined? https://gist.github.com/TheCodeArtist/5874669 (if so, would be more than happy to rework it for the latest Linux Kernel version) regards ChinmayVS -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html