Message-ID: <CAPweEDyYt+pN+UaFuqWL5RrHpyuq_4So-tArmx3dr=0wLS+hwQ@mail.gmail.com>
Date:	Fri, 7 Jun 2013 09:02:43 +0100
From:	"luke.leighton" <luke.leighton@...il.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Tomasz Figa <tomasz.figa@...il.com>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	debian-arm@...ts.debian.org,
	"jonsmirl@...il.com" <jonsmirl@...il.com>,
	Linux on small ARM machines 
	<arm-netbook@...ts.phcomp.co.uk>,
	linux-arm-kernel@...ts.infradead.org,
	debian-kernel@...ts.debian.org
Subject: Re: [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
<linux@....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?

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

 l.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists