On Wed, 26 Nov 2008 11:29:36 +0300 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 26, 2008 at 12:15:38AM -0800, Andrew Morton ([EMAIL PROTECTED]) > wrote: > > OK, so we have a super-duper framework which will allow us to add pids > > (and other things) to inotify messages. > > Yup :) > > > This still doesn't provide a reason for anyone to be interested in the > > code! Why do we want pids in inotify messages? > > I actually cared only about myself :) > I started the thread and implementation, because my application has to > differentiate IO made by itself and any IO made by system (another > users, crons, whatever else), inotify did not give me that info, so I > extended it. As of others: PID/TID may be used by watching applications > to reduce own load to not process own IO, things like beagle may show > who actually made changes into the file. hrm. Well this is the sort of information which reviewers want to know all about before looking at an implementation. > > And how does this work give that pids are (no longer) system-wide unique? > > It gets pids from the caller's task_struct (via current), so its data is > as unique as process calling getpid() or syscall(__NR_gettid). That means that the code delivers non-unique process identifiers to userspace. A client gets pid=42 but there are seven processes on the machine with that pid. Problem. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
