Linux Kernel

Development
Greg Kroah-Hartman
[email protected]
github.com/gregkh/kernel-development


4!4"" file#
$%!%&"!""" line#
Kernel relea#e '.&."

!((& developer#
4$ companie#
Kernel relea#e# '.)." * '.&."
+a, "$ * -pril "$'

$"!)"" line# added
%!."" line# removed
$!&&" line# modified
2.6.20 to 2.6.24-rc8
Kernel relea#e# '.)." * '.&."
+a, "$ * -pril "$'

$"!)"" line# added
%!."" line# removed
$!&&" line# modified
ever, da,
2.6.20 to 2.6.24-rc8
Kernel relea#e# '.)." * '.&."
+a, "$ * -pril "$'

%.&( change# per hour
2.6.20 to 2.6.24-rc8
Kernel relea#e# '.)." * '.&."
+a, "$ * -pril "$'

..'( change# per hour
'.(." relea#e
2.6.20 to 2.6.24-rc8

Ho/ /e #ta, #ane
2.6.20 to 2.6.24-rc8
0ime ba#ed relea#e#
1ncremental change#

2e/ relea#e ever,
3 month#
Kernel relea#e# .%." * '.4."



4Longterm kernel#5
6ne picked per ,ear
+aintained for t/o ,ear#
'." and '.4
2.6.20 to 2.6.24-rc8



commit ecf85e481a716cfe07406439fdc7ba9526bbfaeb
Author: Robert Jarzmik <robert!arzmik"freefr#
Author$ate: %ue A&r 21 20:33:10 2009 '0700
(ommit: )re* +roah',artma- <*re*kh".u.ede#
(ommit$ate: %hu A&r 23 14:15:31 2009 '0700
/01: ot*: 2i3 bu* o- remo4e &ath 5ithout tra-.cei4er

6- the ca.e 5here a *ad*et dri4er i. remo4ed 5hi7e -o
tra-.cei4er 5a. fou-d at &robe time8 a bu* i-
ot*9&ut9tra-.cei4er:; 5i77 tri**er

0i*-ed'off'b<: Robert Jarzmik <robert!arzmik"freefr#
Acked'b<: $a4id 1ro5-e77 <dbro5-e77"u.er..ourcefor*e-et#
0i*-ed'off'b<: )re* +roah',artma- <*re*kh".u.ede#
''' a=dri4er.=u.b=ot*=ot*c
>>> b=dri4er.=u.b=ot*=ot*c
"" '4387 >4388 "" ?@ABR%90CD1BE:ot*9*et9tra-.cei4er;F
4oid ot*9&ut9tra-.cei4er:.truct ot*9tra-.cei4er G3;
H
' &ut9de4ice:3'#de4;F
> if :3;
> &ut9de4ice:3'#de4;F
I

Developer7# 8ertificate of 6rigin
9a: 1 created thi# change; or
9b: <a#ed thi# on a previou# /ork /ith a
compatible licen#e; or
9c: =rovided to me b, 9a:! 9b:! or 9c: and not
modified
9d: 0hi# contribution i# public.




0op developer# b, >uantit,
H. Hartle, ?/eeten $%&.
-l @iro .%$
+ark <ro/n .)
-xel Lin )(.
Aohanne# <erg )('
Daniel @etter )4.
0aka#hi 1/ai )'%
Greg Kroah-Hartman )
?achin Kamat 4%'
0eBun Heo 4'$
Kernel relea#e# '.)." * '.&."
Kernel relea#e# '.)." * '.&."
+a, "$ * -pril "$'

0op ?igned-off-b,C
Greg Kroah-Hartman .)"'
David ?. +iller 4$&.
+auro 8arvalho 8hehab .4(
Linu# 0orvald# '%$
+ark <ro/n 4
-ndre/ +orton $4(
Aohn Linville $(4$
H Hartle, ?/eeten $%&(
Daniel @etter $.'
-l @iro $")%
Kernel relea#e# '.)." * '.&."

Dho i# funding thi# /orkE
$. 4-mateur#5 $'.4F
. Ged Hat &.&F
'. 1ntel (.(F
4. Hnkno/n 1ndividual# 4.&F
). Linaro 4.F
%. 0exa# 1n#trument# '.(F
.. ?u?I '.)F
(. 1<+ '."F
&. @i#ion Ingraving '."F
$". Google .)F
Kernel relea#e# '.)." * '.&."

Dho i# funding thi# /orkE
$$. ?am#ung .4F
$. Dolf#on +icro $.4F
$'. 2vidia $.'F
$4. 8on#ultant# $.'F
$). 6racle $.'F
$%. L12<10 $.F
$.. Jree#cale $.F
$(. Linux Joundation $.$F
$&. <roadcom $.$F
". 1ngic# 0echnolog, $."F
Kernel relea#e# '.)." * '.&."

Getting involved
2.6.20 to 2.6.24-rc8
Gun the kernel.org relea#e on ,our machine

Getting involved
2.6.20 to 2.6.24-rc8

2.6.20 to 2.6.24-rc8
$ocume-tatio-=,BJ%B
$ocume-tatio-=de4e7o&me-t'&roce..
Getting involved

2.6.20 to 2.6.24-rc8
Getting involved
kernelne/bie#.org

2.6.20 to 2.6.24-rc8
Getting involved
Google 4/rite ,our fir#t kernel patch5

2.6.20 to 2.6.24-rc8
Getting involved
kernelne/bie#.org/KernelAanitor#/0odo

2.6.20 to 2.6.24-rc8
Linux Driver =roBect
dri4er.=.ta*i-*=G=%B$B
Getting involved

github.com/gregkh/kernel-development




Linux Kernel
Development
Greg Kroah-Hartman
[email protected]
github.com/gregkh/kernel-development
I'm going to discuss the how fast the kernel is
moving, how we do it all, and how you can
get involved.




4!4"" file#
$%!%&"!""" line#
Kernel relea#e '.&."
This was for the 3.9 kernel release, which
happened April 2, 2!"3.



!((& developer#
4$ companie#
Kernel relea#e# '.)." * '.&."
+a, "$ * -pril "$'
This makes the #inu$ kernel the largest
contri%uted %ody of software out there that
we know of.
This is &ust the num%er of companies that we
know a%out, there are more that we do not,
and as the responses to our in'uiries come
in, this num%er will go up.
(irst one year timespan that we have
surpassed )!! companies.



$"!)"" line# added
%!."" line# removed
$!&&" line# modified
2.6.20 to 2.6.24-rc8
Kernel relea#e# '.)." * '.&."
+a, "$ * -pril "$'



$"!)"" line# added
%!."" line# removed
$!&&" line# modified
ever, da,
2.6.20 to 2.6.24-rc8
Kernel relea#e# '.)." * '.&."
+a, "$ * -pril "$'



%.&( change# per hour
2.6.20 to 2.6.24-rc8
Kernel relea#e# '.)." * '.&."
+a, "$ * -pril "$'
This is 2) hours a day, * days a week, for a
full year.
+e went this fast the year %efore this as well,
this is an ama,ing rate of change.
Interesting note, all of these changes are all
through the whole kernel.
(or e$ample, the core kernel is only -. of the
code, and -. of the change was to the core
kernel. /rivers are --., and --. was done
to them, it's completely proportional all
across the whole kernel.



..'( change# per hour
'.(." relea#e
2.6.20 to 2.6.24-rc8
This past 3. release was the fastest we have
ever created. That num%er shows &ust how
well the #inu$ kernel development model is
working. +e are growing in developers and
in how fast we are developing overall.
0ow this is &ust the patches we accepted, not
all of the patches that have %een su%mitted,
lots of patches are re&ected, as anyone who
has ever tried to su%mit a patch can attest
to.



Ho/ /e #ta, #ane
2.6.20 to 2.6.24-rc8
0ime ba#ed relea#e#
1ncremental change#



2e/ relea#e ever,
3 month#
Kernel relea#e# .%." * '.4."
) days to %e e$act, very regular e$perience.



1ow a kernel is developed.
#inus releases a sta%le kernel
2 2 week merge window from su%system
maintainers
2 rc" is released
2 %ugfi$es only now
2 2 weeks later, rc2
2 %ugfi$es and regressions
2 2 weeks later,rc3
And so on until all ma&or %ugfi$es and
regressions are resolved and then the cycle
starts over again.



3reg takes the sta%le releases from #inus,
and does sta%le releases with them,
applying only fi$es that are already in
#inus's tree.
4e'uiring fi$es to %e in #inus's tree first
ensures that there is no divergence in the
development model.
After #inus releases a new sta%le release,
the old sta%le series is dropped.
+ith the e$ception of 5longterm6 sta%le
releases, those are special, the stick around
for much longer...



4Longterm kernel#5
6ne picked per ,ear
+aintained for t/o ,ear#
'." and '.4
2.6.20 to 2.6.24-rc8
I pick one kernel release per year to maintain for
longer than one release cycle. This kernel I will
maintain for at least 2 years.
This means there are 2 longterm kernels being
maintained at the same time.
3.0 and 3.4 are the longterm kernel releases I am
maintaining.
Ben Hutchings is maintaining the 3.2 kernel as a
longterm kernel for the ebian pro!ect.
The "T#I pro!ect is based on the longterm kernels.



#ike mentioned %efore, we have almost 29!!
individual contri%utors. They all create a
patch, a single change to the #inu$ kernel.
This change could %e something small, like a
spelling correction, or something larger, like
a whole new driver.
7very patch that is created only does one
thing, and it can not %reak the %uild,
comple$ changes to the kernel get %roken
up into smaller pieces.



The developers send their patch to the
maintainer of the file8s9 that they have
modified.
+e have a%out *!! different
driver:file:su%system maintainers



commit ecf85e481a716cfe07406439fdc7ba9526bbfaeb
Author: Robert Jarzmik <robert!arzmik"freefr#
Author$ate: %ue A&r 21 20:33:10 2009 '0700
(ommit: )re* +roah',artma- <*re*kh".u.ede#
(ommit$ate: %hu A&r 23 14:15:31 2009 '0700
/01: ot*: 2i3 bu* o- remo4e &ath 5ithout tra-.cei4er

6- the ca.e 5here a *ad*et dri4er i. remo4ed 5hi7e -o
tra-.cei4er 5a. fou-d at &robe time8 a bu* i-
ot*9&ut9tra-.cei4er:; 5i77 tri**er

0i*-ed'off'b<: Robert Jarzmik <robert!arzmik"freefr#
Acked'b<: $a4id 1ro5-e77 <dbro5-e77"u.er..ourcefor*e-et#
0i*-ed'off'b<: )re* +roah',artma- <*re*kh".u.ede#
''' a=dri4er.=u.b=ot*=ot*c
>>> b=dri4er.=u.b=ot*=ot*c
"" '4387 >4388 "" ?@ABR%90CD1BE:ot*9*et9tra-.cei4er;F
4oid ot*9&ut9tra-.cei4er:.truct ot*9tra-.cei4er G3;
H
' &ut9de4ice:3'#de4;F
> if :3;
> &ut9de4ice:3'#de4;F
I
This is an e$ample of a patch.
It came from 4o%ert, was acked %y /avid, the
maintainer at the time of the us% on2the2go su%system,
and then signed off %y %y me %efore it was commited to
the kernel tree.
The change did one thing, it checked the value of the
pointer %efore it was dereferenced, fi$ing a %ug that
would have crashed the kernel if it had %een hit.
This is also a 5%lame6 trail, showing who changed each
line in the kernel, and who agreed with that change.
If a pro%lem is found, these are the developers that you
can ask a%out it.
;ecause of this, every line in the #inu$ kernel can %e
traced %ack to at least two developers who are
responsi%le for it.
This is %etter than any other %ody of code.



Developer7# 8ertificate of 6rigin
9a: 1 created thi# change; or
9b: <a#ed thi# on a previou# /ork /ith a
compatible licen#e; or
9c: =rovided to me b, 9a:! 9b:! or 9c: and not
modified
9d: 0hi# contribution i# public.
This is what 5<igned2off2%y=6 means.
All contri%utions to the #inu$ kernel have to
agree to this, and every single patch has at
least one signed2off2%y line, usually all have
at least two.
This is also a 5%lame6 trail, showing who
changed each line in the kernel, and who
agreed with that change.
If a pro%lem is found, this is the developers
that you can ask a%out it.
;ecause of this, every line in the #inu$
kernel can %e traced %ack to at least two
developers who are responsi%le for it.
This is %etter than any other %ody of code.



After reviewing the code, and adding their
own signed2off2%y to the patch, the
file:driver maintainer sends the patch to the
su%system maintainer responsi%le for that
portion of the kernel.
+e have around "-! su%system maintainers



#inu$2ne$t gets created every night from all
of the different su%system trees and %uild
tested on a wide range of different
platforms.
+e have a%out "-! different trees in the
linu$2ne$t release.
Andrew >orton picks up patches that cross
su%systems, or are missed %y others, and
releases his 2mm kernels every few weeks.
This includes the linu$2ne$t release at that
time.



7very 3 months, when the merge window
opens up, everything gets sent to #inus from
the su%system maintainers and Andrew
>orton.
The merge window is 2 weeks long, and
thousands of patches get merged in that
short time.
All of the patches merged to #inus should
have %een in the linu$2ne$t release, %ut that
isn't always the case for various reasons.
#inu$2ne$t can not &ust %e sent to #inus as
there are things in there that sometimes are
not good enough to %e merged &ust yet, it is
up to the individual su%system maintainer to
decide what to merge.



0op developer# b, >uantit,
H. Hartle, ?/eeten $%&.
-l @iro .%$
+ark <ro/n .)
-xel Lin )(.
Aohanne# <erg )('
Daniel @etter )4.
0aka#hi 1/ai )'%
Greg Kroah-Hartman )
?achin Kamat 4%'
0eBun Heo 4'$
Kernel relea#e# '.)." * '.&."
Kernel relea#e# '.)." * '.&."
+a, "$ * -pril "$'
>ark ? em%edded sound
A$el ? &anitorial
1artley ? comedi
Al ? vfs and filesystem
>auro ? v)l
4ussell ? A4>
@ohannes ? intel wireless
/avid ? networking
7ric 2 networking
3reg ? A<;, staging, tty, etc.



0op ?igned-off-b,C
Greg Kroah-Hartman .)"'
David ?. +iller 4$&.
+auro 8arvalho 8hehab .4(
Linu# 0orvald# '%$
+ark <ro/n 4
-ndre/ +orton $4(
Aohn Linville $(4$
H Hartle, ?/eeten $%&(
Daniel @etter $.'
-l @iro $")%
Kernel relea#e# '.)." * '.&."
3reg ? driver core, us%, staging
/avid ? networking
@ohn ? wireless networking
>auro 2 v)l
>ark ? em%edded sound
#inus 2 everything
Andrew ? everything
@ames ? <B<I
/avid 2 graphics
A$el 2 &anitorial



Dho i# funding thi# /orkE
$. 4-mateur#5 $'.4F
. Ged Hat &.&F
'. 1ntel (.(F
4. Hnkno/n 1ndividual# 4.&F
). Linaro 4.F
%. 0exa# 1n#trument# '.(F
.. ?u?I '.)F
(. 1<+ '."F
&. @i#ion Ingraving '."F
$". Google .)F
Kernel relea#e# '.)." * '.&."
<o you can view this as either 2!. is done %y
non2affiliated people, or !. is done %y
companies.
0ow to %e fair, if you show any skill in kernel
development you are instantly hired.
+hy this all matters= If your company relies
on #inu$, and it depends on the future of
#inu$ supporting your needs, then you
either trust these other companies are
developing #inu$ in ways that will %enefit
you, or you need to get involved to make
sure #inu$ works properly for your
workloads and needs.



Dho i# funding thi# /orkE
$$. ?am#ung .4F
$. Dolf#on +icro $.4F
$'. 2vidia $.'F
$4. 8on#ultant# $.'F
$). 6racle $.'F
$%. L12<10 $.F
$.. Jree#cale $.F
$(. Linux Joundation $.$F
$&. <roadcom $.$F
". 1ngic# 0echnolog, $."F
Kernel relea#e# '.)." * '.&."
<amsung "!)* patches
#( ? -!" patches
Cualcomm *!* patches



Getting involved
2.6.20 to 2.6.24-rc8
10,900 lines added
5,500 lines removed
2,200 lines modified
per day 2008 - 2009
Gun the kernel.org relea#e on ,our machine



Getting involved
2.6.20 to 2.6.24-rc8
10,900 lines added
5,500 lines removed
2,200 lines modified
per day 2008 - 2009
This book tells you how to build and install a kernel
on your machine.
$ree online



2.6.20 to 2.6.24-rc8
$ocume-tatio-=,BJ%B
$ocume-tatio-=de4e7o&me-t'&roce..
Getting involved
These documents in the kernel source
directory are the %est place to start if you
want to understand how the development
process works, and how to get involved.
The 1D+TD file has links to almost
everything else you ever wanted..



2.6.20 to 2.6.24-rc8
Getting involved
kernelne/bie#.org
http%&&www.kernelnewbies.org



2.6.20 to 2.6.24-rc8
Getting involved
Google 4/rite ,our fir#t kernel patch5
This is a video of a talk I gave at (D</7>,
going through the steps, showing e$actly
how to create, %uild, and send a kernel
patch.



2.6.20 to 2.6.24-rc8
Getting involved
kernelne/bie#.org/KernelAanitor#/0odo
<o you know how to create a patch, %ut
what should you doE The kernel &anitors has
a great list of tasks to start with in cleaning
up the kernel and making easy patches to %e
accepted.



2.6.20 to 2.6.24-rc8
Linux Driver =roBect
dri4er.=.ta*i-*=G=%B$B
Getting involved
The staging tree also needs a lot of help, here
are lists of things to do in the kernel for the
drivers to %e a%le to move out of the staging
area.
Flease always work off of the linu$2ne$t tree if
you want to do these tasks, as sometimes
they are already done %y others %y the time
you see them in #inus's tree.



github.com/gregkh/kernel-development
D%ligatory Fenguin Ficture