From mboxrd@z Thu Jan 1 00:00:00 1970 From: Evgeniy Polyakov Subject: Re: [1/1] Use pid in inotify events. Date: Mon, 10 Nov 2008 18:20:43 +0300 Message-ID: <20081110152043.GB15796@ioremap.net> References: <20081108114225.GA22674@ioremap.net> <20081108153545.GA3859@ioremap.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Robert Love , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, John McCutchan List-Id: linux-api@vger.kernel.org Hi Michael. On Sat, Nov 08, 2008 at 11:58:30AM -0500, Michael Kerrisk (mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org) wrote: > It's perhaps unfortunate that the structure wasn't padded out with a > few additional fields "for future use". But -- maybe it is not really > true that we can't change things. Two things to consider: > > a) We now (since 2.6.27) have an inotify_init1() which has a flags argument. > b) There are spare bits in the mask argument of inotify_add_watch() > > We could use a flag in either of these to say that we want a different > structure returned on read() from the inotify descriptor. In the > first case, this would be a global setting for all inotify events on > that descriptor. In the second, we could do it on a per-watch basis > (I'm not so sure that that is a nice idea). Since we are in any case > extending the ABI, and new applications would need to be taught about > the extension, it seems we could consider either of the alternative > extensions I mentioned, which woul also allow the PID to be obtained > for rename() events. What do you think? This may be a good idea for some serious ABI change. I think we could extend it even more to include IO offset/size into events and attribute changes. -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753938AbYKJPUx (ORCPT ); Mon, 10 Nov 2008 10:20:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752175AbYKJPUp (ORCPT ); Mon, 10 Nov 2008 10:20:45 -0500 Received: from kandzendo.ru ([195.178.208.66]:53384 "EHLO tservice.net.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751647AbYKJPUp (ORCPT ); Mon, 10 Nov 2008 10:20:45 -0500 Date: Mon, 10 Nov 2008 18:20:43 +0300 From: Evgeniy Polyakov To: mtk.manpages@gmail.com Cc: linux-kernel@vger.kernel.org, Robert Love , linux-api@vger.kernel.org, John McCutchan Subject: Re: [1/1] Use pid in inotify events. Message-ID: <20081110152043.GB15796@ioremap.net> References: <20081108114225.GA22674@ioremap.net> <20081108153545.GA3859@ioremap.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Michael. On Sat, Nov 08, 2008 at 11:58:30AM -0500, Michael Kerrisk (mtk.manpages@googlemail.com) wrote: > It's perhaps unfortunate that the structure wasn't padded out with a > few additional fields "for future use". But -- maybe it is not really > true that we can't change things. Two things to consider: > > a) We now (since 2.6.27) have an inotify_init1() which has a flags argument. > b) There are spare bits in the mask argument of inotify_add_watch() > > We could use a flag in either of these to say that we want a different > structure returned on read() from the inotify descriptor. In the > first case, this would be a global setting for all inotify events on > that descriptor. In the second, we could do it on a per-watch basis > (I'm not so sure that that is a nice idea). Since we are in any case > extending the ABI, and new applications would need to be taught about > the extension, it seems we could consider either of the alternative > extensions I mentioned, which woul also allow the PID to be obtained > for rename() events. What do you think? This may be a good idea for some serious ABI change. I think we could extend it even more to include IO offset/size into events and attribute changes. -- Evgeniy Polyakov