Re: [GIT PULL] kdbus for 4.1-rc1

[Martin Steigerwald]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/