Re: Generic Kernel API

Marcin Jessa wrote:
> On Tue, 08 Nov 2005 17:42:07 -0700
> Scott Long <scottl_at_samsco.org> wrote:
> 
> 
>>Marcin Jessa wrote:
>>
>>>Hi guys.
>>>
>>>I just came across an article of Mr. Greg Kroah-Hartman in his blog
>>>http://www.kroah.com/log/2005/11/03/ 
>>>about generic kernel API which could make it possible for hardware
>>>vendors to supply us with their own drivers.
>>>To be honest I disagree with Greg and consider this a good idea.
>>>Especially if we had a system which could isolate each device driver
>>>running as a separate user-mode process so it would not bring down
>>>the entire OS in case the driver was buggy. 
>>>An API like that would both boost up FreeBSD's popularity and make
>>>it possible to use a way larger variety of hardware. 
>>>I mean, lets not fool ourselves, the majority of hardware vendors is
>>>not interested in revealing of their secrets publishing freely
>>>avaliable documentation of their products. 
>>>We could have a new choice to use (or not) binary drivers the 
>>>same way the popular commercial O.Ss do. 
>>>What do you guys think? What is the view of the
>>>FreeBSD community on this metter? 
>>>Could this be concerned as a good idea ?
>>>
>>>
>>>Cheers,
>>>Marcin Jessa.
>>
>>
>>Please don't take this the wrong way, but google for 'Universal Driver
>>Interface'.  Yes, this topic comes up every few years.  It sounds
>>like a good idea, but every OS has unique and incompatible ways of
>>doing things.  
> 
> 
> You've misunderstood me Scott. 
> I never meant it to be an universal API but a FreeBSD one only. 
> I understand an universal closs-platform driver API would me a nearly
> impossible project.
> My idea is to create an API for binary vendor drivers to make it
> easier for hardware vendors to create FreeBSD drivers the same way
> they can do for Windows or Mac OS X.
> 
> 

Yes, I did misunderstand, sorry.

So you're asking for a generic, stable kernel API for drivers?  In
some ways, this already exists.  We decided last year that we would
keep kernel APIs stable and essentially 'frozen' for -STABLE branches.
So the API that we have with 6.0 will remain unchanged for 6.1, 6.2,
etc.  There is room for exceptions here so long as they are well
documented, justified, and complete, but I expect this to be very, very
rare.

Where this breaks down is in moving from 6.x to 7.0.  We make no
guarantees there for binary or source compatiblity.  Apple is trying to
address with problem with KPI's.  There are obvious advantages to this,
but the cost is quite high.  It took them a number of years to go
through the system and essentially re-write most of it.  And it's still
really only a theory; porting from 10.3 to 10.4 is hard because you
have to adopt the KPIs in your code, and no one has seen 10.5 yet to
decide if the KPI is really the same there.

And, what do you do when you need to change an interface in order to
make it faster or more capable?  Do you shim it with a KPI and deal with
the mess of trying to hide the differences under the covers?  There are
a lot of places in the SCSI and network driver APIs right now where 
changes can and should be made in order to get keep them useful.
Loosing the flexibilty to do that between major releases will make the
OS stagnate.  I'm hoping that the guarantees that we have now are a good
compromise.  They stand in the middle between OSX at one end (strict
compatiblity through generic APIs) and Linux at the other end (no
guarantees on compatiblity at all between any releases).

Scott