A month ago, Amanda McPherson and Greg Kroah-Hartman from the Linux Foundation asked me to coordinate an internship program aimed at getting more women to participate in the Linux kernel. In order to be considered for an internship, the applicants need to submit patches to the Linux kernel, and get them accepted.
The results have been amazing:
41 women applied for 6 Linux kernel internships.
In 13 days, 374 patches were submitted, and 137 patches were accepted.
Diff stat for accepted patches:
105 files changed, 3889 insertions(+), 4872 deletions(-)
Oh, I just came up with a really good metaphor for how to create a good looking patchset:
A patch should be one logical change. For example, you should put all whitespace changes in one patch. If you’re changing variable names to avoid CamelCase, you should do only one variable name change per patch. Basically, you’re breaking up patches into the smallest logical unit necessary, in order to make it easy to read and review. A patch that’s over a hundred lines is going to be pretty hard to review.
Think of it this way: you’re preparing a big meal for a friend, and you have many different dishes you want to serve them. You don’t throw all the food into one big pot and serve it to them. Instead, you serve each part of the meal on separate plates, so that they can admire your cooking, and you take the time to explain how you prepared each dish, and why it’s tasty.
A good patchset is like a well-prepared meal. You provide a menu (cover letter or patch zero) that explains what you’re going to serve (what the overall goal of the patchset is), and bite-sized portions (one logical change per patch) beautifully arranged (documented, signed, and up to coding style) in a particular order (numbered patches, with bug fixes and refactoring first).
It takes a while to learn how to cook a full course meal, and even longer to figure out how to present it with a flourish. People new to Linux kernel development should work on sending bite-sized, smaller patches, with one logical change per patch. Once you’ve got that down, you can work on presentation of multiple patches.
+Peter Senna Tschudinasked (about the Pycon incident): “What I can’t understand, and I would like help to understand, is how talking about big dongles to a friend in a conference can become a real problem to a women who is listening. Why did she felt uncomfortable about that? Did she felt threatened? How the dongle size talking could turn into something against her? Can the content of the two guys talking be considered a lack of respect? What are the limits to what can be considered offensive?”
I’m going to take you at face value, and assume you really do want to understand how making simple jokes can cause issues for women in tech. I’m making this a post, because I think lots of my male friends are worried about cracking jokes right now.
A while back I posted a Netconsole tutorial for how to capture Linux kernel debugging messages from a crashing machine. I’ve refined the instructions down to three scripts and three commands, which are after the break.
This documents my personal flow for downloading and installing a Linux kernel with my xHCI and USB 3.0 code. Until the code is in the upstream kernel and shipping in Linux distributions, you’ll have to follow these directions to get Linux USB 3.0 support.
The xHCI (USB 3.0) host controller driver and initial support for USB 3.0 devices is now publicly available on my kernel.org git tree. Greg Kroah-Hartman has queued the patches for 2.6.31, so Linux users should have official USB 3.0 support around September 2009. This is impeccable timing, since NEC recently announced they’ll be producing 1 million xHCI PCI express add-in cards in September.
This means that Linux will be the first operating system with official USB 3.0 support. I’m working with Keve Gabbert (the OSV person in my group at Intel) to make sure that Linux distributions like Ubuntu and Red Hat pick up the xHCI driver. Advanced users can always compile their own kernel on a standard distro install.
I hope that some USB 3.0 vendors who have prototypes will test with my driver. Instructions on how to compile a kernel using my git tree will follow.
This is a giant project that I’ve been working on for the past year and a half. It’s gratifying to see the code finally released, and exciting to know that hardware is on its way.
Netconsole is a powerful Linux kernel debugging tool. The dmesg output from a machine under test is transferred over an ethernet link (via UDP packets) to another machine. That means that you can see the debugging messages from the test machine on the screen of another machine. Netconsole isn’t good for debugging early kernel panics, but it is very useful if your new kernel driver hangs your system.
In the beginning, there was USB 1.1, with the “low speed” and “full speed” devices (at 1 Mbps and 12 Mbps, respectively). Then USB 2.0 came along with “high speed” devices that ran at 480 Mbps. Now the new USB 3.0 bus specification defines “SuperSpeed” devices that run at 5 Gbps (5,120 Mbps).
Now that the bus specification is public, I can finally talk about the code I’ve been developing at work. I’ve been writing a Linux driver for xHCI (the new USB 3.0 host controller), and changing the Linux kernel stack to support USB 3.0 devices. On November 17th, I got to demo my work at the world’s first USB 3.0 “SuperSpeed” Developers Conference.
For the past couple of months, I’ve been helping organize a student mini-conference for LPC, which will take place on September 16th. So far we only have 9 people registered for student day. We would like at least 15 students to make the student mini-conference a full-day event, and this week is the deadline for conference organizers to decide whether they need to scale back.
Over the past week, I’ve run into two different people who expressed the same thought, “Linux lacks support for a lot of devices.” I told them that this was a myth, and the Linux Driver Project has proven it is a myth.
Today I had an idea for a way to dispel this myth. I think someone should post a video of them walking into Circuit City, buying a random device, and walking out to their car. The video shows them configuring it on a Linux box and testing it. Then they would return the device and buy a new device. Buy, configure, return; repeat as necessary. The devices and configuration notes could be posted on the Linux Drivers Project wiki.
Now to find a decent videographer, buy a GSM data phone plan (for downloading packages and drivers in the car), and find some funding for devices that are non-returnable. In my copious spare time, of course.