[lkml]   [2008]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [take 3] Use pid in inotify events.
    On Fri, Nov 21, 2008 at 09:30:38AM -0500, Robert Love ( 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

     \ /
      Last update: 2008-11-21 15:55    [W:3.601 / U:1.584 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site