Re: Generic Kernel API

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'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:

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... ]

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]

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

-- 
-Chuck

[1]: One _single_ abstraction, that is, rather than having lots of  
variants of similar code scattered hither and yon.