the future of qualcomm SoC in linux

the future of qualcomm SoC in linux

[Daniel Walker]

David, Bryan,

In general this community wants all code maintained. Your intentions seem to be
that you want to push code, but you want to orphan it fairly quickly after you
push the code. I know this is true having worked with both of you and many of
your developers, and recent events seem to prove it.

It's fine if you don't want to maintain the code you push, but it's better for
us as a community if some one does maintains the code long term (10-15 years).

Linux also fosters community development so that people with devices can submit
patches or add extensions to existing code. It's my believe that you don't want
that, and have no intentions of supporting it for any of your platforms or for
any device that is created with your chips.

Since both of you seem un-willing to do these things, I suggesting this compromise. I
maintain the code long term for all Qualcomm platforms new and old, you submit
patches to me. If you don't want me to do this, or don't trust me to do it,
that's fine too just find someone else willing to maintain all the code long term.

Daniel

Re: the future of qualcomm SoC in linux

[Bill Gatliff]

I think the problems and solutions might be more nuanced than that.

Having met and worked with David and Bryan, I'm pretty confident that
they aren't seeking to actively prevent community maintenance of MSM
kernel code.  The problems seem to be that (a) their employer doesn't
charter them for long-term maintenance, and (b) the target SoC's
aren't currently used in contexts suitable for long-term maintenance.

Until both of these problems are fixed, the opportunity for progress is limited.

The fixes aren't attractive, either.  MSM SoC's are challenging enough
that it's going to require actual people working deliberately to
maintain their code, beyond what I think is likely to come from a
purely volunteer effort.  And that's even before you consider just how
many chips we're talking about here, and the rate at which the MSM
architecture (and the corresponding kernel code) is evolving.
Finally, don't get me started on the documentation and datasheet
issues.

Then, for what? MSMs largely target cell phones, which have a very
short lifespan.  Two years from now, you'll be maintaining kernel code
for an obsolete SoC on a phone that has a vanishing market share.  And
that SoC will be different enough from shipping commercial product
(which just about marks the end of an MSM SoC's lifespan already) that
there will be very little that would be worth forward-porting.

To pick but one example, I'd like to go back and clean up the way that
voltage regulators and the like were handled in the 7K's, because the
RPC mechanism implemented then was slow enough that it really limited
options for runtime power management in device drivers.  But that's a
thankless job if I've ever seen one.

I'm not saying that Qualcomm (and their downstream vendors) couldn't
do more to make it possible for us to clean up their shipping kernels,
or that there aren't any problems worth solving.  I'm only suggesting
that until MSMs find their ways into products with longer shelf life
e.g. embedded systems that aren't cell phones or tablets, the
motivation and enabling factors needed to prevent orphaning their code
is going to be hard to come by.

Believe it or not, I'm a huge Qualcomm fanboi.  :-) But I luvs them
enough to be realistic about them, too.  Insert the tough love, truth
hurts sometimes, just my $0.02, and the rest of the usual disclaimers
here.


b.g.



On Fri, Nov 1, 2013 at 12:11 PM, Daniel Walker <dwalker@fifo99.com> wrote:
>
> David, Bryan,
>
> In general this community wants all code maintained. Your intentions seem to be
> that you want to push code, but you want to orphan it fairly quickly after you
> push the code. I know this is true having worked with both of you and many of
> your developers, and recent events seem to prove it.
>
> It's fine if you don't want to maintain the code you push, but it's better for
> us as a community if some one does maintains the code long term (10-15 years).
>
> Linux also fosters community development so that people with devices can submit
> patches or add extensions to existing code. It's my believe that you don't want
> that, and have no intentions of supporting it for any of your platforms or for
> any device that is created with your chips.
>
> Since both of you seem un-willing to do these things, I suggesting this compromise. I
> maintain the code long term for all Qualcomm platforms new and old, you submit
> patches to me. If you don't want me to do this, or don't trust me to do it,
> that's fine too just find someone else willing to maintain all the code long term.
>
> Daniel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Bill Gatliff
bgat@billgatliff.com