Re: Generic Kernel API

• Previous message: FreeBSD Tinderbox: "[head tinderbox] failure on i386/i386"
• In reply to: Poul-Henning Kamp: "Re: Generic Kernel API"
• Next in thread: Kirk Strauser: "Re: Generic Kernel API"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Wed, 9 Nov 2005 19:39:10 -0500
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

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.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

• Previous message: FreeBSD Tinderbox: "[head tinderbox] failure on i386/i386"
• In reply to: Poul-Henning Kamp: "Re: Generic Kernel API"
• Next in thread: Kirk Strauser: "Re: Generic Kernel API"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]