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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Bill Gatliff bgat@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
