-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/10/2014 13:01, Lennart Poettering wrote: > On Thu, 23.10.14 11:40, Martyn Russell (mar...@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----- _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
