On Thu 27-06-13 22:22:35, Chinmay V S wrote: > 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) As Al wrote, inotify has its problems (e.g. if you want to watch lots of files, when you want some reliability across operations such as rename etc.) so he is reluctant to extend it. In your case it can work OK though. But why can't you use current IN_MODIFY event? Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
