Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755225AbYKUOxl (ORCPT ); Fri, 21 Nov 2008 09:53:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753471AbYKUOxc (ORCPT ); Fri, 21 Nov 2008 09:53:32 -0500 Received: from kandzendo.ru ([195.178.208.66]:45168 "EHLO tservice.net.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753358AbYKUOxb (ORCPT ); Fri, 21 Nov 2008 09:53:31 -0500 Date: Fri, 21 Nov 2008 17:53:29 +0300 From: Evgeniy Polyakov To: Robert Love Cc: Pavel Machek , mtk.manpages@gmail.com, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , Christoph Hellwig Subject: Re: [take 3] Use pid in inotify events. Message-ID: <20081121145329.GA14556@ioremap.net> References: <20081116232450.GA13547@ioremap.net> <20081117171508.GA564@ioremap.net> <20081117175212.GA2224@ioremap.net> <20081120130902.GA1408@ucw.cz> <20081121140325.GA12384@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 Content-Length: 2586 Lines: 58 On Fri, Nov 21, 2008 at 09:30:38AM -0500, Robert Love (rlove@rlove.org) wrote: > Your solution needs to be (a) generally applicable and useful, with an > (b) elegant and clean API, which (c) does not break ABI or API. > > Overloading the cookie field is not the way to go. Finding ways to > extend the API through inotify_init might be--you will have even > higher hurdles of "do we really need this" though. That's it. Does it mean neither solution will be accepted? Just because 'we' do not need to know IO origin identity. According to your three requirements for the solution. They can not be satisfied, just because inotify event returned to userspace is fixed, so there will be at least extension of the API and ABI. > John & I intentionally did not add the pid field when writing inotify > for reasons of security and questionable need. It also stinks to have > to add a pid field to the event structure if that field is seldom > used. That's it: overloading existing cookie is a no-go, new interface is not needed :) What I would implement if things are getting that far, is a nesting attributes in form of header and data, like [generic inotify header: event, watch and attached data size] [attribute0 size data] [attribute1 size data] ... [attributeN size data] where attribute list, needed to be sent per event is created via ioctls on top of inotify file descriptor, since overloading flag value of the inotify_init1() allows to have only 32 attributes, while that may be not enough. So far I see several: pid, IO offset and start, attributes changed (access mode, permissions, xattrs names), combine move event into two attributes of the same event instead of two events with the same cookie. Maybe something else, this can be extended infinitely. > Working on lkml often sounds like everyone is screaming NO, channeling > nothing but stop energy. Sometimes people are, but more often what > they really mean is you just have to take your time and do things > right. Admittedly it is a lot of iteration, but Linux is a noble > pursuit. It is linux-kernel@ only. All subsystems I worked with behave cooperately to solve the problem. All except generic changes, which end up in linux-kernel@. But that's the matter of feeling that this is a so special mail lists. We can live with it of course :) -- Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/