Linux Kernel Development:
Getting Started
Randy Dunlap
Linux Kernel Developer,
Mentor, and Janitor
IEEE Northcon
May 19, 2005
Copyright 2005 Randy Dunlap, All rights reserved.
Agenda
■ Timetable: 10:00am – 3:00pm with 15minute break every hour,
plus lunch
■ Lots of time for questions and discussion
■ Abstract:
■ Linux development is fastpaced and [as they say in Oregon] “things
are different here.” This tutorial introduces some of the Linux culture
and how to get things done well.
2
Copyright 2005 Randy Dunlap, All rights reserved.
Topics
■ Open source development style, values, culture
■ Linux rapid development cycle
■ Linux “maintainers” and hierarchy
■ Communications methods
■ Advantages of having a driver in the mainline kernel tree
■ Coding style
■ How to submit Linux kernel patches
■ Some best known practices
■ Legal/Licenses
■ Testing
■ Working in the Linux kernel tree
3
Copyright 2005 Randy Dunlap, All rights reserved.
Major Goals
■ Encourage new device driver development and support
■ Driver code merged and maintained in mainline (GPL)
4
Copyright 2005 Randy Dunlap, All rights reserved.
Development Style, Values, and Culture
■ Learning curve, things are different
■ Meritocracy – good ideas & good code are rewarded
■ Chance to work on a real OS – any parts of it that interest you
■ Massive amounts of open communication via email, IRC, etc.
5
Copyright 2005 Randy Dunlap, All rights reserved.
Linux Culture
■ Work in open, not behind closed doors (in smokefilled rooms) #
■ Community allegiance is very high
■ Do what is right for Linux
■ Meritocracy: good ideas and good code are rewarded
■ Often driven by ideals and pragmatism, bottomup development
■ Not driven by marketing requirements
■ Don't just take, give back too: #
■ Modifications are & remain GPL (if distributed)
■ Payment in kind, selfinterest
■ Improve software quality, features used/understood more
6
Copyright 2005 Randy Dunlap, All rights reserved.
Linux Culture (2)
■ Committed to following and using standards (e.g., POSIX, IETF)
■ Committed to compatibility with other system software
■ Informal design/development: Not much external highlevel project
planning or design docs (maybe some internally at companies); can
appear to be chaotic
■ New ideas best presented as code, not specifications or
requirements
■ RERO: Release Early, Release Often for comments, help, testing,
community acceptance #
■ Possible downsides: flames, embarrassment
7
Copyright 2005 Randy Dunlap, All rights reserved.
Linux Culture (3)
■ Development community is highly technical
■ Motivated and committed, but since many are volunteers, treat them
with respect and ask/influence them, don't tell
■ Continuous code review (including security)
■ Continuous improvement
■ Have fun!! :)
■ Follow the culture
8
Copyright 2005 Randy Dunlap, All rights reserved.