[Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Neal Peacock
neal at nic-stix.com
Fri Jun 7 12:27:31 BST 2013
"mike.valk at gmail.com" <mike.valk at gmail.com> wrote:
>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 think this summarizes the benefits pretty well. One thing to add , they have already seen and taken advantage of these benefits. We have seen linux-sunxi community commits end up in their kernel source.
The current linux-sunxi community is very small next to whole of the Linux community. They know how much software development is currently costing them. This money could be spent for great new features that make them stand out from the competition, instead its just keeping up a parallel development program. Since Android is tied to the mainline their workload is only going to increase over time unless they invest in joining the community approach.
Their current build system is very easy to use and install. Given that, I see no reason Henrik's solution won't work. Keep fex, make a converter program, rebuild your DT kernel when needed.
>
>>
>> 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
>
>_______________________________________________
>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
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
More information about the arm-netbook
mailing list