[cgl_discussion] Open Source Driver Summit Minutes
Tom Hanrahan
hanrahat at osdl.org
Fri Feb 25 11:30:29 PST 2005
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 os_drivers at osdl.org 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
More information about the cgl_discussion
mailing list