Re: Generic Kernel API

Charles Swiger wrote:
> On Nov 9, 2005, at 5:18 PM, Poul-Henning Kamp wrote:
> 
>>> Apple has found that using inheritance is a big win for them: "In
>>> addition, code reusability decreases the memory footprint of drivers;
>>> drivers ported from Mac OS 9, for example, have been up to 75%
>>> smaller in Mac OS X."  Of course, it's easier to say such things then
>>> to write the code, but Apple has achieved pretty good results from
>>> the IOKit.
>>
>>
>> Apple also has significantly better control over the hardware
>> they have to write drivers for.
> 
> 
> Over their own hardware, agreed.  However, there are a number of  
> third-party hardware devices being used with Macs which Apple has no  
> control over, things like GPS receivers using USB-to-serial  converters, 
> etc.
> 
> Retaining backwards compatibility with older software, including  older 
> kernel modules (so long as they follow the rules), seems to be  a very 
> high priority for Apple, and they've done a fair-to-decent job  of it.
> 
> [ They've had some problems, too, such as VPN software breaking from  
> 10.3 -> 10.4. ]
> 
>> That said, there is a lot of stuff which could be improved in our
>> APIs.  And I wouldn't mind getting a "C with classes" language with  a 
>> couple
>> of domain-specific extensions in the bargain.
> 

I have a fair amount of very close experience with the OSX kernel.  See
my comment below:

> 
> I'm not strongly advocating the use of C++ in the kernel, but Apple  is 
> using g++ to build their kernels, so I'd imagine that FreeBSD  could 
> utilize the same embedded C++ dialect in our kernels if people  wanted 
> to do so.  The things that leapt out at me in comparing the  FreeBSD 
> APIs and IOKit were:

A cut down version of C++ is used for IOKit, it is not used for the 
whole kernel.  The large majority of the kernel is written in C, not
C++.  Not all kernel modules are hardware device drivers, neither in
OSX or in FreeBSD.  GEOM modules, filesystems, and netgraph modules are
all valid examples of pseudo drivers that benefit from a stable API but
do not represent hardware devices.  So IOKit is not the cure-all API.

> 
> 1) the notion of a system-wide driver registry, which could be  obtained 
> easily from the existing code in sys/bus.h & kern/subr_bus.c  which 
> keeps track of this:
> 
> typedef TAILQ_HEAD(driver_list, driverlink) driver_list_t;
> 
> [ devclass_get_devices() is close but not quite the same thing... ]
> 

There is already a module registry.  It's used to know when to reject
loading KLDs that contain modules that are already in the system.  This
works for both device drivers and pseudo drivers.

> 2) the "work loop" abstraction (long link, again):
> 
> http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ 
> IOKitFundamentals/HandlingEvents/chapter_8_section_2.html
> 
> Programming using callbacks or continuations, having to serialize  
> access to driver data structures, etc is one of the most difficult  
> areas to deal with, and race conditions and so forth are a common  
> source of evil, tricky, hard-to-reproduce bugs.  There isn't a free  
> lunch, the kernel has got to deal with such things, but having an  
> abstraction like this would probably help make the lives of people  
> writing drivers easier. [1]

I've written an IOKit driver for high performance hardware.  I'm not
convinced that the work loop paradigm is any more efficient than
locking.  Apple advocates it because it is indeed easier to program to
and takes less to explain than using the different locking primitives.
Remember that the target audience for much of the Apple documentation is
people who have never programmed in a Unix kernel before, be they coming
from Windows or coming from OS9.  In fact, the Apple docs go out of 
their way to discourage you from writing kernel modules entirely.

> 
> 3) the IOMemoryDescriptor and IOMemoryCursor classes, which provide  an 
> abstraction for managing virtual memory mappings and representing  DMA 
> or PIO activity (ie, building a scatter/gather list appropriate  for a 
> particular NIC or RAID controller's DMA engine):
> 
> http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ 
> IOKitFundamentals/DataMgmt/chapter_9_section_5.html
> 

There is already a well established and stable API for doing DMA in 
FreeBSD.  Just about every driver in the kernel uses it.  Why change?

There are good ideas in the IOKit that I've advocated for FreeBSD in the
past (interrupt filters, for example), and the object oriented approach
there is certainly interesting, but I don't see it as a cure all to 
stability or ease.

Scott