Messages in this thread | | | Date | Tue, 25 Nov 2008 16:24:34 -0800 | From | Andrew Morton <> | Subject | Re: [take2] Inotify: nested attributes support. |
| |
On Tue, 25 Nov 2008 22:42:35 +0300 Evgeniy Polyakov <zbr@ioremap.net> wrote:
> Hi. > > Attached patch (also attached test application) implementes > scalable nested attributes which are transferred on behalf the inotify > mechanism. It uses inotify_init1() to show that new event format should > be returned when reading from inotify file descriptor. > > Attributes are attached to given inotify instance via TIOCSETD ioctl, > where ID of the attribute is transferred. If entry with given ID exists, > it is removed and -EEXIST is returned. > > There is a set of callbacks indexed by ID (currently 4 attributes are > supported: pid, tid, io details (start/size of the written block) and > name), which are attached to given inotify device. > When new event is created, each callback is executed and may queue some > data into event structure, based on its internal details. When event is > read from the userspace, first its header is transferred (old > inotify_event structure) and then all attributes data in the order of > its registration via above ioctl. Nested attributes have following > structure: > > struct inotify_attribute > { > unsigned int id; > unsigned int size; > unsigned char data[0]; > }; > > where size is nuber of attached bytes for given attribute. > inotify_event.len contains number of bytes used to store all attached > attributes and data. > > Attribute callback can check if mask contains its bits and do some steps > based on that information, for example io details attribute does not add > own data (and header) if event mask does not contain IN_MODIFY bit. > > It is possible to infinitely extend number of attributes processed, so > we will be no longer limited by inotify API and ABI. > > Test application usage: > $ gcc ./iotest.c -W -Wall -I/path/to/kernel/include/ -o iotest > $ ./iotest -f /tmp/ -t -n -p -i > 2008-11-25 22:29:47.8477 pid: 1850, tid: 1850, name: /tmp/, wd: 1, mask: 303, attributes: pid: 1, tid: 1, io: 1, name: 1. > event: 2, wd: 1, cookie: 0, len: 61. > tid: 1672. > pid: 1672. > io details: start: 0, size: 0. > name: test. > event: 2, wd: 1, cookie: 0, len: 61. > tid: 1672. > pid: 1672. > io details: start: 0, size: 6. > name: test. > > Example with only tid and io details: > $ $ ./iotest -f /tmp/ -t -i > 2008-11-25 22:40:30.201286 pid: 1928, tid: 1928, name: /tmp/, wd: 1, > mask: 303, attributes: pid: 0, tid: 1, io: 1, name: 0. > event: 2, wd: 1, cookie: 0, len: 36. > tid: 1672. > io details: start: 0, size: 0. > > > while in parallel I did: > $ echo qwe11 > /tmp/test > > Two events were sent because of two calls for fsnotify_modify(), invoked > lkely from attribute change and write. Events are not combined since > because attributes may be different. Not having a name always combines > (read: skips next event) events because of old logic. >
I guess I'm being more than usually thick, but I don't understand what this is all about, why it was implemented, what value it provides to users, etc, etc? Why do I want scalable nested attributes in inotify??
I'm buried in patches which I don't understand lately, and having hundreds of people send patches at one guy who doesn't understand them isn't a good system. Eric Paris is working on inotify-type things as well. It would be neat if you guys were to understand and review each other's work. Please.
| |