From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chinmay V S Subject: Re: Query regarding inotify and mmap-ed files Date: Mon, 1 Jul 2013 22:08:28 +0800 Message-ID: References: <20130627104721.GA27378@dyad.programming.kicks-ass.net> <20130701133711.GC3897@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Peter Zijlstra , linux-fsdevel@vger.kernel.org, hch@lst.de, akpm@osdl.org To: Jan Kara Return-path: Received: from mail-vc0-f181.google.com ([209.85.220.181]:54007 "EHLO mail-vc0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753801Ab3GAOJA (ORCPT ); Mon, 1 Jul 2013 10:09:00 -0400 Received: by mail-vc0-f181.google.com with SMTP id lf11so1953349vcb.40 for ; Mon, 01 Jul 2013 07:08:59 -0700 (PDT) In-Reply-To: <20130701133711.GC3897@quack.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > But why can't you use current IN_MODIFY event? > Initially i registered a "catch all" inotify watch on the mmap-ed file by calling inotify_add_watch() with IN_ALL_EVENTS in the "reader" process. But modifications to the file by mmap-ing it in the "writer" process did NOT trigger the inotify watch. Even calling msync() did NOT trigger any inotify events. (BTW, Is this expected behaviour?? v2.6.37 on ARMCortexA8, rootfs on NAND) The file was mapped using MAP_SHARED to ensure that no copies were made in memory and the changes made by the "writer" process are being flushed to the file. Hence added support for IN_SYNC event in the inotify framework. https://gist.github.com/TheCodeArtist/5874669 IMHO, this is a well justified addition to the inotify mechanism. Since it simplifies the creation of an event notification framework for IPC, is any reason why IN_SYNC should *NOT* be mainlined? PS: Once again, i would really really welcome any suggestions to implement a simple high performance notification mechanism for IPC using any existing alternatives. Running a "patched" kernel is something i would like to avoid. System requirements: a. Single data "writer" process. b. Multiple "reader" processes, each to be notified of every update by the writer. c. Processes "writer" and "readers" NOT related. No per-determined order of execution. d. Events may NOT be dropped. regards ChinmayVS