As I've documented here previously, the Linux kernel community has had a few issues with OSDL in the past, so they got together, and worked out how they felt they could help resolve the different issues, and also provide some way for the kernel developers to solve some general issues that they feel need to be addressed.

A whitepaper was created, shopped around to the board members of OSDL, and yesterday, we gave a presentation to the full board, about what we felt could be done to help.

As people have been asking us what happened, and what specifically we proposed, here's a short summary. It was created by 17 of the top Linux kernel developers, and has their implicit backing. If anyone wants more details, please just let me know:

Proposals for how OSDL can help serve the vendor community

  • Create a program that can be used to get hardware specifications that are only available under a NDA to individual developers. This will entail creating a legal entity under OSDL that can sign the NDA with the company, and provide the individual developer that needs the spec with it. Also, if the developer moves on to do something else, OSDL will still have access to the spec if another developer wants access to it.

  • Provide some way for developers to access hardware before it is publicly available. This will help the company by allowing kernel developers to help out with drivers and code before it is released to the general public, which will help them with their deadlines of releasing working drivers at the same time hardware is available. It is also very difficult for most companies to give hardware to individual people, but very easy for them to give hardware to other companies.

  • A lot of time, when a vendor tries to get code accepted into the Linux kernel, it is a very frustrating task for both sides. Large code changes are sometimes just dismissed as they do not take into consideration the way the kernel is developed (small changes over time), or they just do not follow the basic rules (coding style, submission process, etc.) We need an approach that will make it easier for everyone involved, and one proposal to do this is to have a training conference. Kernel developers and subsystem maintainers will be willing to provide training on what the proper procedures are, and case studies of what has failed in the past, and why. It will also allow vendor developers to meet directly with the kernel developers to help ease any tension that might occur over email, and will provide a neutral ground for everyone involved.

  • In the past vendors use "requirements" to control operating system development. This was how all of the UNIX variants were created, but this process no longer applies to Linux. Code and ideas that are implemented are how to control and modify Linux, not providing a specification and telling other people to go follow it. This too is a big educational issue, and can probably be addressed at the above mentioned conference.

Proposals for how OSDL can help nurture the Linux kernel community

  • We really need a technical writer dedicated to help keeping the in-kernel documentation up to date and relevant. The kernel developers are much better at writing code than documenting it, and if there was someone watching over this, and bugging the developers to keep it up to date when it lapses, it would help out immensely. The fact that the in-kernel documentation is not properly up to date, causes significant vendor pain when they try to go create a new driver or change, and are confronted with incorrect documentation.

  • The current OSDL fellowship program has been very successful, employing Linus and Andrew to do vendor-neutral tasks without worrying about any controlling company. We feel that this program should be expanded to cover aspects of the kernel that are in need of attention. Specific fellowships with limited time periods could be funded (even separately from OSDL) to help complete needed tasks. Example areas where help is needed is the PCMCIA and Firewire subsystems, which are known to have issues, but no one vendor is willing to step up and fund development for.

  • The development community usually does not have any access to travel funding in order to go to different conferences, or to go to meetings to interact with other developers. A program of creating travel grants to address this would help solve this problem.

  • Linux user groups represent a very good base of where future and current kernel developers can be found. We need to find a way to nurture these groups, provide a way to fly kernel developers to speak at these groups, and just be a general resource for them to use for the different issues they have.

  • There is no Linux technical conference in the US anymore. If this could be addressed with a conference much like ALS used to be, it would be a very good thing. We need to nurture the technical community across the US with regional conferences that are easy to access in order to help seed the creation of new developers for Linux. The different BSDs do this very well, and we need to also fill this gap. This isn't restricted to the US alone, South America, Africa, Asia and other parts of the world also need to have these types of meetings if we are to successfully thrive over time.

How to formalise the relationship between OSDL and the kernel community

  • A technical advisory board should be created at OSDL which consists of members of the kernel community. This board will act as an input mechanism from the community to OSDL internally. It will help oversee all of these different proposals and provide a line of communication from OSDL's sponsors back to the community.

  • A kernel community at large member should be created on the OSDL board of directors. This will allow the community to ensure that these proposals are properly implemented, and also prove a way for the community to have a stake in the way OSDL is run. It would be a visible sign of a trust bond between OSDL's sponsors, and the kernel community.

We realize that funding for OSDL is limited, but almost all of these proposals can be funded independently from OSDL's main budget. For example, the fellowship program can be sponsored by individual companies that want to see a specific task completed, and the conferences, if run properly, should be self-funding.

We found out yesterday evening that the OSDL board of directors had "agreed to implement all the proposals". So now comes the hard work...

And yes, Dan Frye, see, I spelled your name correctly :)

posted Thu, 26 Jan 2006 in [/linux]

Thanks for the many people responding to my previous plea for help about applying patches from mutt, with a script.

Turns out the solution to my problem (as pointed out by many people) was changing a line in my script from:

${VISUAL:-${EDITOR:-vi}} "$DIR/foo.patch"


${VISUAL:-${EDITOR:-vi}} "$DIR/foo.patch" < /dev/tty

This made vim much happier, and now my enter key works properly, and it even seems a whole lot faster. Lots of people responded that they didn't even know how vim would work without that change, as it was using the input from a pipe from mutt.

So now everything works just wonderfully, although this suggestion about how to do it all directly from mutt, without calling out to a shell script, looks like it will be fun to play with sometime in the near future.

posted Thu, 26 Jan 2006 in [/linux]


My Linux Stuff