Re: Generic Kernel API

Julian Elischer wrote:
> Scott Long wrote:
> 
>> 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.
> 
> 
> but if we could implement it we could run apple drivers....
> (when they move to x86)
> 

No, we can't, unless we emulate the rest of the kernel API in OSX.
IOKit doesn't describe the entire kernel API.  Think of it as 'newbus
done right' and nothing more.  The rest of the kernel interfaces are
up for grabs.  Some look and act like their BSD counterparts, some do
not.

Scott