User: Password:
Subscribe / Log in / New account



Posted Sep 3, 2008 2:40 UTC (Wed) by liamh (subscriber, #4872)
In reply to: inotify? by dlang
Parent article: TALPA strides forward

OK. Then wouldn't it make sense to make this effort be an inotify next generation (robust and scalable) project, thereby avoiding the issue of the eventual application(s)? I use inotify now for something which has nothing to do with virus scanning, and I can imagine other applications as well, so perhaps there is a need for this anyway, quite apart from the scanners. It seems like a bad idea to have two independent partially overlapping subsystems in the kernel.


(Log in to post comments)


Posted Sep 3, 2008 8:21 UTC (Wed) by njs (guest, #40338) [Link]

There's been talk of such things (OS X has a similar scalable mixed kernel/user-space notification service that it uses for things like indexing), and it absolutely should be created for Linux -- but TALPA has requirements well beyond that. Blocking read(2) until some other userspace process has woken up and okay'ed things is *way* outside the scope of an inotify-alike!


Posted Sep 3, 2008 18:51 UTC (Wed) by jlokier (guest, #52227) [Link]

Actually it's not so far away from inotify.

We have leases in fcntl() F_SETLEASE, they go alongside dnotify in fcntl() F_NOTIFY.

inotify could similarly benefit from an an ilease extension, as well as further scalability improvements. (inotify was designed to improve on dnotify in many ways including scalability; it's a shame it stopped half way).

That's blocking readers right there.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds