Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1171865 > unrolled thread

Re: kdbus: to merge or not to merge?

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: kdbus: to merge or not to merge? Martin Steigerwald <martin@lichtvoll.de> - 2015-06-25 08:10 +0200
    Re: kdbus: to merge or not to merge? Martin Steigerwald <martin@lichtvoll.de> - 2015-06-25 08:10 +0200

#1171865 — Re: kdbus: to merge or not to merge?

Am Mittwoch, 24. Juni 2015, 19:20:27 schrieb Linus Torvalds:
> On Wed, Jun 24, 2015 at 7:14 PM, Steven Rostedt <rostedt@goodmis.org> 
wrote:
> > I don't think it will complicate things even if the API changes. The
> > distros will have to deal with that fall out. Mainline only cares about
> > its own regressions. But any API changes would only be done for good
> > reasons, and give the distros an excuse to fix whatever was done wrong
> > in the first place.
> I don't think that's true.
> 
> Realistically, every single kernel developer tends to work on a
> machine with some random distro. If that developer cannot compile his
> own kernel because his distro stops working, or has to use some
> "kdbus=0" switch to turn off the kernel kdbus and (hopefuly) the
> distro just switches to the legacy user mode bus, then for that
> developer, merging and enabling incompatible kdbus implementation is
> basically a regression.
> 
> We've seen this before. We end up stuck with the ABI of whatever user
> land applications. It doesn't matter where that ABI came from.
> 
> I do agree that distro's that want to enable kdbus before any agreed
> version has been merged would get to also act as guinea pigs and do
> their own QA, and handle fallout from whatever problems they encounter
> etc. That part might be good. But I don't think we really end up
> having the option to make up some incompatible kdbus ABI
> after-the-fact.

Linus, so is that a recommendation to the distros to be careful to put kdbus 
into the distro kernel right now and probably better defer it or are you 
thinking that the ABI of kdbus already is suitable for merging and you see 
no issues to merge a kdbus with the ABI it currently has, but probably 
otherwise improved?

Thanks,
-- 
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1171868

Am Donnerstag, 25. Juni 2015, 08:01:35 schrieb Martin Steigerwald:
> Am Mittwoch, 24. Juni 2015, 19:20:27 schrieb Linus Torvalds:
> > On Wed, Jun 24, 2015 at 7:14 PM, Steven Rostedt <rostedt@goodmis.org>
> 
> wrote:
> > > I don't think it will complicate things even if the API changes. The
> > > distros will have to deal with that fall out. Mainline only cares
> > > about
> > > its own regressions. But any API changes would only be done for good
> > > reasons, and give the distros an excuse to fix whatever was done wrong
> > > in the first place.
> > 
> > I don't think that's true.
> > 
> > Realistically, every single kernel developer tends to work on a
> > machine with some random distro. If that developer cannot compile his
> > own kernel because his distro stops working, or has to use some
> > "kdbus=0" switch to turn off the kernel kdbus and (hopefuly) the
> > distro just switches to the legacy user mode bus, then for that
> > developer, merging and enabling incompatible kdbus implementation is
> > basically a regression.
> > 
> > We've seen this before. We end up stuck with the ABI of whatever user
> > land applications. It doesn't matter where that ABI came from.
> > 
> > I do agree that distro's that want to enable kdbus before any agreed
> > version has been merged would get to also act as guinea pigs and do
> > their own QA, and handle fallout from whatever problems they encounter
> > etc. That part might be good. But I don't think we really end up
> > having the option to make up some incompatible kdbus ABI
> > after-the-fact.
> 
> Linus, so is that a recommendation to the distros to be careful to put
> kdbus into the distro kernel right now and probably better defer it or
> are you thinking that the ABI of kdbus already is suitable for merging
> and you see no issues to merge a kdbus with the ABI it currently has, but
> probably otherwise improved?

Or, do you think, that there is a different option to handle this then the 
both I outlined above?

-- 
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web