Session:The Relationship Between Development and the Use of Linux for Embedded Applications ELC 2008

Revision as of 13:15, 12 August 2013 by Tim Bird (Talk | contribs)

Jump to: navigation, search

Session Details

ELC 2008 (Mountain View)
April 16 2008
Andrew Morton
55 minutes


Andrew will summarize the development and decision-making processes. Special focus will be placed upon how they impact the developers of Linux for embedded products, including the economics of using a modern kernel versus staying on a frozen older kernel version, and the economics of maintaining private patchsets versus merging work back into the public kernel. For those who choose to work with the team, Andrew will look at how that can most effectively be done. Andrew works with Linus Torvalds and other members of the Linux development community (including open source developers and distribution vendors and industry contributors) to shepherd new features and quality improvements into the Linux kernel.


Andrew has worked at Nortel Networks' R&D labs, and Digeo Interactive, a maker of digital home entertainment products. He is currently employed by Google, working fulltime on the Linux kernel. His long experience with Linux development, and experience in the embedded realm, give Andrew a unique and valuable perspective on the issues facing embedded Liux developers.


Reports on this talk are at: and


Transcribed by
Verified by
1 -

0:00 - 1:00:

1:00 - 2:00:

2:00 - 3:00:

3:00 - 4:00:

4:00 - 5:00:

5:00 - 6:00:

6:00 - 7:00:

7:00 - 8:00:

8:00 - 9:00:

9:00 - 10:00:

10:00 - 11:00:

11:00 - 12:00:

12:00 - 13:00:

13:00 - 14:00:

14:00 - 15:00:

15:00 - 16:00:

Over time, it will help prioritize it was work. You help people understand what things are most beneficial to the most users as they work on the Linux kernel.

I find that a lot of people are monitoring the mailing lists, websites, release announcements and that sort of things. Often they come to conferences and people tell me things they didn't know. And that's bad. I shouldn't not know anything. If you know something that is potentially of use to the kernel, to help or guide development, tell us. And a way to tell us, is by sending an e-mail to you-know-which-mailinglist. Tell us what you need. There's no way we can do it if we don't know that there's a need.

Another way in which a person can contribute to development is to review the patches as they go past.

16:00 - 17:00:

You can help us to check if the change will not damaging to embedded in any way. You may see a feature which is close to what you need, but it needs a few tweaks to be more useful. Please tell us! Reviewing the patches, checking them for correctness and suitability for your application is direct contribution and it's not a lot of work.

"Squeaky gates get the oil" is an old English phrase in that the person who makes the most noise, is the one that gets the most attention. I'm afraid that's how kernel work is. There's historically been a group of people who were very good at making a lot of fuss about for example latency on a desktop and as a consequence, quite a lot of developers and resources have been devoted to improving the latency on desktops for multimedia applications and games.

17:00 - 18:00:

That wouldn't have happened if the first people hadn't appeared on the mailing list and make us look bad. So if you want something done; come on the mailing list and make us look bad. Chances are, it will happen.

What a secretly fruitful group embedded is. All ### and companies making embedded products. They tend to sit on their own pile of patches which they think are only relevant to your own product and you maintain them out of tree. Consequently, these patches get larger and larger and your ### becomes older and older and it becomes harder and harder to ###. and basically never gets merged in the mainline tree.

18:00 - 19:00:

it's quite a bit of work to make a patch to merge with the mainline tree. I hope the main reason why people sit on their work without sending it upstream is because it's quite a lot of work to get it upstream. But I've also heard of companies who want to keep the patches to themselves because they believe they will be beneficial to their competitors.

sorry, that's not a good reason. This is an open source product. Yes, it will potentially be some small damage if software becomes available to your competitors, but I think you have to see that as the price of admission to use Linux. It's an open source product, everybody else is contributing into it, you have at least the moral, if not a legal obligation to contribute to it yourself.

Another problem of patch hoarding is that it gets increasingly expensive over time as you have to roll forward through kernel versions.

19:00 - 20:00:

20:00 - 21:00:

21:00 - 22:00:

22:00 - 23:00:

23:00 - 24:00:

24:00 - 25:00:

25:00 - 26:00:

26:00 - 27:00:

27:00 - 28:00:

28:00 - 29:00:

29:00 - 30:00:

30:00 - 31:00:

31:00 - 32:00:

32:00 - 33:00:

33:00 - 34:00:

34:00 - 35:00:

35:00 - 36:00:

36:00 - 37:00:

37:00 - 38:00:

38:00 - 39:00:

39:00 - 40:00:

40:00 - 41:00:

41:00 - 42:00:

42:00 - 43:00:

43:00 - 44:00:

44:00 - 45:00:

45:00 - 46:00:

46:00 - 47:00:

47:00 - 48:00:

48:00 - 49:00:

49:00 - 50:00:

50:00 - 51:00:

51:00 - 52:00:

52:00 - 53:00:

53:00 - 54:00:

54:00 - 55:00:

55:00 - 56:00:

56:00 - 57:00:

57:00 - 58:00:

58:00 - 59:00:

59:00 - 60:00: