Project Requests

From OpenDriversWiki

This page tracks project requests and proposals that have been submitted to the open drivers project.

Contents

[edit]

Non-Open Drivers List

It would be nice to have a listing of the top non-open-source drivers that people are having problems with, and what type of problems are being encountered.

Given such a list, it would be useful to then collect the following research, to understand the scope of the problem and to identify what actions could be taken to make improvements:

  • What are the complaints with the current driver?
    • Availability for certain distros?
    • Installation difficulties?
    • Stability problems?
    • Lack of feature support?
    • Other?
  • Are specs available in any form?
  • Is current driver code available under any non-open licenses?
  • Is any historical driver code available?
  • What is the history of vendor/community discussions?
    • What public statements has vendor issued about opening their driver? Or about supporting Linux in general?
    • Who in the community has been in contact with the vendor? What did they find out?
  • What is the status of any ongoing open driver development efforts?
    • What % of the device interface is discovered?
    • What % of discovered interface is implemented?
    • How widely tested has the implementation been?
    • What work remains before driver can be included in kernel?
    • What areas have developers requested assistance in?


[edit]

Driver-Related Conferences and Training

I'd like to have a two new navigation links, one for conferences and one for training. Conferences can include events like the recent Storage Summit in Vancouver, BC and the upcoming OS Driver Forum in San Francisco. Conference information should be a short description with a link to the event's webpage. Training can include events like the FreedomHEC Conference in Seattle, WA and the upcoming OS Driver Training for Managers and Program Managers in July. Training can also be a short description with a link or a longer description if it's an OSDL-sponsored event.

[edit]

Driver Matrix

"I would like to see a "Driver Matrix" with all of the drivers that are available for Linux, and all of the devices that those drivers support. I consider it a matrix because on one axis, you have the device type (or class) (networking, disk, printer, sound), and on the other you have the bus type (USB, ieee1394, PCI, etc). Within each cell are the list of drivers for that type of device on that bus; and for each driver, there is a list of device IDs and device descriptions that the driver supports. . ." - Pat Mochel os_drivers mailing list November 18, 2005

Archive of the discussion:
http://lists.osdl.org/pipermail/os_drivers/2005-November/000116.html


After some discussion with Pat on the mailing list we have a good idea for an overall design of the project. We will want a web-based interface that allows easy navigation of the Driver Matrix. We will start with an initial grid of device type vs bus type. Depending on which grid cell is selected, the list of drivers for that type of device on that bus will be displayed. Then, depending on which driver that is select from the list, the list of device ID's and descriptions is presented. We also want to choose a backend that will easily allow us to export the raw data to a spreadsheet of text file. Building this framework should be a trivial task. Populating the backend database and developing tools to parse the kernel source to help automate database population will be a more time consuming task. The next set of immediate tasks is to slap together a mock up interface and db.

[edit]

Distributed Driver Test Farm

Thank you to Bryce Harrington and Andrew Tridgell for the conceptual ideas and written summary below.

PROBLEM STATEMENT:

One of the major difficulties in testing drivers is that except for the most artificial of testing, you need the actual hardware on hand. Unfortunately, the expense of acquiring and administrating all that hardware is prohibitive. However, many people in the community have this hardware that they could lend for testing, so long as the hardware remains in their control.

BASIC CONCEPT:

Thus the idea is to set up a distributed test harness that allows community members to hook up their systems to the test harness from their own homes or workplaces. Then, developers and testers who wish to develop or run tests for the given driver can add their test to the harness and indicate the types of hardware to run it on.

This idea is not without precident; the Samba developers have been using a system like this for some years: http://build.samba.org

Bryce has also used this software for NFSv4 testing, and while he hasn't used its distributed testing ideas, the concept has proven effective at making it easy to add new systems. He has extended the software with the ability to patch, install, and boot Linux kernels, improved the documentation, and added some capabilities for doing client/server testing.

To read a full detailed description of the Distributed Driver Test Farm, challenges, solutions, theortical prototypes, and future work:
http://developer.osdl.org/dev/opendrivers/project_requests/distributed_driver_test_farm.php
Retrieved from "http://devresources.linux-foundation.org/dev/opendrivers/wiki/index.php/Project_Requests"
Personal tools