A Guide to the Linux Kernel Development Process. Jonathan Corbet LWN.net

Transcription

1 A Guide to the Linux Kernel Development Process Jonathan Corbet LWN.net 1

2 Agenda Why participation matters Guiding principles Trees Some tips 2

3 For more information ldn.linuxfoundation.org/book/ how-participate-linux-community -- or -- Documentation/development-process/ 3

4 Why? 4

5 Why? The kernel is the core of a Linux system 5

6 Why? It's how you get the kernel to meet your needs Well, this is open source... you don't get to request new features, you get to implement them -- James Bottomley 6

7 Why? External code is expensive 7

8 Why? External code is lower quality code 8

9 Why? In-tree code can be improved by others 9

10 Why? That is how our community works 10

11 Why this talk? Working with the kernel is not hard...if you understand how the process works 11

12 So, I've had enough. I'm out of here forever. I want to leave before I get so disgruntled that I end up using Windows. I may play occasionally with userspace code but for me the kernel is a black hole that I don't want to enter the event horizon of again -- Con Kolivas 12

13 Some guiding principles...which should help in understanding how the kernel is made 13

14 Upstream first Code goes into the kernel first...before going to customers...before user space depends on it 14

15 Not a differentiator Vendors should not differentiate their offerings at the kernel level 15

16 Not a differentiator Vendors should not differentiate their offerings at the kernel level (See Upstream first ) 16

17 Technical quality over all Code quality outweighs: Company plans User desires Existing practice Developer status 17

18 Long-term view Kernel developers expect to be maintaining the code 5-10 years from now 18

19 Peer review No code is perfect it can always be improved heed requests for changes 19

20 Developers are individuals...separate from their employers 20

21 No ownership of code Even code you wrote 21

22 No regressions...even to fix other problems So we don't fix bugs by introducing new problems. That way lies madness, and nobody ever knows if you actually make any real progress at all. Is it two steps forwards, one step back, or one step forward and two steps back? -- Linus Torvalds 22

23 No inherent right to inclusion Changes require justification Other solutions may win out 23

24 Trees 24

25 Mainline kernel Linus Torvalds's kernel 2-3 month release cycle 25

26 The release cycle 26

27 The release cycle 27

28 -stable Important updates to the mainline Security fixes Severe bugs Maintained for ~6 months 28

29 Distributor kernels Based on -stable May include significant changes enterprise kernels especially Maintenance period varies 29

30 Development trees linux-next Staging area for the next mainline cycle Patch integration Early testing -mm Now based on linux-next Collection point for miscellaneous patches More early testing 30

31 Subsystem trees Development for a single subsystem Feed into the mainline...or another subsystem tree 31

32 Subsystem maintainers...are the true gatekeepers But their power is not absolute 32

33 33

34 34

35 The moral of the story Developers should target subsystem trees 35

36 Tips 36

37 Getting started: companies Develop skills in-house 37

38 Getting started: companies Get legal on board 38

39 Getting started: companies Ensure management understands the process 39

40 Getting started: companies Let your developers contribute 40

41 Getting started: developers The #1 project for all kernel beginners should surely be "make sure that the kernel runs perfectly at all times on all machines which you can lay your hands on". -- Andrew Morton 41

42 Getting started: developers Review code! 42

43 Communication (1) Communicate your plans early 43

44 Communication (2) Specify requirements carefully Why instead of what 44

45 Communication (3) Listen 45

46 Aim for the mainline...early! Do NOT fall into the trap of adding more and more stuff to an out-of-tree project. It just makes it harder and harder to get it merged. There are many examples of this -- Andrew Morton 46

47 Posting code Read the process document Justify the change What problem is fixed? What feature is added (and why)? Effects on performance? 47

48 Where to post? Find the subsystem mailing list Find the maintainer Consider linux-kernel 48

49 Expect to make changes No code submission is perfect 49

50 Dealing with reviewers Do not ignore reviews Be nice to reviewers Understand their motivation Do not take it personally 50

51 Signed-off-by: Code submissions require a signoff...a statement that it can be contributed under the GPL 51

52 About linux-kernel Volume is high Discussion is... uninhibited It's where the community gathers Avoiding l-k may be appealing...but it has its hazards 52

53 Follow through Dump and run submissions are not appreciated 53

54 Be part of the process The kernel needs you 54

55 Questions? Development process document 55