Request review of device tree documentation

[Tim Bird]

On 06/16/2010 07:39 AM, Nicolas Pitre wrote:
> The cost function _is_ different for the Linux community and decision 
> makers at chip vendor companies. I know that for having worked long 
> enough at a prominent chip vendor already.
> 
> Those vendors want to ship a product and be first on the market before 
> the competitors do.  They grab a kernel tree, fit in their existing HAL 
> as quickly as they can, so that they are able to demo the new chip to 
> potential customers even before moving to full production.  And if the 
> HAL fitting work has been done into last year's kernel already, then 
> they will simply reuse that kernel to minimize the effort further as in 
> theory only the HAL part needs to be swapped with the new one (doesn't 
> matter if last year's kernel was itself already based on a kernel from 
> the year before).  Once the software appears to work, they send it to 
> customers and forget about it as they move to the next chip design.  So 
> here, the cost is directly related to bring-up time, and quick (or big) 
> ugly software hacks are more than a convenience but rather a necessity 
> if you want to win the race.
> 
> People from the Linux community care about totally different things. The 
> most important factor here is _long term_ maintainability.  It is 
> important that the code be clean, use a uniform coding style, and follow 
> common interfaces.  This is so because the cost function here is 
> directly related to the difficulty for the Linux community to evolve the 
> kernel with generic improvements and new features.  If each driver has a 
> different style, or rely on a different HAL, then it quickly becomes 
> extremely expensive to update those drivers along with the generic 
> improvements.  And if the HAL is in binary form only, or stuck behind 
> some unalterable BIOS-like calls or firmware API, then it may even be 
> impossible to update those drivers as the execution context assumed by 
> the HAL firmware may not be guaranteed anymore (think about UP vs SMP, 
> different preemption modes, different realtime kernel modes, etc.)  And 
> of course it is impossible to anticipate what execution context and 
> requirements the kernel might need in the future, hence this can't be 
> provisioned for (and much less validated) into the HAL design in advance 
> (and see above why it is next to hopeless to expect vendors to update 
> their HAL for old products in a timely fashion).
> 
> So there *is* indeed a big difference between both points of view.  And 
> sometimes the imperatives from each group are in total conflict.

This is absolutely correct.  At the CE Linux Forum, we've been working
for years to try to get vendors more involved in the community, with
a variety of techniques, including white papers for management,
magazine articles, outreach at industry events, and hosting our
own events to introduce "industry" and "community" developers.

It is not uncommon for vendors to throw the software away (or big
chunks of it) for each release, which is completely contrary
to the goals of mainline developers.  I once had a product line
where each year for 3 years, the product team used a different
processor ARCHITECTURE.  Stuff like that significantly impairs
the argument that they'll see big wins from mainlining things.

>>> Which of course raises the question:  How does the Linux community view such
>>> SoC vendors?  Are they embraced and eagerly supported,

No.  Mostly, they get chastised and told how wrong they are,
so they just stay away.   Any work they have done is often thrown
under the bus by people who refuse to acknowledge their requirements.
(Witness the suspend blockers thread on linux-pm).

>>> or (either openly or
>>> secretly) viewed as a nuisance?  How does the widespread objection to
>>> something that such vendors "would make extensive use of" mesh with that
>>> view?
>>
>> I cannot tell for the entire Linux community, but from what I know, such
>> vendors are not much welcomed in the community.
> 
> And the reverse is also true: those vendors are not amenable to more 
> openness and early community involvement which could help them get to 
> market with "community acceptable" support for their products due to 
> NDAs and such, or simply because of the perception that the Linux 
> community is putting too much value on "expendable software".  It is way 
> too common to hear from hardware designers that "software is cheap"... 
> which is not quite the case in the end.  That's a real pity.

Also true.  Nicolas - you're on a roll today. :-)
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Network Entertainment
=============================