15 Mar
2007
15 Mar
'07
8:59 a.m.
Ross Vandegrift wrote:
On Wed, Mar 14, 2007 at 07:57:06PM +0100, Fons
Adriaensen wrote:
This isn't an issue if you release a driver as free software and preen
it for mainline inclusion.
Once a driver in using APIs in the mainline tree, it's easy to track
when API changes break it. When a developer changes an API that
breaks your driver, it is typically up to the developer to update your
code for the API, not you!
So very specifically, it's *not* a planning or budgetary problem, if
you (with your vendor hat on), follow the standard procedures that
operate within Linux kernel development.
There is one thing that I found particularly frustrating about the lack
of fixed API's: These fluctuations make it difficult to learn driver
programming due to the lack of up-to-date documentation. Or the
abundance of not-up-to-date documents. I don't know which one is the
most problematic.
There is the LDD book, which is very good btw, but it's outdated almost
as soon as it is published. Google then helps you find a lot of emails
in mailing lists but you still have to figure out whether they apply or
not. And the 'just ask, somebody will answer' has it's limitations too.
If I were a commercial HW developer needing to develop a driver for the
first time, this would certainly be an issue.
Greets,
Pieter
The
interface does not change that fast.
But the argument that 'kernel developers
need the freedom to change
the driver interface when they want to' has been used as one of the
reasons for not having a fixed BDI. Currently the interface _could_
change at any time and you can't plan for it.
Same for 'if your driver is open source then it will be maintained
by some volunteers.' Maybe it will, maybe not. It's understandable
that some people don't want to base a business on that.