Re: Generic Kernel API

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)

>
> Scott
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe_at_freebsd.org"