Posts Tagged ‘development’
Earlier today, I finished reading the excellent article on How to participate in the Linux kernel community by Jon Corbet. I immediately forwarded it to a few people inside VMware who I know are going to appreciate the depth and breadth of information contained in this guide.
As I’ve mentioned before, we, as a company, are moving towards open source and development more and more each day. Our kernel modules are slowly but surely being released as open source software under the GPL v2. As Jon observes so astutely,
The kernel’s development process may come across as strange and intimidating to new developers, but there are good reasons and solid experience behind it. A developer who does not understand the kernel community’s ways (or, worse, who tries to flout or circumvent them) will have a frustrating experience in store. The development community, while being helpful to those who are trying to learn, has little time for those who will not listen or who do not care about the development process.
A big reason for such a reaction isn’t as much about wanting to openly flout the rules as much as not understanding why things are done in a certain way. Which brings me to the point of this post – the article left me wanting for more.
The article makes a strong case for upstreaming the Linux kernel modules. It says,
Code which has been merged into the mainline kernel is available to all Linux users. It will automatically be present on all distributions which enable it. There is no need for driver disks, downloads, or the hassles of supporting multiple versions of multiple distributions; it all just works, for the developer and for the user. Incorporation into the mainline solves a large number of distribution and support problems.
While this may be mostly true, it is not always the case. As someone that is living through this problem right now, there are a few other practical questions that come up, like:
- How do you develop new features against the upstream kernel, and still make them available on older kernels that are shipping with various distributions? These are the kernels your customers are using and without an excellent relationship with the distro vendors, what are your options? DKMS? The driver back-porting workgroup?
- What are your options if a distro vendor chooses not to enable your module/driver by default, for whatever reason? Are your customers going to be understanding if you explain to them this is not totally under your control?
I think a companion article, perhaps from a distro kernel maintainer, answering questions like the ones I mention above would go a long way towards providing a complete end-to-end story for organizations that want to do the right thing, but don’t know how.
I’ll end with a slight dig, aimed more at some of my friendly colleagues who think the Linux kernel development process is complex and convoluted – when was the last time you had this much insight into how the [windows|opensolaris|hp-ux|etc] kernel was developed and how *you* could influence its direction?