[Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))

[mike.valk at gmail.com]

2013/6/7 luke.leighton <luke.leighton at gmail.com>:
> On Thu, Jun 6, 2013 at 2:10 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
>
>> If companies are going to go off and invent the square wheel, and that
>> makes *them* suffer the loss of being able to merge back into the
>> mainline kernel, thereby making *their* job of moving forward with
>> their kernel versions much harder, then yes, we *are* happy.
>
>  russell: they have more employees than sense :)  they also don't have
> any idea of what they *should* be doing, so this is an opportunity to
> educate them.
>
>  they're not feeling any pain: they just employ more chinese
> developers and substitute bodies for time and common-sense.
>
>  also, in this particular case, thanks to their script.fex system when
> i said they only need to develop one kernel and one u-boot i really
> wasn't kidding around: they really have got to the point which
> everyone else dreams of with device-tree [admittedly by limiting the
> product range that their clients can play with, but that product range
> has huge returns, so they're still happy].
>
>> Companies will always do idiotic things; it's *them* and their users
>> who have to live with the results of that bad decision making process.
>
>  russell: the decision process they've made is actually an extremely
> effective one.
>
>> Eventually, the pain of being outside the mainline kernel will become
>> too great, especially if their users demand things like kernel upgrades
>> from them.  Eventually, they will change.
>>
>> And no, this isn't an intransigent position.  This is reality given
>> that ARM already has way too much code in the Linux kernel and we're
>> trying to reduce that through the use of technologies like DT.  The
>> last thing we need right now is for another "DT" like implementation
>> to come along which is only used on a minority of platforms - even if
>> the platform it is used on is successful.
>>
>> The way this works is this:
>> - you either go with the policies which are set, or
>
>  .... which they weren't consulted on, it has to be pointed out.
>
>> - you change the policy as a whole because you have a technically
>>   superior solution
>
>  i believe they have a technically more *successful* solution. whether
> it's more appropriate in a wider context is another matter.
>
>  here we have a key to the crux of the problem: the linux kernel
> maintainers have to cater for _everyone_.  with no funding or
> incentive from the major contributors to work with them.  hmmm....
>
>> What that means in this case is either you adopt DT, or you convince
>> everyone that DT isn't the solution, but your solution is, and we adopt
>> your solution for *everything* instead.
>>
>> If neither of those are possible, then that's really not our problem,
>> and it's not _us_ who are being "intransigent".
>
>  indeed.
>
>  ok.  so.  we come back to the question again: what shall i propose to
> them that they consider doing, and what benefit would it be to them to
> do so?

As I read/see it :

Conforming/Collaborating with DT/Upstream Kernel/Linux-sunxi has at
least the following benefits for AllWinner
- Acces to the latstest kernels. With little effort.
- Free bug fixing.
- Faster deployment of new Adroid versions with
- Obtaining market share in other distro's/OS'es like: FirefoxOS,
Tizen, Desktop linux, ....
- Obtaining market share easily in other area's like: Thin client's /
TV's / Desktops / Low level control (ARM is becomming more popular in
the 'Arduino' segment) etc.
- Gaining access/compatibility to a lot of other peripheral hardware
without any effort.
- No dependency on hardware of the currently supported 3rd party vendors
- More focus on there core business... Making SoC's. Less on software
development.
- Access to great developers around the world

There could be more.

>
>  i cannot go to them and say "you have to do this [insert proposal
> here]" - it has to be more subtle than that.
>
>  l.
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk