[linux-audio-dev] Getting out of the software game

Pieter Palmers pieterp at joow.be
Thu Mar 15 11:56:26 UTC 2007


Ross Vandegrift wrote:
> On Wed, Mar 14, 2007 at 07:57:06PM +0100, Fons Adriaensen wrote:
>>> 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.
> 
> 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




More information about the Linux-audio-dev mailing list