Re: [GIT PULL] kdbus for 4.1-rc1

[Greg Kroah-Hartman]

On Wed, Apr 15, 2015 at 10:52:37AM +0200, Martin Steigerwald wrote:
> 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.

Adding features to the systemd repo, and then having those releases make
it out to your distro is a multi-year timeframe normally, and
multi-month at the least.  If a distro made such a decision to not
support old kernels by accepting such a userspace requirement, take it
up with them.

And there are forks of systemd that keep around older kernel support,
and distros use them for this very reason.  Because they want to use old
kernel versions, and that's great.

It's the same for any kernel feature, programs are free to use them if
they want to.  If glibc were to make the requirement tomorrow that they
are going to use memfd for their internal use and require that everyone
update their kernels for their new release, we would all laugh that that
is pretty funny and their user base would suffer.

But again, that's nothing that the kernel has any control over, take it
up with that project if you object to that.

Personally, I want people to use the new code/features I provide them in
the kernel, and get upset when people don't.  Otherwise, why would I
have spent so much time creating them and supporting them in the first
place?

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

I take technical comments very seriously, where have I not?  If you have
technical reasons why the current implementation has problems, please
let me know, and I will be glad to address them.

thanks,

greg k-h
--
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/