lkml.org 
[lkml]   [2015]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [GIT PULL] kdbus for 4.1-rc1
Date
Am Dienstag, 14. April 2015, 21:48:04 schrieb Greg Kroah-Hartman:
> On Tue, Apr 14, 2015 at 08:40:04PM +0100, Al Viro wrote:
> > On Tue, Apr 14, 2015 at 09:32:29PM +0200, Greg Kroah-Hartman wrote:
> > > On Tue, Apr 14, 2015 at 09:24:29PM +0200, Borislav Petkov wrote:
> > > > On Tue, Apr 14, 2015 at 09:23:57PM +0200, Greg Kroah-Hartman
wrote:
> > > > > You might not like the design, but it is a valid design. Again,
> > > > > we
> > > > > don't refuse to support hardware that is designed badly.
> > > >
> > > > Yeah except the small difference that unlike this, we can't change
> > > > hardware.
> > >
> > > And we can't change the design/implementation of many things, again,
> > > it's not the kernel's job to prevent something, just because we
> > > don't
> > > like the RFC, from being accepted.
> >
> > Translate, please. What exactly will be prevented by NAK on your Fine
> > Piece Of Software? Not dbus working as it does, surely?
>
> I don't understand. You can not like the D-Bus model (and accordingly
> the X11 model), but to prevent users from wanting to use it in a more
> secure, and faster way by implementing it like we have seems very odd to
> me.
>
> It's not going to stop anything from working, it's just going to stop
> some programs from being able to do things they really want to do (see
> the first email for examples.)
>
> Yes, we could make this live outside the kernel tree, but that's not the
> way we work anymore. We merge things that are useful, that match our
> security and coding requirements, and are going to be maintained by
> people we trust. To have the only major objection be "we don't like
> the way the protocol is designed because we know better, sorry", isn't
> ok at all.

Greg, I think I understood Al here.

dbus as it is used in KDE, GNOME, network-manager, systemd, you name it
does work. Not merging kdbus will not break it.

So the ones who want to see kdbus in kernel want to do something better or
differently like it is currently done in dbus. And yes, I have seen the
presentations about the benefits of having dbus in the kernel.

But if thats the case, what I think Al asks for a *new* kernel component
is a sound design that does not repeat any flaws from the original design
as the original design is no hardware that cannot be changed anymore after
production.

And to whether the design of kdbus is sound there seem to be strong
different oppinions about it. I think it is important to accept that and go
from there.

On the other hand, if you do things differently enough from the way
userspace dbus is doing it in order to have such a sound design, it may be
necessary to adapt all applications to it. But since kdbus is not yet in
the kernel officially this would not violate the "we never ever break
userspace" rule, cause the kernel obviously doesn´t guarantee the
stability of the current userspace dbus API, cause it doesn´t yet have
such an API at all. But if kdbus goes in, it has, and then it needs to
guarantee it until this "never break userspace" rule is changed, *if*
ever.

And also: Even if the kernel API is different in order to be sound, it may
be possible to adapt userspace dbus to use it to improve upon some of its
current flaws so that applications using it do not need to be changed at
all.

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7


\
 
 \ /
  Last update: 2015-04-14 22:21    [W:0.374 / U:0.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site