Re: [take 3] Use pid in inotify events.

[Evgeniy Polyakov <zbr-i6C2adt8DTjR7s880joybQ@public.gmane.org>]

Hi John.

On Thu, Nov 20, 2008 at 02:34:11PM -0800, John McCutchan (john-jueV0HHMeujJJrXXpGQQMAC/G2K4zDHf@public.gmane.org) wrote:
> I really don't like the idea of overloading the cookie field to store
> the pid for only the events that don't already use the cookie field.

Adding PID or whatever else will not be used most of the time either.
I agree, that having new protocol (which so far did not get any
extensions except what I described for my own application) looks
cleaner, but if no one will use it, and existing extension works for
everyone (nothing breaks), I'm trying to push this idea up.

So, except theoretical clearness of the unused-by-everyong idea,
what forces you to think, that new inotify should be implemented?

> Coming into this late, maybe I missed it but can you explain why you
> need the pid that caused the event?

I have a network server, which gets IO requests from different clients
and maintains coherency of the data between them, but if file is
modified locally I want to flush or invalidate remote data. I decided
not to dig into the kernel on the server node and use inotify to get
notifications about events, but there is no way to determine if given IO
was originated by server itself (and in this case nothing should be
done), or by external application which accesses exported directory (and
in this case I should send update messages to clients).

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html