joining the herd of cats: how to work with the kernel ... · kernel developers have different...

Joining the herd of cats:how to work with the

kernel development process

Jonathan [email protected]

Slides: http://lwn.net/talks/elc2007/

I:Introduction

Why?

“There are a number of very good Linux kernel developers, but they tend to get outshouted by a large crowd of arrogant fools. Trying to communicate user requirements to these people is a waste of time. They are much too 'intelligent' to listen to lesser mortals.”

-- Jack O'Quin, Linux audio developer

Why?

There is great value to working with the communityInfluence development directionsOffload code maintenanceBetter support for customersMore efficient developmentBenefit from community expertiseTake ownership of your platform – and make it better

Free software is different

Proprietary softwareProprietary software

Product driven

Free software

Process driven



Product driven

Top-down requirements

Free software

Process driven

Bottom-up requirements



Product driven


Short time horizon

Free software

Process driven


Long-term view



Product driven


Short time horizon

Internal QA

Free software

Process driven


Long-term view

External QA



Product driven


Short time horizon

Internal QA

Hierarchical decisions

Free software

Process driven


Long-term view

External QA

Consensus decisions



Product driven


Short time horizon

Internal QA


Private

Free software

Process driven


Long-term view

External QA

Consensus decisions

Public



Product driven


Short time horizon

Internal QA


Private

Complete control

Free software

Process driven


Long-term view

External QA

Consensus decisions

Public

Little control

The kernel is even more different

It's big

Over 2,000 contributors 3/2006 to 4/2007

Only 10 contributed over 1% of changes

It's worldwide

Significant contributions fromNorth AmericaEuropeJapanSouth AmericaIndia...

It's of great commercial interest

At least 2/3 of kernel work is by paid developers

It's growing quickly

750,000 lines added 3/2006 to 3/2007

It's the wild west

It's the wild west

...but that is changing

II:Processissues

Do: understand the patch lifecycle

Much developer pain results from a failure to understand how code gets into the kernel.

Patch lifecycle: the beginning

Patch Lifecycle: the RFC

Patch lifecycle: first code

Patch lifecycle: repairs

Patch lifecycle: wider testing

Finally: into the mainline

Patch lifecycle: repeat

Lifecycle: the corporate view

Do: communicate early

Let the community know what you are doing

Avoid duplication

Avoid mistakes

Do: release early

Big vendor mistake:“We'll release the code after it passes internal QA”

By then it is too late

Do: expect to make changes

No initial code submission is perfect

Kernel developers have different goals

The kernel release cycle

Do: observe the merge window

“I'm really fed up with having to pull big changes after the merge window, because it just doesn't seem to let up. I'm going to go postal on the next maintainer who doesn't understand what 'merge window' and 'fixes only' means”

-- Linus Torvalds

II:Patch

submission

Do: Send in your changes

Avoid having to carry changes out-of-tree

Draw attention to problems

Influence the direction of the kernel

Don't: send multipurpose patches

Patches should:Be small (if possible)Do exactly one thing

If you have a big change:Split it into independent pieces

Do: send bisectable patches

“git bisect” is a great tool for finding regressionsBinary search on the patch stream

To support bisect:Your patch series must work after every patch

Do: take care in submitting patches

Use diff -uNo MIME attachmentsDescribe them properly

A one-line summary at topLonger description below (if needed)Justify the patch

Include a Signed-off-by: lineAvoid word-wrapping

Thunderbird is especially bad here

See:Documentation/SubmittingPatches

Find the correct mailing list

linux-kernel is not the right place for all patches

Example: networking patches go to netdev

See:MAINTAINERSvger.kernel.org/vger-lists.html

Aside: the new linuxkernel subscriber

1) I want to be part of this, I'll subscribe


1) I want to be part of this, I'll subscribe2) I have mail from Linus! Cool!



...I wish I understood it



...I wish I understood it3) Hmm...I have a lot of mail from Linus




...I thought he was a nicer guy than that.




...I thought he was a nicer guy than that.4) 350 new messages. Ouch!

...I was only gone for an hour...





...I was only gone for an hour...5) I'll post my great idea for using C++ in the kernel





...I was only gone for an hour...5) I'll post my great idea for using C++ in the kernel6) These people have no clue of how to program!





...I was only gone for an hour...5) I'll post my great idea for using C++ in the kernel6) These people have no clue of how to program!7) My full mailbox is making me miss those great

penny stock alerts.





...I was only gone for an hour...5) I'll post my great idea for using C++ in the kernel6) These people have no clue of how to program!7) My full mailbox is making me miss those great

penny stock alerts.8) Unsubscribe. I'll go run Windows now.

On mailing lists

Ask whether you really need to read linux-kernelMany of us do

Consider a subsystem list instead

If so, read it sparinglyLook for interesting topics and contributors

Do: listen to reviewers

Reviewing patches is hard, thankless work

When a reviewer makes a commentSay “thanks”Respond politelyFix the problem (or justify the current code)

Don't: attack reviewers

...even if they are rude

Don't: take criticism personally

Patch reviewers do not hate you

They do not hate your company

They do not hate your employees

Requests for major changes

Reviewers may ask for big changesPush functionality into higher layersReimplement major functionalityClean up a longstanding mess

Their goals are different than yoursLong-term maintainability is key

Try to accommodate these requestsThey usually make sense in the long term

Do: Let go

Others will patch your codeAn Acked-by: for good changes is polite

They may replace it outright!Consider it the sincerest form of flattery

Once you release code under a free license...you no longer have controlIt gets better without work from you!

III:Codingissues

Do: follow the coding style

Documentation/CodingStyle

Do: avoid unnecessary abstractions

Things to avoid:HAL layersUnused parameters “just in case”Single-line functions

API stability

There is no stable internal kernel APIGet used to it

Ways to copeGet your code into the mainlinehttp://lwn.net/Articles/2.6-kernel-api

Don't: add multiversion code

Support the current mainline kernel...and no others

Do: clean up your messes

Breaking an internal API is OK...if there is a good reason for it

But: you have the responsibility to fix in-tree code

Don't add regressions

...even to fix something else

Don't: change the userspace API

Breaking applications is bad news

The API includesSystem call behavior/proc filesSysfs filesNetlink

Don't: assume all the world is a PC

Linux runs on all kinds of systemshandhelds to supercomputers32/64 bitSingle processor through thousands of processorsA few dozen architectures

Your code should build and work everywhere

In particular:Get your locking right from the beginning

Do: avoid silly mistakes

Use the tools:gcc -Wlockdepfault injection frameworkslab poisoningsparse...

Red flags

#ifdeftypedefsioctl()Silenceinline functionsHeavy stack usageUnnecessary abstractions

HAL layersSingle-line functionsUnused parameters

IV:Finalnotes

Don't: submit tainted code

Read the Developer's Certification of OriginBe sure you mean it

Be very careful with reverse engineeringChinese wall approach should be used

Don't: ship binaryonly modules

Legality of these modules is dubious

The benefit is even more dubious

Respect your customers: give them the source

Do: use the resources available

There is information and help out therekernelnewbies.orgKernel mentorsDocumentation/HOWTOLWN

Do: join in and have fun

Questions....?

joining the herd of cats: how to work with the kernel ... · kernel developers have different...

Documents