Generic Kernel API
Julian Elischer
julian at elischer.org
Wed Nov 9 18:22:15 PST 2005
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"
More information about the freebsd-current
mailing list