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



-----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 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-----


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]