[lkml]   [2013]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 2:10 PM, Russell King - ARM Linux
<> 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".


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?

i cannot go to them and say "you have to do this [insert proposal
here]" - it has to be more subtle than that.


 \ /
  Last update: 2013-06-07 10:41    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean