LWN Obstacles article details

Comments on LWN.NET about Obstacles to contribution in embedded Linux

Summary of ideas: 1. binary blobs should be discouraged, as they freeze downstream to particular kernel versions 2. NDAs are another obstacle to contributing 3. use staging for non-mainlinable code 4. mail patches to LKML for future reference, even if not for mainlining 5. make software costs visible 6. get hard data on costs for out-of-tree code 7. make a dumping ground for non-mainlined source possibly use automation to create it 8. vendors should release kernel source ASAP, to reduce customer wait for source 9. create a wiki page with links to source trees

Here's a wiki page to save the links to different mobile phone kernel source download sites, that I found during my analysis. It's at http://elinux.org/Phones_Processors_and_Download_Sites

Three of the above ideas are ways to make the out-of-tree code more accessible: 1) use staging, 2) mail to LKML, 3) make a dumping ground. Some of the ideas are related to exposing the cost.

Posted Jun 9, 2015 21:58 UTC (Tue) by Jonimus (subscriber, #89694) [Link] Google is part of the issue... Single-kernel image helps – discoverable buses and standardized hardware should help Posted Jun 9, 2015 23:04 UTC (Tue) by SEJeff (subscriber, #51588) [Link] Linaro is working on it, device tree helps Posted Jun 11, 2015 10:58 UTC (Thu) by broonie (subscriber, #7078) [Link] Discoverable buses are costly.

Posted Jun 9, 2015 23:58 UTC (Tue) by jg (subscriber, #17537) [Link] binary blob drivers/kernel modules "freezes" people on old kernel versions. Preparing patches against mainline (top of tree) is too time-consuming so there's no return on investment. Should require GPL drivers. Blobs will be a security problem in future. Blobs are used in comm chips and graphics devices. Posted Jun 10, 2015 3:43 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link] Vendors should consider “life of part” instead of life of device. If used over multiple products, cost/benefit tips in favor of mainlining. Part manufacturer is in better position to mainline driver, and stands to benefit more from it

Posted Jun 11, 2015 23:24 UTC (Thu) by andrel (subscriber, #5166) [Link] Incentive for longer-term software support is customers requiring it. Not enough customers pay attention.

Posted Jun 10, 2015 8:18 UTC (Wed) by edeloget (subscriber, #88392) [Link] Obstacle: NDAs are an obstacle. Once signed, you can't mainline (or even publish) code for parts.

Posted Jun 9, 2015 22:03 UTC (Tue) by jstultz (subscriber, #212) [Link] Idea: Use staging more. 1) Vendors reduce re-base cost, 2) mainline works, 3) not as much work by community maintainers. Can use staging to find if code is used over multiple years. *** Tim's response/questions: Is it less costly to upstream to staging? (it should) Does it really reduce re-base cost? Would mainline really work (is only partial support helpful)? Does it really decrease community effort? (it should)

Posted Jun 9, 2015 23:48 UTC (Tue) by gdt (subscriber, #6284) [Link] Mail patches to LKML regardless, so they're available if wanted. Provides something to start with.

Posted Jun 23, 2015 12:36 UTC (Tue) by nye (guest, #51576) [Link] Idea: Make software costs visible “As I see it the important part is the sentence that comes after that one: "The cost of software development should be figured into the bill of materials when the hardware is selected." Companies can be pretty good at cost/benefit analysis, but it requires that the costs are visible up-front, so a real practical answer is to stop pretending that certain costs don't exist.

It's easiest to assume that marginal cost is all that matters, and that development costs are amortised into something close to zero per device - easy, but often wrong. The development costs can be significant, so for anything but the highest volume devices they should be factored in, at least within an order of magnitude or so, rather than looking at nothing but the per-unit cost for the widget and imagining that that's a good indicator of the *actual* cost to the company.

Posted Jun 10, 2015 3:03 UTC (Wed) by JIghtuse (subscriber, #95703) [Link] My company has all these problems.

Posted Jun 10, 2015 16:55 UTC (Wed) by jospoortvliet (subscriber, #33164) [Link] Takes a long time and hard data to convince management. Idea: Get hard data.

Posted Jun 10, 2015 5:21 UTC (Wed) by asaz989 (subscriber, #67798) [Link] 2-team solution doesn't work decision tree looks like this: 1. Upgrade to mainline. Merging to mainline is now easy! a. forward-port code bugfixes and new features from vendor to new kernel b. don't use new code from vendor 2. Don't upgrade to mainline version. Merging vendor changes is now easy! a. forward-porting our changes in order to mainline them. b. don't bother mainlining you need to have code build for mainline kernels *from the start* to minimize this cost

“This starts with vendors - the number one determinant in how recent of a kernel my former employer shipped was how recent of a kernel our upstream drivers supported. When we wanted to get onto new kernels (or at least, ones that were EOLed within 6 months instead of ones that had been EOL for multiple years) the big problem was in vendor relations - putting as much pressure as possible on vendors to update their drivers to new kernels, or sometimes getting them to support our older hardware in newer versions of their drivers.”

Posted Jun 12, 2015 11:00 UTC (Fri) by HIGHGuY (subscriber, #62277) [Link] Obstacle: Can't forward-port driver, because mainline support is not on your board, and that's the only board you have with the device on it.

*** Tim's Idea: 1) get device on another board. (Won't work for device integrated into SoC) 2) get enough of mainline on board for that device

Posted Jun 16, 2015 7:52 UTC (Tue) by Felix.Braun (subscriber, #3032) [Link] Companies should ask about mainline status and factor in cost.

Posted Jun 10, 2015 11:54 UTC (Wed) by NAR (subscriber, #1313) [Link] Can the kernel community keep the drivers working without the rest of the hardware? *** Tim's solution: 1) get sufficient support in mainline for that driver 2) make hardware available to community

Posted Jun 14, 2015 16:05 UTC (Sun) by Hauke (guest, #103131) [Link] Drivers sometimes are not hard to forward-port (depends on interface changes)

Posted Jun 10, 2015 21:17 UTC (Wed) by tpo (subscriber, #25713) [Link] Idea: create dumping ground for non-mainlinable kernel source

Posted Jun 11, 2015 11:35 UTC (Thu) by faramir (subscriber, #2327) [Link] Idea: create a single large diff pool, using automation. Use to identify common changes/drivers by SoC

Posted Jun 14, 2015 16:15 UTC (Sun) by Hauke (guest, #103131) [Link] Idea: vendors needs to release their code as soon as possible (before product ship would be good) *** Tim idea: need ideas for how to get vendors to release sooner

Posted Jun 12, 2015 16:30 UTC (Fri) by mm7323 (subscriber, #87386) [Link] Use common pool to identify needed APIs or interfaces.

Posted Jun 14, 2015 16:57 UTC (Sun) by faramir (subscriber, #2327) [Link] Idea: Create wiki page for source tree download links

Posted Jun 14, 2015 16:54 UTC (Sun) by dirklwn (subscriber, #80581) [Link] two-team approach is hard because good developers get swallowed into product teams. So far, don't see lots of patches (<100 out of 1800) to mainline. How much does this gain?

Cars have hard requirements, and require lots of QA (leading to more version gap). Optimizations for fast booting and other things lead to re-specialization, which is not mainlinable.