All of lore.kernel.org
 help / color / mirror / Atom feed
From: Evgeniy Polyakov <zbr-i6C2adt8DTjR7s880joybQ@public.gmane.org>
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Robert Love <rlove-L7G0xEPcOZbYtjvyW6yDsg@public.gmane.org>,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	John McCutchan <ttb-/fF4VJJ1vBJctGpslLZhzA@public.gmane.org>
Subject: Re: [1/1] Use pid in inotify events.
Date: Mon, 10 Nov 2008 18:20:43 +0300	[thread overview]
Message-ID: <20081110152043.GB15796@ioremap.net> (raw)
In-Reply-To: <cfd18e0f0811080858k7f6cddadg962771ed0cb3bdb8-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.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

WARNING: multiple messages have this Message-ID (diff)
From: Evgeniy Polyakov <zbr@ioremap.net>
To: mtk.manpages@gmail.com
Cc: linux-kernel@vger.kernel.org, Robert Love <rlove@rlove.org>,
	linux-api@vger.kernel.org, John McCutchan <ttb@tentacle.dhs.org>
Subject: Re: [1/1] Use pid in inotify events.
Date: Mon, 10 Nov 2008 18:20:43 +0300	[thread overview]
Message-ID: <20081110152043.GB15796@ioremap.net> (raw)
In-Reply-To: <cfd18e0f0811080858k7f6cddadg962771ed0cb3bdb8@mail.gmail.com>

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

  parent reply	other threads:[~2008-11-10 15:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-08 11:42 [1/1] Use pid in inotify events Evgeniy Polyakov
     [not found] ` <20081108114225.GA22674-i6C2adt8DTjR7s880joybQ@public.gmane.org>
2008-11-08 14:25   ` Michael Kerrisk
2008-11-08 14:25     ` Michael Kerrisk
     [not found]     ` <cfd18e0f0811080625w5b285cc0p2410e8d187b025c7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-08 15:35       ` Evgeniy Polyakov
2008-11-08 15:35         ` Evgeniy Polyakov
     [not found]         ` <20081108153545.GA3859-i6C2adt8DTjR7s880joybQ@public.gmane.org>
2008-11-08 16:58           ` Michael Kerrisk
2008-11-08 16:58             ` Michael Kerrisk
     [not found]             ` <cfd18e0f0811080858k7f6cddadg962771ed0cb3bdb8-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-08 17:04               ` Robert Love
2008-11-08 17:04                 ` Robert Love
     [not found]                 ` <acdcfe7e0811080904y7eb461d3n70b0765d8b1e9011-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-08 17:27                   ` Evgeniy Polyakov
2008-11-08 17:27                     ` Evgeniy Polyakov
2008-11-10 15:20               ` Evgeniy Polyakov [this message]
2008-11-10 15:20                 ` Evgeniy Polyakov
     [not found]                 ` <20081110152043.GB15796-i6C2adt8DTjR7s880joybQ@public.gmane.org>
2008-11-10 17:15                   ` Michael Kerrisk
2008-11-10 17:15                     ` Michael Kerrisk
     [not found]                     ` <cfd18e0f0811100915o8ea98a0s816921cee3163c1c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-10 17:20                       ` Evgeniy Polyakov
2008-11-10 17:20                         ` Evgeniy Polyakov
     [not found] <acdcfe7e0811081035l56eedf05x8b3b7ee2fc01eee6@mail.gmail.com>
     [not found] ` <acdcfe7e0811081035l56eedf05x8b3b7ee2fc01eee6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-08 18:40   ` Evgeniy Polyakov
2008-11-08 18:40     ` Evgeniy Polyakov
     [not found]     ` <20081108184013.GA11888-i6C2adt8DTjR7s880joybQ@public.gmane.org>
2008-11-08 22:03       ` Evgeniy Polyakov
2008-11-08 22:03         ` Evgeniy Polyakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081110152043.GB15796@ioremap.net \
    --to=zbr-i6c2adt8dtjr7s880joybq@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=rlove-L7G0xEPcOZbYtjvyW6yDsg@public.gmane.org \
    --cc=ttb-/fF4VJJ1vBJctGpslLZhzA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.