1. Working with the Linux Kernel
Community
Kristen Carlson Accardi
July 2007

2. picture of sand castle

3. Everything I Needed to Know to be
a Successful Linux Kernel
Developer
I Learned in Kindergarten

4. Cooperation

5. Open Source License !=
Open Source Development Model

6. Release Early, Release Often

7. Don't Succumb to NIH Syndrome
(Not Invented Here)

8. Following Directions

9. quot;HOWTO do Linux kernel developmentquot;
Documentation/HOWTO

10. Read Documentation/CodingStyle

11. Example of Bad Comments
int pcie_get_ctlr_slot_config(struct controller *ctrl,
int *num_ctlr_slots, /* number of slots in this HPC; only 1 in
PCIE */
int *first_device_num, /* PCI dev num of the first slot in this
PCIE */
int *physical_slot_num, /* phy slot num of the first slot in this
PCIE */
u8 *ctrlcap)
{

12. Break up large patches

13. Read
Documentation/SubmittingPatches

14. Test your email client

15. Ask for Help

16. Good Listening Skills

17. On Thu, 6 Jun 2002, Rusty Russell wrote:
> >
> > The method is: open /dev/futex
STOP!
What madness is this?
You have a damn mutex system call, don't introduce mode crap in /dev.
Do we create pipes by opening /dev/pipe? No. Do we have major and minor
numbers for sockets and populate /dev with them? No. And as a result,
there has _never_ been any sysadmin problems with either.
You already have to have a system call to bind the particular fd to the
futex _anyway_, so do the only sane thing, and allocate the fd _there_,
and get rid of that stupid and horrible /dev/futed which only buys you
pain, system administration, extra code, and a black star for being
stupid.
Linus

18. On Thu, 6 Jun 2002, Rusty Russell wrote:
> >
> > The method is: open /dev/futex
STOP!
What madness is this?
You have a damn mutex system call, don't introduce mode crap in /dev.
Do we create pipes by opening /dev/pipe? No. Do we have major and minor
numbers for sockets and populate /dev with them? No. And as a result,
there has _never_ been any sysadmin problems with either.
You already have to have a system call to bind the particular fd to the
futex _anyway_, so do the only sane thing, and allocate the fd _there_,
futex _anyway
and get rid of that stupid and horrible /dev/futed which only buys you
pain, system administration, extra code, and a black star for being
stupid.
Linus

19. Manners

20. quot;Sometimes the kernel community is not
the friendliest community and I don't like
that. It sometimes scares away people.quot;
­­Linus Torvalds, January 2007

21. Keep Comments Constructive

22. > + if (!(pro&0x40))
Again missing spaces. Please take another look at Documentation/CodingStyle
for the preferred linux style.
> + return;
> +
> + temp32 = csr_add;
> + phost­>host_sgpio.pcsr = (void *)temp32;
> + phost­>host_sgpio.pcb = phys_to_virt(cb_add);
Use of phys_to_virt is generally a bug. What are you trying to do here?
> +
> + if (phost­>host_sgpio.pcb­>nvcr.bit.init_cnt!=0x2 ||
> phost­>host_sgpio.pcb­>nvcr.bit.cbver!=0x0)
in addition to the whitespace damage this line is far too long,
please break it up.

23. Matthew Wilcox wrote:
> ­ The fakephp driver bombs out as soon as it tries to register the second
> function of any device. Arguably, fakephp is mis­designed as it should
> register one slot per device, rather than one slot per function.
> On the other hand, with virtualisation, presumably we're going to
> want to hot­remove individual functions in the future, so maybe I
> should permit that in the new design. Comments on that?
Use dummyphp. It creates one slot per slot :)
> Next steps:
> ­ Fix fakephp
Kill it. Use dummyphp.
Eike

24. Practice Self­Control

25. Two weeks ago, we had:
­ a bug report
­ a detailed description how to possibly fix this issue
What we did NOT have was:
­ any reaction by the patch author or any maintainer
(although with the exception of Linus, the recipients of the problem
description were exactly the same as the ones in this email)
A few days later, the patch that includes this bug was included in
Linus' tree.
Two weeks later, the bug is still present in both latest ­mm and Linus'
tree.
Linus, please do a
git­revert a5e1b94008f2a96abf4a0c0371a55a56b320c13e

26. > Linus, please do a
> git­revert a5e1b94008f2a96abf4a0c0371a55a56b320c13e
Fair enough. Reverted.
I think I'll stop accepting any ACPI patches at all that add new features,
as long as there doesn't seem to be anybody who reacts to bug­reports. We
don't need ACPI features.
We need somebody who answers when people like Andrew asks about patches to
support things like memory hotplug (which was also a problem over the last
weeks). Here's a quote from Andrew from a week or so ago: quot;repeat seven
times over three months with zero response.quot;.
It's not worth it to accept new stuff if we know it's not going to get any
attention ever afterwards.

27. On Monday 10 July 2006 08:38, Linus Torvalds wrote:
> On Sun, 9 Jul 2006, Brown, Len wrote:
> > So I ask you. If I fix the Kconfig issue today, will you accept
> > a push that restores this driver to 2.6.18?
>
> Sure.
Great! Sorry Linus from me too ­ I've been assigned to watch this for Redhat
and completely missed the feedback as well. We have an open bug that we're
hoping it will fix, and would like to see it in vanilla.
Regards,
Nigel
For the record ­ I apologize for the delay in fixing this build issue. Yes, this driver is most
certainly maintained (in fact I sent a different patch on Friday for the same driver). It's been a
busy 2 weeks. Thank you Len for sorting this out.
Kristen

28. Include Positive Comments

29. On Fri, Feb 09, 2007 at 01:55:18PM +1100, Michael Ellerman wrote:
> Currently pci_disable_device() disables MSI on a device by twiddling
> bits in config space via disable_msi_mode().
>
> On some platforms that may not be appropriate, so abstract the MSI
> suspend logic into pci_disable_device_msi().
Michael,
I appreciate the work you've put into improving MSI code.
But I don't understand the point of adding another extern function to
drivers/pci/pci.h.
Could you be more specific about the quot;may not be appropriatequot; comment?
(ie which platforms, what breaks)
Just explaining that bit is probably enough to justify my nit and will help
prevent other folks from breaking it again in the future. Maybe add this as
a comment to the new function.
thanks,
grant

30. “Manners” has a Cultural Context

31. Cleaning Up After Yourself

32. Learning to Play With Others, not
just Side by Side

33. Develop Trust by:
Reviewing other people's code and making
constructive comments on it (see Manners)

34. Develop Trust by:
Being a member, not just a supplier

35. Develop Trust by:
Seeking out Face to Face contact

36. Develop Trust by:
Being Willing to Admit Mistakes

37. Thanks!
Ken Brush
Kyle Accardi
Arjan van de Ven
Keith Packard