Re: [Ksummit-discuss] [Stable kernel] feature backporting collaboration

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3622 bytes --]

On Mon, Sep 05, 2016 at 05:22:59PM +0300, Laurent Pinchart wrote:
> On Monday 05 Sep 2016 10:03:27 Theodore Ts'o wrote:
> > On Mon, Sep 05, 2016 at 12:11:05PM +0100, Mark Brown wrote:

> > One of the problems is I can't test the Android common tree, because I
> > don't have access to hardware that I can boot on that tree.  (To be
> > honest, I'm not even sure what hardware would boot on it.)  And thanks

I'd be rather suprised if it doesn't boot on x86 TBH - if it doesn't I'd
imagine Google would fix it.  If you have a burning desire to run it on
an ARM system (and who wouldn't!) then one of the qemu platforms or
something like the BeagleBone Black or Cubietruck will work well
upstream (CubieTruck should be especially good for filesystem stuff due
to the SATA interface).  It's just a normal tree, it should work on
anything you're already working with.

> > This is why upstream-first is so darned important.  And why sloppy
> > patches that break other architectures are a really bad idea, even if
> > they are for a vendor-only BSP kernel....

You're preaching to the converted here but just telling everyone over
and over again that they're doing a terrible job isn't helping anything.
It's not offering any sort of constructive suggestion for how to improve
the situation that engages with the reality on the ground.

> > Maybe there will be some hope if some of the features from ARM64
> > server can infect the SOC community --- Jon Masters really had the
> > right idea when he insisted on one kernel to boot all ARM64 kernels,
> > with all changes pushed upstream, and not hacky, out-of-tree patches
> > which only work for one SOC vendor.

> I don't think that's a fair comparison. For server platforms end-users of the 
> hardware will pick a distribution and roll it out on the machines, so hardware 
> vendors have a strong incentive to play by our rules. Phones are completely 

The other big difference with server on ARM is that it's starting from
scratch with no real world to worry about on this architecture - the
server vendors only really care about the distros who happen to have
policies we like.  In turn the reason the distros are able to do that is
that there is no real deployed base of hardware and software for them to
target.

There's also the fact that for platforms that are upstream (and anyone
doing a good job downstream) we've been doing the single kernel image
thing for literally years - the way arm64 did single system image was
just to inherit all the work that had already been done on 32 bit ARM.
This is mainly about upstreaming especially in the mobile space where a
combination of technical issues and the construction of the market make
things challenging for everyone (the x86 mobile systems I've seen have
had just the same issues here).

> different in that the device vendor doesn't care about end-users being able to 
> pick what software in general and kernel in particular they want to install on 
> the device. Worse than that, many vendors go through hoops and loops to make 
> that impossible. Unless customers start boycotting devices that are not 
> upstream-friendly - and I don't think anyone expects this to happen - we'll 
> need to give SoC vendors a different incentive.

You can see some of those incentives operating if you look at the
systems that do do better upstream - for the most part the platforms
doing best upstream are those that address markets where the customers
care about it like the general market where there's no expectation of
strong support from the chip vendor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]