Difference between revisions of "Kernel Mainlining"

From eLinux.org
Jump to: navigation, search
(add list of related talks - start filling in details)
(add notes on deepak's presentation)
Line 43: Line 43:
 
== Specific Projects ==
 
== Specific Projects ==
 
* [[Qualcomm SOC Mainlining Project]]
 
* [[Qualcomm SOC Mainlining Project]]
 +
 +
== Notes for Best Practices ==
 +
(from Deepak:
 +
* don't be arrogant - don't assume your experience in proprietary development methods translates into open source
 +
** be humble and listen to others
 +
* release early and often
 +
** not doing this wastes a lot of time on implementations that get discarded, rewritten
 +
* do your homework
 +
** see what's already there in Linux, and whether it can be extended to support your case
 +
** add to existing abstractions rather than add your uniqe solution (be willing to abandon your code, as long as you ultimately get support for your feature upstream)
 +
* don't add OS abstractions (or, HALS for other OSes)
 +
** drivers must be Linux native - other layers and abstractions complicate the drivers - they can't be maintained by Linux kernel developers
 +
* do add abstractions - don't just solve your immediate problem
 +
** write systems that suport multiple related hardware
 +
** be willing to generalize
 +
* do your homework
 +
** use mainlining resources
 +
** ask informed questions
 +
* work with the community - treat them as equals on your team
 +
** treat external developers input as you would your own team members
 +
** be respectful
  
 
[[category:kernel]]
 
[[category:kernel]]

Revision as of 11:36, 11 July 2014

This page has information for embedded developers about mainlining patches to the Linux kernel.

General Resources

Presentations

Greg KH has a great presentation about how the community works, with links to references for getting started:

An older talk (2008) by Andrew Morton discusses the reasons to contribute, and best practices for contributing to the upstream kernel

Here is a list of talks about mainlining and community involvement, from previous Linux conferences:

  • How to Participate in the Kernel Development Process (PDF) - ELC-2007, April 2007, Jonathan Corbet
    • This talk is an attempt to identify the factors which lead to success or failure and present them in a way that will help others seeking to get code into the kernel.
  • ELC-2008 morton (noted above)
  • Appropriate Community Practices: Social and Technical Advice - ELC-2008, April 2008 Deepak Saxena
    • Abstract: With the increasing popularity of Linux in the embedded world, HW vendors are jumping on the bandwagon to add kernel support for their devices/chipsets/SOCs. We in the community keep seeing the same mistakes made (both technical and social) repetitively. We will go over the benefits of being involved with the community and utilize examples of what not do when working within the Linux development ecosystem to illustrate appropriate practices to increase your probability of successful code adoption into the kernel.org tree.
    • (presentation not available)
  • ELCE-2008 David Woodhouse
  • ELC-2009 David Woodhouse
  • ELC-2009 Jeff Osier-Mixon
  • ELC-2011 Arnd Bergmann*
  • ELCE-2011 Satoru Ueda
  • ELCE-2012 Matt Locke
  • ELC-2013 rose
  • ELC-2013 chalmers
  • ELC-2014 maupin

Training, tutorials and challenges

  • The Outreach Program For Women has an excellent tutorial on the steps for contributing one's first patch to the kernel

Specific Projects

Notes for Best Practices

(from Deepak:

  • don't be arrogant - don't assume your experience in proprietary development methods translates into open source
    • be humble and listen to others
  • release early and often
    • not doing this wastes a lot of time on implementations that get discarded, rewritten
  • do your homework
    • see what's already there in Linux, and whether it can be extended to support your case
    • add to existing abstractions rather than add your uniqe solution (be willing to abandon your code, as long as you ultimately get support for your feature upstream)
  • don't add OS abstractions (or, HALS for other OSes)
    • drivers must be Linux native - other layers and abstractions complicate the drivers - they can't be maintained by Linux kernel developers
  • do add abstractions - don't just solve your immediate problem
    • write systems that suport multiple related hardware
    • be willing to generalize
  • do your homework
    • use mainlining resources
    • ask informed questions
  • work with the community - treat them as equals on your team
    • treat external developers input as you would your own team members
    • be respectful