Open Source Driver Summit Minutes

Following are minutes of the Open Source Driver Summit we held in Boston
on February 16.  My thanks to Craig Thomas for being scribe and writing
the minutes you see below.

I encourage any of you interested in continuing this discussion and
effort to sign up for the [email protected] mailing list.  It is an
open list and you or anyone interested can enroll using the following
link:

    http://lists.osdl.org/mailman/lisinfo/os_drivers

Minutes:

The Open Source driver summit was held during LWE on Wednesday,
February 16, 2005 at 4:00 pm.  An estimate of the number of attendees
was about 40.  In addition to the attendees in the room, an IRC chat
channel was created and several people participated through that
means.

The companies represented are as follows:

AMD            Dell            EMC            Emulex
HP             IBM             Intel          Motorola
Novell/SuSE    OSDL            Qlogic         Red Hat
Unisys


Intro (short slide presentation):

The open source community made it clear that for drivers, one still
needs to follow the open source methodolgy.

OSDL's role
 - bridge infrastructure
    + focusing on problems and inhibitors
        - through work groups
        - through forums

 - vehicles used by osdl
     + assign resources to support problems
         - dev
         - testdev

OSDL coordinates efforts to provide maps to "nirvana"
     - through SIGS and other vehicles

Agenda:
  1. create meaningful problem statements
      - inhibitors to driver currency
          lack of version control, too many drivers of the same kind
      - inhibitors to getting drivers into kernel.org
      - inhibitors to moving from closed to open drivers

  2. What can OSDL do to help
  3. Next steps

Ground rules:
  - identify yourself/company
  - move toward nirvana

==========================================================================

Summary of problem statements:

What you would like to see OSDL do to help?
-------------------------------------------

1. be able to provide advocacy for vendors, primarily from asia
   for understanding the open source process and getting them
   engaged in the process

   - need to create a how-to best know practices document for creating
     open source drivers
   - need to create training material and present this material as
     often as possible
   - maintain documents in a directory but publish the material as
     a pdf

2. not enough shared communal testing; would like to see others help
   sharing testing results and tests

   - OSDL could be a repository for test results for all to view.

3. sending hardware to developers does magic.

4. Hardware vendors have responsibilities to select parts and make sure
   parts suppliers provide gpl drivers.

5. Provide documented how-to to address the issues of service agreements
   made by vendors and how it relates to open source maintained code

    - don't expect kernel community to provide support for a vendor
      service level agreement.
    - don't expect to have subtree maintainer maintain your code, your
      patches and problems will be sent to the maintainer.  They need
      to make sure driver is kept up to date

==========================================================================


The following notes are an attempt to capture the discussion.

Question: how to increase the number of people to work on open source
          drivers or how to fix open source drivers
Answer:   Much of the focus should be on the latter, but don't exclude
          the former


Roger Hurwitz - Intel
  We heard from ISVs: there are time to market issues - how long does it
  take once the code is released to get into a mainline kernel?
  The customer needs the driver now, but the code is not yet mainlined
  or not yet rolled out into a distro.

Mark VanderWiele - IBM
  Is the issue because the submit is being done wrong or is there
  something else?

Steve Hemminger - OSDL
  network driver problems seen by him are due to a delay of putting out
  an early driver into kernel and telling kernel group to hold a place
  for it until it was fully ready - driver development needs to work in
  parallel and get things out early.

Roger Hurwitz:
  Again, problem is speed to customer

Rich Brunner - AMD
  There is a need to get some back door releases of drivers out to
  allow test and development of new hardware, but there needs to be
  a way to kill the early drivers, and allow the "official" driver
  to grow

Novell:
  The next group in the food chain also has the same issues.  They
  don't want to just take the driver and assume it works; they
  want to test the new driver and quality it as well.

Tim Burke - Red Hat:
   There are different times in the release process where changes to
   drivers are acceptable.  New releases can accept wholesale overhauls
   of drivers, whereas smaller releases of distros will only accept
   smaller changes in a driver.

Matt Dobbson - Dell:
   The reason for this is for stability.

Rich Brunner:
  You probably can't replace distro qualification, but maybe hardware
  vendors can do testing at OSDL in the lab to run against different
  platforms.

Steve Hemminger:
  It would be great if companies can give driver stress tests to OSDL
  and we can make them available openly for all to use

Rick Wheeler - EMC:
  We are trying to figure out how to share enterprise class equipment
  for testing and development.  Could OSDL be a repository for this?
  Also needs to point out that distros have diversions of the same
  basic driver.  Therefore, we should be testing upstream as much as
  possible.

SuSE:
  We are trying to consolidate (drivers) within our distros, to make
  sure that all HW vendors release official versions.

Duane Grigsby: qlogic
  there are reasons for multiple versions:
   1. how long it takes to get something into the kernel tree.
      one instance, it took many months
   2. timelines for qualification - synchronizing all qualifications
      is very hard to do, and is complicated when the API's in the
      kernel are constantly changing.

Any Wilison - Intel
  Picking up on suggestion to make big iron available: it was the
  mission of OSDL originally, but there are other things that need
  to be done to make this work in osdl.

Tim Witham - OSDL:
  There will always be multiple drivers for the same hardware; we
  just need to get to a point where people are comfortable with it.
  There needs to be an extra set of coordination on this.

Richard Brunner - AMD:
  How fast do the api's change?

Duane Grigsby - qlogic:
  Right now, a lot of changes over the past few months on sysfs.

Rick Wheeler - EMC:
  I didn't want to point fingers; I wanted to find out how to make
  the IHV's life easier.
  Testing a large number of luns needs to be better examined (large
  scale testing for enterprise).  No one has public access to large
  gear.

Tim Burke - Red Hat:
  I Feel that osdl could act more like a clearing house, coordinating
  test and publishing results, but the testing efforts should still
  be done by the distros and IHV's

Rick Wheeler - EMC:
  If the testing methodologies could be shared publicly, it could help
  all of them.

Mark VanderWiele - IBM:
  One thing that helps is to create a test harness, with certain  
standard
  API's and results are fed back to harness so when they are published,
  they all make sense.

Rich Brunner - AMD:
  OSDL can add some value by having some of those platforms.

Tim Witham - OSDL:
  It also helps to run on early kernels to see if anything breaks so
  they can be fixed before its too late.

Rick Wheeler - EMC:
  Not only kernel testing, need to test the whole stack.

Mark Miller - AMD
  One comment made last night at the ISV forum, is that an ISV can
  join a Red Hat partnership program or a SuSE partnership program;
  but there is no partnership program for the whole thing (driver
  integration).

SuSE:
  We are actively helping/training people on how to write drivers.

Bruce Vessey - Unisys:
  It's not patently obvious who the key community developers are to
  go to when you need help.

Steve Geary - HP:
  What's not clear to me is that there is a business aspect that
  asks where is the accountability for a released piece of code
  once it's put in the open source tree?  Who will help answer his
  customer's problem?  If his customer has a problem, where does he
  find the root cause and who can he ask to fix the problem?
  Example, a fix is in a kernel.org mainline kernel, but not yet in
  a distro release; how does a customer get his problem fixed if he
  has a service contract?

Steve Hemminger - OSDL:
  The responsibility of fixing a bug is up to the maintainer of the
  driver.

Jeremy Allison - HP:
  Sometimes bug fixes are not passed up stream -- samba is an example
  where there is not really a single place to send the problem to for
  a fix.

Steve Geary - HP:
  Perhaps we should find out who's problem are we trying to solve.
  from a business perspective there's more to driver writing than
  just submitting fixes to kernel.org.  Customers are down and they
  need a fix now!

Steve Hemminger - OSDL:
  There's a need for regular meetings to provide tutorials on how
  to get drivers in linux.

SuSE:
  Do people feel there is a lack of documentation of open source
  software?

  Answer: yes.  Nothing documented on how to get a driver accepted
          into the kernel.  Knowledge of coding style of kernel
          community is really needed to help make the drivers more
          acceptable.

Rich Brunner - AMD:
  Example: Taiwan has problems socailizing with the open community
  (kernel); there are cultural problems that make this diffictult.
  Many drivers are coming from Asia -- that's where the hardware
  is made more and more.

Jeremy Allison - HP
  Language issues are hard to solve and are a roadblock to get
  good code added into the kernel.

unknown:
  There needs to be greater advocacy or mentoring for people
  wanting to contribute in the open source commnity

unknown:
  Perhaps a large solution provider or hardware system vendor
  can work with hardware suppliers and convince them to create
  a GPL driver as part of the supply.  HP, IBM. Dell should
  push back on parts suppliers to demand GPL drivers.

unknown:
  Also Intel/AMD can use this method as a criteria for branding
  certain boards; they won't endorse or recommend certain boards
  unless GPL drivers are provided.

unknown:
  Take linux drivers - certify if it runs on the current
  kernel.org at the time the board is received by AMD/Intel

unknown:
  But it can't be released in the kernel due to the short time
  to market of hardware board.  Device writers won't be able to
  get the code in the kernel in time due to lag time of getting
  in kernel for board branding.

consensus:
  drivers need to be GPL'ed; some open source licenses are not
  sufficient.

Martine Silbermann - HP:
  The dcl work group is looking to provide more RAS features; event
  log is very hard to decipher due to inconsistencies of the drivers
  logging information; we need to have some kind of consistent content
  for a driver to report

Mark Langsdorf - AMD:
  All the subtrees need to unify their messages; perhaps someone can
  make this happen.

At the end of the session, problem statements were crafted with
sufficient detail that they could be acted upon.  They are
presented below:

1. be able to provide advocacy for vendors, primarily from asia
   for understanding the open source process and getting them
   engaged in the process

   - need to codify the existing best known practice (how-to)
     in a corporate friendly manner;  focus on process and culture
     of kernel community;  needs to be a corporate how-to
      + need to point out that you will be criticized for your
        submissions
      + make people avaiable to go out and present this material
      + a process manager's guide
      + coding styles
   - possibly be maintained as a working document in a directory, but
     published material as a pdf.

2. not enough shared communal testing; would like to see others help
   sharing testing results and tests

3. sending hardware to developers does magic.

4. hardware vendors have responsibilities to select parts and make sure
   parts suppliers provide GPL drivers.

5. service agreements:
    once driver is accepted upstream, a documented how-to should
    be made

    - don't expect kernel community to provide support for you service
      level agreement.
    - don't expect to have subtree maintainer maintain your code, your
      patches and problems will be sent to the maintainer.  They need
      to make sure driver is kept up to date

Steve Geary - HP:
  We didn't address issue on how to get things out quickly and not
  wait for kernel updates or for distro updates/patches, etc.

unknown:
  How can we use OSDL to write corporate how-to?

Tom Hanrahan - OSDL
  I own this problem to solve.


The closing segment asked the question: What are the next steps?
OSDL's suggestions were as follows:


 - OSDL would like to keep a mailing list active
   + mail list set up (os_drivers)

     http://lists.osdl.org/mailman/lisinfo/os_drivers

_______________________________________________
cgl_discussion mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/cgl_discussion