From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 00:39:13 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C496016A41F for ; Thu, 10 Nov 2005 00:39:13 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4687C43D55 for ; Thu, 10 Nov 2005 00:39:13 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 9A8615F7E; Wed, 9 Nov 2005 19:39:12 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24607-07; Wed, 9 Nov 2005 19:39:11 -0500 (EST) Received: from [199.103.21.238] (pan.codefab.com [199.103.21.238]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 5239B5D82; Wed, 9 Nov 2005 19:39:11 -0500 (EST) In-Reply-To: <1566.1131574723@critter.freebsd.dk> References: <1566.1131574723@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <916E69BA-AE58-4BB4-AB8A-01BDFBA5FF49@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 9 Nov 2005 19:39:10 -0500 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at codefab.com Cc: current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2005 00:39:14 -0000 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.