[systemd-devel] [Tracker] How to use cgroups for Tracker?

[Philip Van Hoof]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/10/2014 13:01, Lennart Poettering wrote:
> On Thu, 23.10.14 11:40, Martyn Russell (martyn at lanedo.com) wrote:

[cut]

>> I know it's a hard problem to solve, but if it's not solved with
>> the proposed solutions, the kernel developers shouldn't really be
>> accepting them.
> 
> Well, if it doesn't work, fix it! IIRC you have a business interest
> in tracker. Kernel interfaces don't fix themselves magically. They
> usual get fixed if somebody scratches his own itch, or if somebody
> with a business interest pays somebody to scratch his itch...

I think many people are reluctant to start working on this because the
kernel people don't know themselves yet what they would accept in the
kernel. But I agree it's a chicken and egg problem and probably in the
end even more a funding problem (or it just doesn't itch us enough).

The coalescing, however sounds like a good start. I can imagine that
kernel people would accept this as it wouldn't cause unpredictable
buffering in kernel. I guess that's their biggest concern. That and of
course that the kernel should never depend on a userspace component to
be functional in itself (the dependency should go the other way
around, as you correctly mentioned earlier).

> All these problems aren't exactly new, are they? They have been 
> discussed since 5y on and off...

I don't think that even after 5yrs it's clear where the Linux kernel
world wants to go with it. I'm guessing the coalescing with fanotify
with addition of the create/move/remove/etc events?

And then perhaps on top of that, in userspace, something like
fsevents. Or would the kernel world trust a coalescing fanotify enough
to allow unprivileged users of it?

For example: it might also mean filtering events per client process
depending on access rights the uid of current has on the filesystems
that caused the events: files that aren't visible for a user's
processes shouldn't become visible through fanotify's events.

Allowing unprivileged processes access is a can of worms you open ;-)


Philip

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (MingW32)

iQEcBAEBAgAGBQJUSOcMAAoJEEP2NSGEz4aDMRgH/1M+WvN5hNYF5/wV6CjeMPwK
Y2TSXSoQGe6+onPQyJhLiqit7CFjNylnZTIAzEhAOV+UOVMpggs1dDy+9pmwQIug
0MKC9uLqSK/yasxK8yUDozAfSBE2L4lyceGDHO2mtWF7O1dP+KJXrGrpH5VowPFd
6f2UUaKA5byl62RKK4GZOMlBCuQae12oyPnBYQfL8rV4pTwrjo1QjK+xdJrvwQmI
3CB8PWZ4jgNgQPaSqmnPsdOl0GmR9S2zlLt+9f8wfskywtMzGTTTVQNUE3E2Y3cq
HHrDaoFUhuSYFc0alYkiqs5FXv8ZsDdqfptCVCQKj1lqnsWJfmJB8Ajn8OV8rI4=
=7c29
-----END PGP SIGNATURE-----