Re: [GIT PULL] kdbus for 4.1-rc1

[Martin Steigerwald]

Am Mittwoch, 15. April 2015, 10:32:19 schrieb Greg Kroah-Hartman:
> On Wed, Apr 15, 2015 at 10:18:46AM +0200, Martin Steigerwald wrote:
> > Am Dienstag, 14. April 2015, 18:36:28 schrieb Andy Lutomirski:
> > > On Mon, Apr 13, 2015 at 1:22 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx>
> > 
> > wrote:
> > > > On Mon, Apr 13, 2015 at 09:42:17PM +0200, Greg Kroah-Hartman 
wrote:
> > > >> > I remain opposed to this half thought out trash of an ABI for
> > > >> > the
> > > >> > meta-data.
> > > >> 
> > > >> You don't have to enable the metadata if you don't want to use
> > > >> it,
> > > >> it's
> > > >> an option :)
> > > > 
> > > > OK, _that_ argument needs to be stomped out.  It had been used
> > > > before,
> > > > and it was a deliberate scam.  There is no such thing as optional
> > > > kernel interface, especially when udev/dbus/systemd crowd is
> > > > nearby.
> > > > We'd been through that excuse before; remember how devtmpfs was
> > > > pushed in as "optional"?
> > > > 
> > > > This is a huge red flag.  On the level of "I need your account
> > > > information to transfer $200M you might have inherited from my
> > > > deceased client".
> > > > 
> > > > Just to recap how it went the last time around: Kay kept pushing
> > > > his
> > > > piece of code into the tree, claiming that it was optional, that
> > > > nobody who doesn't like it has to enable it, so what's the
> > > > problem?
> > > > OK, in it went.  And pretty soon udev (maintained by the same...
> > > > meticulously honorable person) had stopped working on the kernels
> > > > that didn't have that enabled.
> > > > 
> > > > We had been there before.  To paraphrase another... meticulously
> > > > honorable person, "if you didn't want something relied upon, why
> > > > have
> > > > you put it into the kernel?" Said person is on the record as
> > > > having
> > > > no problem whatsoever with adding dependencies to the bottom of
> > > > userland stack.
> > > 
> > > It appears that, if kdbus is merged, upstream udev may end up
> > > requiring
> > > it:
> > > 
> > > http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.
> > > html
> > > 
> > > Grumble.
> > 
> > Honestly, I think that tightly coupling systemd and udev to certain
> > kernel versions in lock step is crap.
> 
> Where do you see that happening?
> 
> > That you require some minimum version after some reasonable time,
> > sure.
> > But in lockstep? Seriously.
> 
> Has that happened in the past?  Look at the minimum requirements of
> systemd/udev today, something like the 3.7 kernel release, many years
> old.

I refer to the linked mailing list post from Lennart as I quote here:

> To make this clear, we expect that systemd and kernels are updated in
> lockstep. We explicitly do not support really old kernels with really
> (which means 3.4 right now), but even that should be taken with a grain
> of salt, as we already made clear that soon after kdbus is merged into
> the kernel we'll probably make a hard requirement on it from the systemd
> side.

Thats plenty clear, isnÂt it? As soond as kdbus is merged into kernel, 
systemd will depend on it, and thenâ if I need to go back to older kernel, 
I have to downgrade systemd as well?

> > I certainly do not want a broken system just cause I have to load an
> > older kernel version for some reason.
> 
> No one does.  But, work with your distribution if you end up with
> something like this.  Remember, the goal is that you can always run
> newer kernels on older userspace, as that is something that we kernel
> developers can enforce.  Userspace programs have other requirements /
> communities, it's up to them to decide what their oldest kernel version
> they wish to support.  Hint, even glibc makes these kinds of
> requirements, it's nothing new at all here, so why is this even an
> issue?

Its no issue for me that systemd required kernel 3.7. Butâ what Lennart 
announces above regarding kdbus reads quite differently.

> > And yes, I think its good not to force just about any userspace idea
> > into the kernel.
> 
> Do you have any technical objections to the patch as proposed?

If I had, I would have written it. I explained already that I see that 
kernel developers have strong technical objections with kdbus. And that I 
think it is important to acknowledge it, instead of telling them, that the 
API is required from userspace, userspace people know what they do, and 
they should just go away with their concerns.

Thats at least how I received quite some of your responses.

Well and I raised an eyebrow on the busname matching rules and the 
capability stuff. Yet, I didnÂt comment on it, cause I didnÂt look at it 
in-depth. I just ask you to take those seriously who did.

-- 
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/