Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes: > On Mon, Mar 23, 2015 at 8:28 AM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: >> Hi >> >> On Thu, Mar 19, 2015 at 4:48 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>> On Thu, Mar 19, 2015 at 4:26 AM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: >>> But you're comparing to the wrong thing, IMO. Of course it's much >>> faster than /proc hackery, but it's probably much slower to do the >>> metadata operation once per message than to do it when you connect to >>> the endpoint. (Gah! It's a "bus" that could easily have tons of >>> users but a single "endpoint". I'm still not used to it.) >> >> Yes, of course your assumption is right if you compare against >> per-connection caches, instead of per-message metadata. But we do >> support _both_ use-cases, so we don't impose any policy. >> We still believe "live"-metadata is a crucial feature of kdbus, >> despite the known performance penalties. > > And you still have not described a single use case for which it's > better than per-connection metadata. > > I'm against adding a feature to the kernel (per-message metadata) if > the primary reason it's being added is to support what appears to be a > misfeature in *new* userspace that we have no obligation whatsoever to > be ABI-compatible with. This is especially true if that feature is > slower than the alternatives. This is even more true if this feature > is *inconsistent* with legacy userspace (i.e. userspace dbus). > > I could be wrong about the lack of use cases. If so, please enlighten > me. Please. I asked this same question on the first revision of this code to go up for review and I was told that there are no existing users of dbus that cares. Right now this looks like a case of the deplorable habit of getting review comments, and then resubmitting a patch with trivial changes and ignoring the substantial review comments. Again and again and again until the reviewers run out of energy to object. That seems like a very poor way to add a new ABI that to the kernel that we will have to support for the next 20 years, because huge swaths of userspace are going to be using it. Not to mention that per message meta-data is known to be both a performance problem but also that it tends to turn in to a security problem. It is the kind of information that is easy to mess up and hard to support long term. So I agree with Andy that we really need something better than it would be nice to have. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
