Re: [PATCH v4 00/14] Add kdbus implementation

Andy Lutomirski [off-list ref] writes:

On Mon, Mar 23, 2015 at 8:28 AM, David Herrmann [off-list ref] wrote:

quoted

Hi

On Thu, Mar 19, 2015 at 4:48 PM, Andy Lutomirski [off-list ref] wrote:

quoted

On Thu, Mar 19, 2015 at 4:26 AM, David Herrmann [off-list ref] wrote:

quoted

quoted

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