Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Toshiharu Harada, Ph.D, profile picture
Uploaded byToshiharu Harada, Ph.D
PDF, PPTX4,246 views

Kernel Development: Drawing Lessons from "Mistakes" (Japan Linux Symposium 2009)

The presentation discusses common mistakes made in kernel development, specifically through the lens of the Tomoyo Linux project, to warn other developers. It highlights the importance of adhering to documentation on coding styles and the consequences of overlooking established protocols when submitting patches. The speaker emphasizes that success in the Linux community is achieved through engagement and active communication when sharing code.

Technology◦News & Politics◦
Download as PDF, PPTX
KERNEL DEVELOPMENT: DRAWING LESSONS FROM "MISTAKES" Japan Linux Symposium 2009 October 23, 2009 Toshiharu Harada haradats@nttdata.co.jp NTT DATA CORPORATION
ABSTRACTS Every kernel developer knows that Linux comes with plenty of precious documentation as an integral part. From coding style to how to post patches, almost everything has been documented. However, history shows that error is human nature. Sometimes developers do not well know Don’ts, but there are also cases when they make mistakes despite being aware of such rules. Why this happen is unsolved, but a documentation, so far missing, of the consequences of this misbehavior could discourage it. The presenter is project manager of TOMOYO Linux, a security enhancement feature merged in version 2.6.30. Thinking open-minded, he decided to share the errors his project made, wishing it could be a helpful warning to other projects, especially newcomers. In this presentation, it will try to explain the mistake circumstances in TOMOYO Linux project, highlighting the thoughts of project members and the community reactions.
“Experience is the name everyone gives to his mistakes” --- Oscar Wild
WHAT’S THIS ALL ABOUT
WHAT’S THIS ALL ABOUT • Linux comes with a set of great documentation
WHAT’S THIS ALL ABOUT • Linux comes with a set of great documentation • DOs and DON’Ts are there already
WHAT’S THIS ALL ABOUT • Linux comes with a set of great documentation • DOs and DON’Ts are there already • Yet we keep on making mistakes
WHAT’S THIS ALL ABOUT • Linux comes with a set of great documentation • DOs and DON’Ts are there already • Yet we keep on making mistakes • Finding a missing piece
WHAT IS MISSING?
WHAT IS MISSING? • In my humble opinion:
WHAT IS MISSING? • In my humble opinion: • Human nature (hard to fix)
WHAT IS MISSING? • In my humble opinion: • Human nature (hard to fix) • Most of us don’t really like readings (hard to fix)
WHAT IS MISSING? • In my humble opinion: • Human nature (hard to fix) • Most of us don’t really like readings (hard to fix) • Real-life examples taken from TOMOYO Linux project
WHO AM I?
WHO AM I? • Project manager of TOMOYO Linux
WHO AM I? • Project manager of TOMOYO Linux • What is “project manager”?
WHO AM I? • Project manager of TOMOYO Linux • What is “project manager”? • Something put in between an Open Source projects and a Company
WHO AM I? • Project manager of TOMOYO Linux • What is “project manager”? • Something put in between an Open Source projects and a Company • It’s an adventurous role (experimental stage)
OUCH, IS THIS “SECURE LINUX” TALK? • No. (so please remain seated, you are safe)
COVERED TOPICS • Chapter 1: Where to find DOs and DON’Ts • Chapter2: TOMOYO Linux posting history overview • Chapter 3: Step by step introduction of DOs and DON’Ts of the TOMOYO Linux
CHAPTER 1 Where to find DOs and DON’Ts
Gentle Reminder
Gentle Reminder Documentation is a part of Linux Kernel
Gentle Reminder Documentation is a part of Linux Kernel After checking out the kernel, cd to “Documentation”
Gentle Reminder Documentation is a part of Linux Kernel After checking out the kernel, cd to “Documentation” Problem is “there are just too many files and directories” and people prefer coding than reading
How Great is It?
How Great is It? $Documentation/ManagementStyle
How Great is It? $Documentation/ManagementStyle “Most people are idiots, and being a manager means you'll have to deal with it, and perhaps more importantly, that _they_ have to deal with _you_.”
How Great is It?
How Great is It? $Documentation/ManagementStyle
How Great is It? $Documentation/ManagementStyle “Thing will go wrong, and people want somebody to blame. Tag you’re it.”
Okay, I’ll do so
Okay, I’ll do so
Okay, I’ll do so Me Blame
The truth is people will blame you regardless of you are tagged or not (you can omit) Just these two statements illustrate the essential part of managements Linux documentation is so practical
Minimal Reading
Minimal Reading Entire Scheme
Minimal Reading Entire Scheme $Documentation/HOWTO
Minimal Reading Entire Scheme $Documentation/HOWTO Submitting Patches
Minimal Reading Entire Scheme $Documentation/HOWTO Submitting Patches $Documentation/SubmitChecklist
Minimal Reading Entire Scheme $Documentation/HOWTO Submitting Patches $Documentation/SubmitChecklist $Documentation/CodingStyle
References
References Note that the title is “How to Participate in the Linux Community”
References Note that the title is “How to Participate in the Linux Community” Making your code upstream means your participation in the Linux Community (Be nice!)
My favorite one http://www.linuxfoundation.jp/jp_uploads/ seminar20070710/Jon-Dev-Process.pdf
Picked up Two pages
I was laughing when I saw the slides for the first time (in 2007) When I came to realize that it was true, I couldn’t laugh any more ... They kept asking me “not yet?” ;-)
CHAPTER 2 TOMOYO Linux by Numbers
Leo Tolstoy said All Happy Families Resemble Each Other, Each Unhappy Family Is Unhappy in Its Own Way.
2,700,000 9,230 2,700,000
Number of employees 2,700,000 of NTT DATA 2,700,000 CORPORATION
2,700,000 3 2,700,000
2,700,000 Number of project 2,700,000 members
2,700,000 0.0325% 2,700,000
Possibilities to be 2,700,000 assigned to the 2,700,000 project
2,700,000 3 2,700,000
TOMOYO is the 3rd 2,700,000 (and the latest) LSM 2,700,000 module merged upstream
2,700,000 0 2,700,000
Number of people 2,700,000 who expected 2,700,000 TOMOYO would be merged
2,700,000 15 2,700,000
2,700,000 We posted patches 15 2,700,000 times
2,700,000 716 2,700,000
2,700,000 Merged since 716 days after the first 2,700,000 post
2,700,000 162 2,700,000
Number of comments 2,700,000 from LKML 2,700,000 (0.2 comments/day)
Proposal History http://tomoyo.sourceforge.jp/wiki-e/?JLS2009
CHAPTER 3 Drawing Lessons from the “Mistakes” of TOMOYO Linux Project
CHAPTER 3 Drawing Lessons from the “Mistakes” of TOMOYO Linux Project B lame Me
IN THE 1ST POSTING I wrote: snip All right, that's almost everything. Please visit the following URL for the code and documents:   http://tomoyo.sourceforge.jp/wiki-e/ If you want to see the code first, then:   http://tomoyo.sourceforge.jp/cgi-bin/lxr/ source/security/tomoyo/?v=linux-2.6.21.3- tomoyo-2.0
DON’T Send URL Send patches
DON’T Send URL Send patches
WHAT HAPPENED? •Igot a personal message from Stephen Smalley, a maintainer of that famous SELinux –“If you really want feedback or to get your code into the kernel, you need to do more than post a URL to the code - you need to break your code down into a number of patches and post them, just like the AppArmor folks have been doing. “
SO WE RUSHED TO POSTED PATCHES NEXT DAY • Pavel Machek gave a comment •“Looks whitespace-damaged to me.”
DON’T Ignore the Linux standard coding style Always apply checkpatch.pl
DON’T Ignore the Linux standard coding style Always apply checkpatch.pl
DO
DO • Carefully read the $Document/CodingStyle
DO • Carefully read the $Document/CodingStyle • Check your code with $scripts/checkpatch.pl
DO • Carefully read the $Document/CodingStyle • Check your code with $scripts/checkpatch.pl • Also use other $scripts/check*.pl
• Jiri Kosina pointed us to make patches bisectable • “Justa trivial minor nitpick - IMHO this breaks bisectability. It might be better to add the Kconfig/ Makefile patch at the end of the whole series, so that bisect doesn't end up in the tree in which Makefile references non-existing files/directories.”
DO • Add the Kconfig/Makefile patch at the end of the whole series, so that bisect doesn't end up in the tree in which Makefile references non-existing files/directories.”
DO • Add the Kconfig/Makefile patch at the end of the whole series, so that bisect doesn't end up in the tree in which Makefile references non-existing files/directories.”
IN THE 3RD PATCH • James Morris taught us series of patches should form a thread •“I'dalso suggest making all of the patches a reply to the first email, so they can be threaded.”
LIKE THIS
DO • Send series of patches as children of the first message so that they can form a thread or you want people to read your messages
DO • Send series of patches as children of the first message so that they can form a thread or you want people to read your messages
• James Morris said: • “Please use standard kernel list handling, per include/linux/list.h” • YOSHIFUJI Hideaki also mentioned: • You'reintroducing a custom API, which is open-coded repeatedly throughout your module. • All linked lists (at least, new ones) must use the standard kernel list API.
DON’T Propose new data structure Use existing one
DON’T Propose new data structure Use existing one
IN THE 5TH POSTING • James Morris suggested to CC netdev mailing list • “Youshould send anything which touches core networking to netdev, too, and get an ack from one of the core developers there.”
DO • Carefully choose CCs and get a review from them
DO • Carefully choose CCs and get a review from them
IN THE 6TH POSTING • Tetsuo posted 30 series of messages with the subject, “Subject: [TOMOYO #7 00/30] TOMOYO Linux 1.6.0 released” • The problem was “TOMOYO 1.6.0” did not use LSM and implemented different hooks
DON’T Try to invent a new API Respect a standard and follow one
DON’T Try to invent a new API Respect a standard and follow one