Messages in this thread |  | | Date | Wed, 22 Oct 2014 22:16:17 +0200 | From | Heinrich Schuchardt <> | Subject | Re: A desktop environment[1] kernel wishlist |
| |
On 21.10.2014 15:11, Sergey wrote: > Hey everyone, > > I'm glad we're having some discussion on this, because we have almost > exactly the same kernel wishlist internally for elementary OS / Pantheon DE. > > I believe I can further elaborate on the VFS monitoring part. We need a file > monitoring facility that's scalable (unlike inotify) and can provide a > decent level of detail (unlike fanotify). In particular, we need to be able > to detect file/directory creation, renaming and removal events, as well as > close_write event. And, in an ideal world, all of that without requiring > root permissions. When I read your wish, I guess adding the capability to watch mounts with inotify would satisfy your needs. Would you agree?
Best regards
Heinrich Schuchardt > > This can be almost accomplished by combining output of fanotify with that of > a custom LSM module that just reports events to userspace (e.g. rlocate uses > such a thing). There are two problems with this: first, it's a hideous hack, > and second, it doesn't detect deletions. > > This is a big deal because without it we're stuck with always presenting the > user with the filesystem. If you've seen library-based music players like > Rhythmbox or Banshee, you know that they group and sort all your music by > artist and album, but not by directory and file name, and that you can > efficiently search all that metadata. We're trying to get the same thing > into more applications, but the absence of VFS features described above is > blocking us. Even after moving all the database management to a single > daemon that does all the monitoring and very rarely has to rescan anything, > the system either slows to a crawl (inotify) or the database gets out of > date quickly (fanotify+LSM). > In case I didn't make myself clear, a more detailed writeup on the design > can be found here: http://tiny.cc/tearing-up-files > > Regarding the other items, AFAIK the kernel implements mechanism, not > policy, so instead of "zswap selectively enabled by default" we just want > "stable reliable zswap". We had to give up on zram previously (in pre-3.10 > days) because of kernel regressions leading to panics when zram was enabled. > And we don't have the "Power management" part on our list because we haven't > really delved in that yet. But our lists are identical in all the other > areas, so that's not "just GNOME". > > PS: I'm not subscribed to LKML either, so please CC me. > > Cheers! > > -- > 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/ >
|  |