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

[ebiederm@xmission.com (Eric W. Biederman)]

Andy Lutomirski <luto@amacapital.net> writes:

> On Mon, Mar 23, 2015 at 8:28 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> Hi
>>
>> On Thu, Mar 19, 2015 at 4:48 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On Thu, Mar 19, 2015 at 4:26 AM, David Herrmann <dh.herrmann@gmail.com> 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