From OpenDriversWiki

Problem Statement

OSDL hosted two Open Driver Forums this past year. One at LWE Boston in February 2005 and the other at LWE San Francisco in August 2005. In both cases, a clear message from the kernel developers that attended the forum was that "Driver writers unfamiliar with Linux and Open Source Processes need to learn how to port their drivers to Linux so that they can be maintained in the mainline kernel." Individuals new to Open Source need to educate themselves on existing community standards and "best-practices" in order to interact effectively with community members. In many cases, device driver writers don't know where to start; information is widely scattered throughout the web and in many cases, some elements of know-how isn't even documented. In addition, technical gaps that have risen from the kernel community need to be addressed.

OSDL has agreed to undertake some of the activities that will help alleviate the concerns addressed by the forum attendees. However, OSDL resources (personnel and equipment) are stretched thin and it is difficult to make an meaningful impact within a year's time.

Breakdown of the Problem Statement

Education and Training

Prior to commencing with the Open Drivers Project, documentation and information about developing in the Linux Open Source community was widespread. Often, it was difficult for a driver developer new to Open Source to find, piece together, and and comprehend the process with which the kernel community followed. The Open Drivers Project has started to resolve this issue by providing a central information portal as a one-stop-shopping web site for those new to the Open Source community. The site intends to provide resources and information, both social and technical, that helps a new community member introduce open source device driver code and become a viable contributor to the kernel community. The new open source developer is not the only target audience either for the Open Drivers Project. The program managers/project managers, legal divisions, and senior management need similar sources of information, education and training. Published content needs to be created to support the types of information required by each of these audiences.

Developer information that needs to be developed and published includes:

• Kernel API documentation pertaining to device drivers such as storage, networking, printers, video, and audio subsystems.
• How to license code that is opened to the kernel community
• Providing templates and guidelines for writing device drivers
• Storing a library of tests to exercise newly written drivers
  
  

Information for program managers and product managers that needs to be published includes:

• What does a real life time line look like for open sourcing a driver, getting it merged into mainline, and then merged into distros.
• What to expect in terms of support and maintenance from the kernel community
• How to plan the life expectancy of the driver that is released as open source
• Alternatives for maintaining and supporting a driver that is not accepted into the mainline kernel
• Open Source driver development checklists
  
  

Types of information that need to be addressed for legal departments include the following:

• How to mitigate legal and patent issues in opening up a device driver
• What license should one use for their open source driver
• How to protect your intellectual property and still provide open drivers
  
  

Information provided to senior management should include the following:

• What are the risks vs. benefits to creating an open source version of a proprietary driver
• What are the legal issues one needs to worry about when creating an open source version of a proprietary driver (summarized for executive management)
• Business benefits
  
  

The list above is not complete; as OSDL moves forward with this project, there is no doubt that additional areas of information will be discovered to be lacking and new information will need to be created.

Requests From the Community

There have already been requests made from the open source community members to the Open Drivers project. One of the requests is a Driver Matrix. Kernel developers want to have a public repository of all the drivers available for Linux and all of the devices that those drivers support. The benefits allow users of Linux to use the matrix and make hardware purchase decisions based upon drivers that are known to work with various releases of the Linux kernel. The matrix also provides a list to developers of devices that are not working with certain releases of the kernel and that need attention by device driver writers. We've started to work on this for the community, but with limited resources it may be a slow work in progress.

Open Source Driver Testing

There has also been a need in the community to create a set of Open Source Driver Test Suites for each device type/class in the kernel. Whenever a new driver is written or an existing driver is patched, there currently doesn't exist any type of functional test suite to run against that new/modified driver to verify it hasn't broken anything. Again, limited resources makes it hard to make substantial headway on this. Also, limited machines and hardware are also an obstacle here.

Requested Resource Timeline

Q1 = Jan 2006 - March 2006
Q2 = April 2006 - June 2006
Q3 = July 2006 - September 2006
Q4 = October 2006 - December 2006

Here are the resources that we would like to acquire (in order) to help resolve some of the above listed issues:

1. Tech Writer (Q1 and Q2)

   Main Responsibilities will be to:

   • Document the Linux kernel APIs where they pertain to device drivers
   • Create training materials usable by OSDL member companies to help educate new driver writers
   • Generate other documents listed in part 1 of the Problem Statement

2. Device Driver Tester/Developer (Q1 - Q3)

   Main responsibility would be to:

   • Create a set of functional Device Driver Test Suites for each of the kernel device types/classes. The tests would be placed in a test library for anyone to download and run against their driver. It is hoped that if enough tests were seeded, a device driver test community will evolve and open contributions of new tests will increase.

3. Driver Matrix Developer (Q1 and Q2):

   Main responsibility would be to:

   • Create the Driver Matrix mentioned in the Requests from the Community section in the above Breakdown of the Problem Statement

4. Machines/Hardware/Equipment (Donated Q1):

   OSDL needs the various equipment in order to validate the device drivers on different system platforms and against different peripheral devices. OSDL is in need of:

   • Systems with different processor architectures, and different CPU and bus speeds.
   • Various hardware controller cards for network and storage initially. Eventually, OSDL would need controller cards for printers, audio, and video.
   • Various storage devices such as NAS and SAN, SCSI, etc.
   • A wide variety of network switches and varying speeds (100MB - 10GB)