Debian GNU/Linux on tablet hardware

Zygmunt Krynicki zygmunt.krynicki at linaro.org
Fri Oct 28 19:30:19 UTC 2011


W dniu 28.10.2011 20:10, Luke Kenneth Casson Leighton pisze:
> On Fri, Oct 28, 2011 at 5:59 PM, Zygmunt Krynicki
> <zygmunt.krynicki at linaro.org>  wrote:
>
>
>> Disclaimer: I'm not a kernel developer. I have experience in the non-Intel
>> part of the world but I'm not the sort of person with up-to-date hands-on
>> experience. For those folks please look at traffic in
>> linaro-dev at lists.linaro.org and at our patchwork instance at
>> patches.linaro.org. You can see what kind of patches we push upstream and if
>> they have landed yet.
>
>   ok - this is potentially misleading, zygmunt, at best irrelevant.
> ok, shall i point out a correction, and you, or someone else from
> linaro, can, if it is incorrect, provide the required corrections,
> yes?

I was just trying to state my opinion that Linaro "supporting android 
kernels" is kind of misleading in its own way. While I'm not a kernel 
developer I'm deep in Linaro and I try to stay informed about what is 
going on. I would love to see responses from other Linaro engineers as 
that would correct my personal opinion if I got something wrong.

Note: if the discussion below is off-topic to the original thread please 
feel free to ignore me.

>   by mentioning the above patch queue (on the debian-arm list), then
> *despite* previously mentioning that linaro is "between the vendors
> and the kernel developers", there is a risk that people could not
> connect the dots between this and the previous paragraph (seen that
> happen so many times it's unreal) and thus it would appear - to them -
> that linaro is *still* seen to quotes be an authority unquotes
> regarding patches [for specific hardware].  the correction - if any is
> needed - is that linaro is NOT an "authority" of ANY KIND regarding
> "definitive patchsets" or in fact an authority of any kind PERIOD.

Linaro is more than a random collection of kernel hackers. The key 
advantage "we" have is that those hackers come from hardware vendors 
directly (and here I mean the people that actually design the SoC and 
then produce chips you can buy). Linaro is in a special position as it 
can attempt cross-vendor solutions on a scale nobody has attempted 
before. That is much stronger than any other group that I know of. We 
can, in a way, discuss and implement de-facto standards that the main 
ARM vendors will use in BSPs for subsequent products.

>   linaro is, in fact an "accelerator", helping SoC vendors to push
> "lowest common denominator" code into the linux kernel for the

Yes, Linaro is an accelerator. I would not, however, limit us to the 
lowest common denominator. We are working on solving the big problems 
that ARM kernel faces. That affects and involves everyone but is not 
equivalent to lowest common denominator in my opinion.

> convenience of *MULTIPLE* hardware and software developers using that
> PARTICULAR SoC, but linaro are not, repeat NOT "direct" suppliers of
> linux kernel source code for a specific device.

No, that is not our goal (to be the supplier of kernel trees for random 
hardware). What you may find interesting however is that some hardware 
device manufactures (not SoCs vendors) want to use or sometimes even 
_require_ Linaro-based trees for their devices.

I think that is a fantastic validation of our efforts. Working with 
Linaro trees is faster and thus cheaper for those vendors.

>   perhaps if any code for a particular device _is_ pushed upstream by
> linaro, it is almost "by accident", by nature of it, for example,
> being a particular example "BSP" or convenient "Reference Platform".

Not by accident and not for a particular device. Our intention is to 
support the _next_ set of SoCs in the upstream kernel. When a company 
goes out to search for devices to build their next product those SoC 
will be already enabled and not only in a random BSP package but 
straight in the upstream vanilla kernel.

>   putting it into context: linaro is paid by _SoC Vendors_.  linaro is
> *not* paid by individual Hardware Factories (afaik) to do
> hardware-specific, device-specific linux kernel development.

Some of the device vendors are coming closer to Linaro. I can cite one 
example from memory, Genesi, the manufacturer of several interesting 
freescale based products has joined Linaro to improve cooperation 
between their engineers working on next Genesi products and Linaro's 
common vision on how things should work.

>   thus in that context, whilst it is nice that linaro is doing upstream
> patches, and it's nice that you mentioned it, it is in the context of
> this discussion, "off-topic".

As stated at the beginning of this message I was attempting to correct 
an inaccurate, in my opinion, assessment of what Linaro is doing.

In a finishing note I'd like to state that the devices that we work on 
daily (and improve GNU/Linux experience on) are being used to form 
products we'll see on the market.

Initially "development boards" were a queer concept for the SoC vendors 
but I think that is rapidly changing and more vendors start to see the 
effect making those devices available on the market has on their 
ecosystem. Devices are turned into prototypes and products, more 
smaller-scale companies can participate, more code is written in the 
community to support those boards. The ecosystem grows faster.

I can point to a simple recent example: the ST-E snowball board is 
actually a full-featured product platform that can be taken from a 
"prototype" to "product" without complex hardware redesign. This means 
that one wishing to obtain a supply of hardware for a free ARM PC like 
product will find that there are many virtually identical (and well 
supported by free software) devices on the market. I think that is a 
good thing.

Best regards
Zygmunt



More information about the linaro-dev mailing list