1 yyyy-mm-dd <the title of the document> <security - PowerPoint PPT Presentation

1 yyyy-mm-dd <the title of the document> <security class>

Senior Software Engineer at Sony Mobile Communications Architecture Group Chair of the CE Workgroup at the Linux Foundation Former CTO of Lineo, an early embedded Linux company Have been doing Linux for 22 years now… 2 yyyy-mm-dd <the title of the document> <security class>

I’ve been involved with CE Linux Forum and Linux Foundation (CE Workgroup) for over 10 years Have noticed a disturbing pattern: Many companies that use and modify open source are not actively involved in the community Big problem with mainline support for SoCs used in mobile products 3 yyyy-mm-dd <the title of the document> <security class>

4 yyyy-mm-dd <the title of the document> <security class>

CE Workgroup project to identify problem areas with mainlining, and try to address them Although companies use open source software… If they don’t work with community, they are missing a big part of the value Companies are working too hard when using open source 5 yyyy-mm-dd <the title of the document> <security class>

Sony Mobile has about 200 software engineers working on the kernel We migrate about 1800 patches between product trees, every phone release That’s for one open source software component 6 yyyy-mm-dd <the title of the document> <security class>

Sony Mobile has about 200 software engineers working on the kernel We migrate about 1800 patches between product trees, every phone release That’s for one open source software component I want to talk about ways to fix this… 7 yyyy-mm-dd <the title of the document> <security class>

What is engagement? Identify obstacles Describe obstacles Things you should do Best Practices Why do this? Device Mainlining project 8 yyyy-mm-dd <the title of the document> <security class>

What is engagement? Identify obstacles Describe obstacles Things you should do Best Practices Why do this? Device Mainlining project 9 yyyy-mm-dd <the title of the document> <security class>

10 yyyy-mm-dd <the title of the document> <security class>

More than just users of open source code More than just complying with the license by publishing your code Engagement means working within the community Explaining requirements Interacting in forums Making modifications Upstreaming , or “mainlining” your changes Helping create the features both you and your competitors need 11 yyyy-mm-dd <the title of the document> <security class>

More than just users of open source code More than just complying with the license by publishing your code Engagement means working within the community Explaining requirements Interacting in forums Making modifications Upstreaming , or “mainlining” your changes Helping create the features both you and your competitors need 12 yyyy-mm-dd <the title of the document> <security class>

Anna Karenina Principle "Happy families are all alike; every unhappy family is unhappy in its own way" There are lots of ways to fail, but only a few ways to succeed Yogi Bera (American baseball player, philosopher) “If people don’t want to come out to the ballpark, nobody’s going to stop them.” Motivation is a key element 13 yyyy-mm-dd <the title of the document> <security class>

14 yyyy-mm-dd <the title of the document> <security class>

Conducted an online survey in September 2014 Goal was to find qualified kernel developers, who do NOT submit patches upstream And determine “why not?” 15 yyyy-mm-dd <the title of the document> <security class>

Top obstacles: 16 yyyy-mm-dd <the title of the document> <security class>

Developer motivation: It is important to submit change upstream: 92% I would like to submit changes upstream: 91% Management motivation: Management doesn’t approve: 21% Employer doesn’t provide time: 40% Interesting non-issues: English not good enough: 9% Not my responsibility: 6% Company process too hard: 26% 17 yyyy-mm-dd <the title of the document> <security class>

Version gap (working on older kernel) Perceived difficulty Low-quality or specialized code Dependency on non-mainlined code Not enough time 18 yyyy-mm-dd <the title of the document> <security class>

19 yyyy-mm-dd <the title of the document> <security class>

Many companies use a vendor tree Particularly true for products with Android Get your kernel and distribution from your hardware supplier Are locked in because of processor or SOC selection Some amount of patches on top of kernel.org Linux Development/Testing/Release schedules causes delay in kernel version 20 yyyy-mm-dd <the title of the document> <security class>

Delta between Sony Mobile and mainline kernel Sony mobile dependent on upstream supplier for Linux version (3.4 in this case) Lots of patches between Sony tree and mainline 16 kernel versions, 3 years 26,000 commits and 1.8 millions lines of code 21 yyyy-mm-dd <the title of the document> <security class>

Kernel is continually changing The farther you are from mainline, the harder to contribute code Community can only take code against current version of the kernel 22 yyyy-mm-dd <the title of the document> <security class>

Process is cumbersome if you are not familiar List of requirements for a contribution is long SubmittingPatches, SubmitChecklist, CodingStyle Good, but don’t cover a variety of social issues Getting anything wrong can result in failure Lots of details which maintainers take for granted Not as strict as it used to be, and there are now tools to assist (e.g. checkpatch.pl) 23 yyyy-mm-dd <the title of the document> <security class>

Maintainers are strict and terse due to overload Don’t have time for malformed contributions Silly mistakes cause quick rejection, or worse, patch is ignored Part-time contributors Switching cost of juggling between contributing and product development is high Similar to high-latency scheduling – results in overall poor performance Not doing full-time contributing means that proficiency in open source methods is developed slowly Can result in bad response time to provided feedback 24 yyyy-mm-dd <the title of the document> <security class>

Required expertise is very high (and increasing) Kernel is quite mature, and serves lots of markets It requires skill to not degrade other people’s use cases This is true for core systems, but not drivers Proxy problem – someone other than author is contributing the code (will be discussed later) 25 yyyy-mm-dd <the title of the document> <security class>

Low-quality Workarounds and quick hacks Specialized code Handles only the specific use case for that market Attitude that code is “throwaway”, or that code is “good enough” for one embedded product release Assumption that reuse is not needed Not generalized for other use cases Code written in different style than mainline 26 yyyy-mm-dd <the title of the document> <security class>

Modifications to drivers and systems that are not upstream Bugfixes and workarounds for code not upstream It’s unclear where to send fixes If it’s an IP block in an SOC, who should get the fixes? SOC vendor?, IP block creator? Example: bugfixes for synaptics touchscreen driver Long delays getting synaptics driver upstream Impractical, and low motivation to do mainlining in place of hardware supplier 27 yyyy-mm-dd <the title of the document> <security class>

Not enough time provided by management Product teams focused on tight delivery deadlines Causes focus on “good enough” solutions Not unique to open source software No time to respond to change requests I refer to this as the “product treadmill” Mainline versions are independent of any notion of product release dates Mainline acceptance happens when it happens, not based on your need 28 yyyy-mm-dd <the title of the document> <security class>

Classic error – everyone has done this! The error: Work on a large patch in isolation Attempt to mainline and find that major changes are needed Community mantra: “release early and often” Input from community or internal OSS experts during the development cycle can avoid large refactoring later Original development strategy makes it much harder to contribute 29 yyyy-mm-dd <the title of the document> <security class>

30 yyyy-mm-dd <the title of the document> <security class>

Solution for version gap: Get a minimal core of mainline running on your hardware Have one team working on mainline, while product engineers work on older kernel (creates the proxy problem, described later), until you catch up Solution for product treadmill Small team dedicated to mainline, off of product treadmill Solution for perceived/real difficulty Internal training, mentors Use same processes internally as upstream Avoid re-learning upstream methods E.g. Don’t manage your kernel with perforce!! Use git. 31 yyyy-mm-dd <the title of the document> <security class>