ARM promising platform, needs to learn from PC.

ARM promising platform, needs to learn from PC.

[Luke Kenneth Casson Leighton]

dear linus,

am writing (publicly) to you again, as this issue still hasn't been
resolved.  i believe now that it is recognised, but we still don't see
any solutions.  allow me to summarise the main point of
https://lkml.org/lkml/2011/7/1/473 which is "set a patch rule: if it's
a common standard / platform / design, i.e. serves more than one
purpose, it's in".  that's all it takes.  this will force SoC vendors
as well as Hardware Manufacturers to collaborate around common
standards, common platforms and common designs.

http://linux.slashdot.org/comments.pl?sid=2386322&cid=37132660

"I think Linus is criticizing the lack of a common platform
surrounding ARM rather than the instructions themselves. The
instruction set of x86 chips has grown a lot, especially with x86_64,
but the way you boot a PC hasn't changed much for example."

note the word "common" in that paragraph.  there *is* no "common" in
ARM devices.

http://linux.slashdot.org/comments.pl?sid=2254082&cid=36506588

"Kind of. Actually things are not that bad. There are a lot of SoCs
out there which bundle an arm core with a few other cores (ethernet,
usb, etc). There are actually staggeringly few vendors for the
peripheral cores. The SoC vendors don't generally mention who the core
vendor is, but they provide a datasheet and stick the core at some
random place in the address space.

As a result, there are a lot of reimplementations of the same drivers.
This has been recognised and peopls are now trying to spot duplicate
drivers and replace them with a asingle unified one."

great!  such patches cover "common devices", and should be encouraged.
 but, any patch *adding* only one "core" for one device should be
placed right at the back of the patch queue, until such time as a 2nd
device using that same "core" comes along.  it then qualifies, and
it's in.

http://linux.slashdot.org/comments.pl?sid=2254082&cid=36506338

"The problem is as dense and layered as the chips themselves - what
really needs to happen is a standardized method for publishing SoC
features in a structured format (XML?) where common features (FIFO
registers with a bytes_remaining field? Write only configuration
registers, Read only configuration register.. etc) could be defined
and the code could in many cases just be automatically generated."

nice idea, which would qualify under the "common" rules.  but it
doesn't help resolve designs based on CPUs that exist *now*.  it would
still qualify, though, and would help with hardware designs scheduled
to be released some time in 2013 or 2014 (*if* more than one SoC
manufacturer adopted the idea right now).

http://linux.slashdot.org/comments.pl?sid=2254082&cid=36507840

"It would be much better to simply standardise the SoC, so that every
ARM system has the same basic elements. Just like a PC, where the
interrupt controller and memory are always in the same place, and the
timer always has the same register map."

yes.  this is just the tip of the iceberg as to why things are such a
dog's dinner right now.  the sheer diversity of deployment scenarios
for ARM CPUs, it being the world's most ubiquitous CPU after all
(between 1 and 3 ARM CPUs in virtually every single phone on the
planet), works against this idea.  but, again: if it *were* to happen,
then such systems, having "common design" at the CPU level, would
qualify.  i don't hold out much hope of it happening though :)


soo, linus.  you know the score, just as much as everyone else does.
everyone - yourself included - is describing the problem, and no real
solutions.  the solution i propose - "reject selfish patches" - is
sufficiently generic to be pretty much deployed right across the
entire linux kernel tree, and it just so happens that the entire x86
architecture *accidentally* is a wholly-owned subset of this proposed
solution.

that just leaves how - or when - such a proposed gets implemented. the
only person with the power to galvanise people to act towards being
less f*****g selfish is... you.  nobody else.  asking people to "get a
grip" doesn't help: they have to know how high to jump, which
direction and which foot to stand on when they commit themselves to a
gravity-defying leap of faith.

so don't arse about: put your foot down!

good luck,

l.

Re: ARM promising platform, needs to learn from PC.

[Luke Kenneth Casson Leighton]

this one's again a very good statement of the problem, with hints in
it that say what the solution is ["accept common open standards"].

short version: punish selfishness [back of the patch queue i.e.
never], and reward cooperation [front of the patch queue].

only you can lay down the law on this one, linus.  nobody else.

http://linux.slashdot.org/comments.pl?sid=2386322&cid=37133042

"Actually it is the other way around. The x86 platform is mostly based
on open standards. There are more 486-compatible clones than you may
realise. ARM, on the other hand, is strongly proprietary. There are no
clones at all. The ARM fragmentation has occurred because of a lack of
open standards - while the PC guys were standardising PCI, USB and
VGA, every ARM licensee was reinventing the wheel to give their own
SoC the features that nobody else had. While the core ISA is always
the same, the system architecture is not.

When ARM CPUs were only used for embedded systems, this was fine,
because each vendor could provide a BSP for each supported OS. Now
that ARM CPUs are being used in general-purpose computers like Windows
Phone 7 and Android handsets, the fragmentation has become an issue
preventing users from loading alternative firmware. Clearly, this is a
concern for Linus Torvalds (and Linux supporters who understand the
issue) as it causes pain for kernel development and makes it
essentially impossible to produce a single OS that could be installed
(say) on any ARM-based smartphone."

 or a tablet.  or a laptop.  or a netbook.  or a smartbook.  or a
[dumb]phone.  or a GSM module.  or a 3G module.  or a Marvell WIFI
module.  or a real-time Engine Control Unit.  or an industrial
embedded controller.

 someone else pointed out that you *can't* have "common hardware
design" right across the board... but you can at least have "common
hardware designs" across areas that are... well... common!   hardware
ODMs could group together based around tablets.  the situation where
there is one design of 7in tablet motherboard per OEM per CPU, one
design of 10in tablet motherboard per OEM per CPU, is bloody
ridiculous!

anyway.  enough.  i've made the point.  i look forward to hearing from
you on this, linus.  even if it's "hmmm..." or "go away you insane
babbling idiot!".

btw - anyone else got any good ideas?

l.

Re: ARM promising platform, needs to learn from PC.

[Luke Kenneth Casson Leighton]

in http://thread.gmane.org/gmane.linux.kernel/1114495/focus=112007,
with subject "[GIT PULL] omap changes for v2.6.39 merge window" in
which the topic discussed has nothing to do with the subject (so glad
to see i'm not the only one who does that...), Thomas Gleixner said:

> I'm sure that device tree is part of the solution, but that only helps
> if we find a way to prevent duplicate drivers in the first place.

well if you apply the proposed "selfish patches are automatically
rejected in favour of collaboration patches" rule, there won't *be*
any duplicate drivers, only shared (i.e. collaborative) ones.

problem's solved, yes?

in the case of peripheral "cores" (e.g. a USB-3 Hardware Macro Block
which multiple SoC vendors license from e.g. Synopsys and lay down as
part of the CPU) i bet you that enough "Hell On Earth" for SoC vendors
whose kernel patches get rejected (because they're classified as
"selfish") would ultimately result in the actual designers of those
"cores" (e.g. Synopsys) writing the actual linux driver code
themselves.

under such circumstances, if the actual designer of the Hardware Macro
Block actually wrote the bloody linux driver, it would a) fit the
"collaborative patches rule", b) save the SoC vendors a job
reimplementing driver code c) stop the SoC vendors from submitting
duplicate drivers.

it might happen.  pigs might fly, but it might happen.

l.

Re: ARM promising platform, needs to learn from PC.

[Luke Kenneth Casson Leighton]

dear linus,

i've written this up, including some examples in FAQ form that would
and would not satisfy the proposed "selfish-is-out, cooperation-is-in"
patch-acceptance rule, here:
http://lkcl.net/linux/linux-selfish.vs.cooperation.html

comments greatly appreciated, as would additional examples to add to the FAQ.

l.

Re: ARM promising platform, needs to learn from PC.

[Florian Fainelli]

Hello,

On Friday 19 August 2011 04:02:33 Luke Kenneth Casson Leighton wrote:
> dear linus,
> 
> i've written this up, including some examples in FAQ form that would
> and would not satisfy the proposed "selfish-is-out, cooperation-is-in"
> patch-acceptance rule, here:
> http://lkcl.net/linux/linux-selfish.vs.cooperation.html
> 
> comments greatly appreciated, as would additional examples to add to the
> FAQ.

Most of your examples, especially the RDC is example is just badly chosen.

I had patches supporting this sub arch acccepted until we could get rid of it 
and make it work with the generic x86 infrastructure. The only thing that has 
not been accepted yet is some kind of "cpuid-like" feature for RDC.

The rdc321x GPIO driver has been accepted mainline and only serves on RDC-
based SoC.

Sorry to say that, but I do not understand the point of your FAQ, most people, 
if explained with good reasons, would accept a new architecture/SoC/sub-arch, 
but that's also at the price of the submitter to eventually rethink its way of 
supporting the architecture (Device Tree, code re-organisation ...).
-- 
Florian

Re: ARM promising platform, needs to learn from PC.

[Luke Kenneth Casson Leighton]

On Fri, Aug 19, 2011 at 10:04 AM, Florian Fainelli <florian@openwrt.org> wrote:
> Hello,
>
> On Friday 19 August 2011 04:02:33 Luke Kenneth Casson Leighton wrote:
>> dear linus,
>>
>> i've written this up, including some examples in FAQ form that would
>> and would not satisfy the proposed "selfish-is-out, cooperation-is-in"
>> patch-acceptance rule, here:
>> http://lkcl.net/linux/linux-selfish.vs.cooperation.html
>>
>> comments greatly appreciated, as would additional examples to add to the
>> FAQ.
>
> Most of your examples, especially the RDC is example is just badly chosen.

 ok, that's good to hear - that's a valuable opinion to hear, on a
work-in-progress, and i look forward to receiving positive
contributions which help improve the document.  do you have any
suggestions on how they might be improved?  or, do you have any other
examples which might best fit?

 or, do you feel that the examples require further clarification, or
perhaps references?

 positive thoughts and contributions will make progress, end-result an
improvement of the lives of the Free Software Developers who work on
the linux kernel.


> I had patches supporting this sub arch acccepted until we could get rid of it
> and make it work with the generic x86 infrastructure. The only thing that has
> not been accepted yet is some kind of "cpuid-like" feature for RDC.
>
> The rdc321x GPIO driver has been accepted mainline and only serves on RDC-
> based SoC.

 ... and there are multiple devices using the RDC-based SoCs, yes?
not just one hardware device, yes?  therefore, under the
"collaboration is ok" proposed rule, it's "in".

i tell you what - i'll put in an extra example (preceding it), which
says "we are a SoC manufacturer, we have created a custom CPU, we have
placed it into one and only one hardware design, and we are
restricting the SoC to sole and exclusive use in that hardware.
please accept our one-SoC, one-design linux kernel patches".  Answer:
not a cat in hell's chance.

is that sufficient explanation and clarification?

if not, what would you suggest?  in what way should the example be
improved and clarified?

> Sorry to say that, but I do not understand the point of your FAQ,

 i apologise - the point is, as stated, to clarify through specific
examples, the goal / aim of the proposed rule [punish selfish patches,
reward cooperative and collaborative patches].

 the reason for doing so is quite simple: the goal / aim is so
incredibly and profoundly simple that it may prove hard for people to
appreciate.

 thus, the examples are some more "concrete" ways to guide people who
are simply not used to thinking in strategic terms, "what is utterly
utterly selfish" and "what is cooperative and collaborative".

 corporations are pathologically and utterly selfish beyond thought
and reason, and will take, and take, and take, and take until all
resources are consumed.

 much like Cancer.

 this is a way to stop that cancerous pathological consumption of Free
Software Developers' resources.


> most people,
> if explained with good reasons, would accept a new architecture/SoC/sub-arch,
> but that's also at the price of the submitter to eventually rethink its way of
> supporting the architecture (Device Tree, code re-organisation ...).

 sorry to ask this, but could you clarify the "rethinking" that you
are hypothetically suggesting?  for example, a code re-organisation
that has some expected and anticipated benefit that would, under the
*present* rules, be perfectly acceptable, and likewise for "Device
Tree"?

 the reason why i ask is because i think you'll find that certain
kinds of code re-organisations as well as Device Tree redesigns would
still fall into the category of "pure selfishness and free-loading on
Free Software Developers' time and resources".

 i'd like to double-check that.

Re: ARM promising platform, needs to learn from PC.

[Florian Fainelli]

Hello,

On Friday 19 August 2011 12:57:38 Luke Kenneth Casson Leighton wrote:
> On Fri, Aug 19, 2011 at 10:04 AM, Florian Fainelli <florian@openwrt.org> 
wrote:
> > Hello,
> > 
> > On Friday 19 August 2011 04:02:33 Luke Kenneth Casson Leighton wrote:
> >> dear linus,
> >> 
> >> i've written this up, including some examples in FAQ form that would
> >> and would not satisfy the proposed "selfish-is-out, cooperation-is-in"
> >> patch-acceptance rule, here:
> >> http://lkcl.net/linux/linux-selfish.vs.cooperation.html
> >> 
> >> comments greatly appreciated, as would additional examples to add to the
> >> FAQ.
> > 
> > Most of your examples, especially the RDC is example is just badly
> > chosen.
> 
>  ok, that's good to hear - that's a valuable opinion to hear, on a
> work-in-progress, and i look forward to receiving positive
> contributions which help improve the document.  do you have any
> suggestions on how they might be improved?  or, do you have any other
> examples which might best fit?

Most if not all of the x86 platforms that I know about (OLPC, RDC, Moorestown, 
CE4100 ...) are supported, and they introduced positive refactoring of the x86 
code when they got submitted for inclusion.

> 
>  or, do you feel that the examples require further clarification, or
> perhaps references?

Yes, definitively include references in your document.

> 
>  positive thoughts and contributions will make progress, end-result an
> improvement of the lives of the Free Software Developers who work on
> the linux kernel.
> 
> > I had patches supporting this sub arch acccepted until we could get rid
> > of it and make it work with the generic x86 infrastructure. The only
> > thing that has not been accepted yet is some kind of "cpuid-like"
> > feature for RDC.
> > 
> > The rdc321x GPIO driver has been accepted mainline and only serves on
> > RDC- based SoC.
> 
>  ... and there are multiple devices using the RDC-based SoCs, yes?
> not just one hardware device, yes?  therefore, under the
> "collaboration is ok" proposed rule, it's "in".

Yes there are thousands of devices using that SoC out there.

> 
> i tell you what - i'll put in an extra example (preceding it), which
> says "we are a SoC manufacturer, we have created a custom CPU, we have
> placed it into one and only one hardware design, and we are
> restricting the SoC to sole and exclusive use in that hardware.
> please accept our one-SoC, one-design linux kernel patches".  Answer:
> not a cat in hell's chance.
> 
> is that sufficient explanation and clarification?

That's definitively clearer and better.

> 
> if not, what would you suggest?  in what way should the example be
> improved and clarified?
> 
> > Sorry to say that, but I do not understand the point of your FAQ,
> 
>  i apologise - the point is, as stated, to clarify through specific
> examples, the goal / aim of the proposed rule [punish selfish patches,
> reward cooperative and collaborative patches].
> 
>  the reason for doing so is quite simple: the goal / aim is so
> incredibly and profoundly simple that it may prove hard for people to
> appreciate.
> 
>  thus, the examples are some more "concrete" ways to guide people who
> are simply not used to thinking in strategic terms, "what is utterly
> utterly selfish" and "what is cooperative and collaborative".
> 
>  corporations are pathologically and utterly selfish beyond thought
> and reason, and will take, and take, and take, and take until all
> resources are consumed.
> 
>  much like Cancer.
> 
>  this is a way to stop that cancerous pathological consumption of Free
> Software Developers' resources.
> 
> > most people,
> > if explained with good reasons, would accept a new
> > architecture/SoC/sub-arch, but that's also at the price of the submitter
> > to eventually rethink its way of supporting the architecture (Device
> > Tree, code re-organisation ...).
> 
>  sorry to ask this, but could you clarify the "rethinking" that you
> are hypothetically suggesting?  for example, a code re-organisation
> that has some expected and anticipated benefit that would, under the
> *present* rules, be perfectly acceptable, and likewise for "Device
> Tree"?

I would direct you to LWN.net if you are not reading it already to better 
understand how using things like Device Tree can befenit in code reusing and 
IP blocks reusing in particular.

> 
>  the reason why i ask is because i think you'll find that certain
> kinds of code re-organisations as well as Device Tree redesigns would
> still fall into the category of "pure selfishness and free-loading on
> Free Software Developers' time and resources".
> 
>  i'd like to double-check that.

-- 
Florian

Re: ARM promising platform, needs to learn from PC.

[Luke Kenneth Casson Leighton]

> I'm suggesting splitting out the crazy part into a separate project
> that does this. Open-source. Like a mini-kernel.

 linus, i'm surprised, shocked even!  are you seriously proposing that
the linux kernel be split into two, ooo, i dunno... something along
the lines of a core and an OSKit v2.0?  the last time OSKit was
created it didn't go down too well :)  but seriously: yes, i also came
up with this idea, and, whilst it sounds like a great idea in
principle, it is merely "moving the problem".

 likewise with any other ideas such as allowing the linux kernel to be
a userspace application (running under L4KA or other microkernel).

 so i think you'll find that whilst such ideas are great in principle,
they merely solve _your_ stress levels, not anyone else's :)

> Because the thing is,
> the main kernel doesn't care, and _shouldn't_ care. Those board files
> are just noise.

 yes, and they're necessary.  they link everything together, for the
actual real-world manufacturer shipping the real-world customised
one-of-a-kind mass-volume product, of which there are merely many many
thousands if not millions of units sold.

 yes, it initially sounded like i was arguing "in favour" of those...
noisy-board-files, but you can see - if you read to the end of the
sentence - i'm most certainly not.

 this is where the "selfish patch is out, collaborative patches are
in" rule would come into play.

 under the proposed rule, such board files would *not* qualify.

 however, if that board file was for a device that was part of a
collaboration (such as: it was for the pandaboard, IMX53QSB, or its
hardware CAD/CAM files were available under an OSI-Approved License),
i would argue that it *should* qualify.

 i've listed examples of each, in the FAQ.

 it would be good to be able to clearly link each concrete example to
a real-world case where linux developers have clearly gone "argggh!",
to evaluate how effective the proposed "selfish is out, collaboration
is in" rule would be.

 l.

Re: ARM promising platform, needs to learn from PC.

[Luke Kenneth Casson Leighton]

At some point, in a random thread, a highly respected but very
depressed ARM linux kernel developer wrote:

> What's the way out of this?  I've no idea.  Can ARM continue being part
> of the mainline kernel?  I've no idea.  Will we be ripping out all the
> ARM platform code from the mainline kernel?  I've no idea.

> I am now completely demotivated.

dear russell,

the purpose of the proposed "selfish is out, collaboration is in"
patch rule is ultimately to allow you to feel that what you're doing
is actually encouraging people to cooperate and help each other - the
complete opposite of the present situation.

right now, you're being massively taken advantage of.  not by your
peers, but by pathological cancerous Corporations who expect you to
clean up their mess and do unpaid work for them, so that they can make
absolute maximum profits.

i'd say you were absolutely within perfectly reasonable rights to tell
everyone to f*** off until there is a solution, and the only puzzling
question i have to ask is why in god's name have you tolerated things
for so long?? :)

can i therefore respectfully ask for your thoughts on the proposed
rule (and in particular, on the examples which help clarify matters)?
is it pure bullshit, or what?

warm regards,

l.

Re: ARM promising platform, needs to learn from PC.

[Luke Kenneth Casson Leighton]

On Fri, Aug 19, 2011 at 12:47 PM, Florian Fainelli <florian@openwrt.org> wrote:
> Hello,

 hii florian

> On Friday 19 August 2011 12:57:38 Luke Kenneth Casson Leighton wrote:
>> On Fri, Aug 19, 2011 at 10:04 AM, Florian Fainelli <florian@openwrt.org>
> wrote:
>> > Hello,
>> >
>> > On Friday 19 August 2011 04:02:33 Luke Kenneth Casson Leighton wrote:
>> >> dear linus,
>> >>
>> >> i've written this up, including some examples in FAQ form that would
>> >> and would not satisfy the proposed "selfish-is-out, cooperation-is-in"
>> >> patch-acceptance rule, here:
>> >> http://lkcl.net/linux/linux-selfish.vs.cooperation.html
>> >>
>> >> comments greatly appreciated, as would additional examples to add to the
>> >> FAQ.
>> >
>> > Most of your examples, especially the RDC is example is just badly
>> > chosen.
>>
>>  ok, that's good to hear - that's a valuable opinion to hear, on a
>> work-in-progress, and i look forward to receiving positive
>> contributions which help improve the document.  do you have any
>> suggestions on how they might be improved?  or, do you have any other
>> examples which might best fit?
>
> Most if not all of the x86 platforms that I know about (OLPC,

 ah you mean the Geode LX :)  beautiful chip.  self-clocking, no power
management needed.  amazing.

> RDC, Moorestown,
> CE4100 ...) are supported, and they introduced positive refactoring of the x86
> code when they got submitted for inclusion.

 yes.  ok.  i take it that the positive refactoring involved making
lives easier for all maintainers involved? thus it would count as
non-selfish collaboration, and would thus clearly and easily qualify
under the proposed rule.

>>
>>  or, do you feel that the examples require further clarification, or
>> perhaps references?
>
> Yes, definitively include references in your document.

 ok.  i'm working on that.  i'm looking for one in amongst this lot:
http://thread.gmane.org/gmane.linux.kernel/1114495/focus=112007

 it's the one i spotted where someone said that there were drivers
submitted by SoC manufacturers that, because the hard macro which he
referred to as a "node" e.g. a USB-2 macro came from the exact same
Silicon Design House, were exactly the same.  but because they were
submitted by different SoC manufacturers, the code was (evidently)
duplicated.

>>  ... and there are multiple devices using the RDC-based SoCs, yes?
>> not just one hardware device, yes?  therefore, under the
>> "collaboration is ok" proposed rule, it's "in".
>
> Yes there are thousands of devices using that SoC out there.

 then that would definitely count.  although, hypothetically, if those
thousands of devices were all from the one hardware supplier (i know
they're not in this case) then i would argue that it would not, on the
basis that it was "selfish" and "self-centred" of that hardware
supplier.

 then again, as you can see, i give *another* example where, despite
the selfish nature of the hardware supplier, it turns out that there
are dozens if not hundreds of people, unrelated to that hardware
supplier, who are collaborating and cooperating around that
"selfishly-designed" device, and i would argue that any patches
submitted by that community (or through the hardware supplier on
behalf of that community) *should* be accepted, if sufficient evidence
is presented which proves that collaboration and cooperation is taking
place.

 actually... funnily enough, many of the openwrt devices would qualify
as this kind of example! :)  they're designed utterly selfishly (and
usually GPL-violating), then Free Software Developers reverse-engineer
them and re-create the linux kernel sources, for the benefit of
others.

 so it's not a hard-and-fast rule, it's very very loose and generic,
aimed at turning the Linux Free Software Kernel _back_ into a
collaborative project, instead of being a lackey and a punching-bag
for a bunch of pathological corporations who sponge off of the
goodwill of the Free Software Community.


>> i tell you what - i'll put in an extra example (preceding it), which
>> says "we are a SoC manufacturer, we have created a custom CPU, we have
>> placed it into one and only one hardware design, and we are
>> restricting the SoC to sole and exclusive use in that hardware.
>> please accept our one-SoC, one-design linux kernel patches".  Answer:
>> not a cat in hell's chance.
>>
>> is that sufficient explanation and clarification?
>
> That's definitively clearer and better.

 ok good stuff.  added.

 thanks florian.

 l.