From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 02:22:15 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 AA1FB16A41F for ; Thu, 10 Nov 2005 02:22:15 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F7AB43D46 for ; Thu, 10 Nov 2005 02:22:15 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 09 Nov 2005 18:22:15 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <4372AED7.9000403@elischer.org> Date: Wed, 09 Nov 2005 18:22:15 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <1566.1131574723@critter.freebsd.dk> <916E69BA-AE58-4BB4-AB8A-01BDFBA5FF49@mac.com> <43729ED9.9050204@samsco.org> In-Reply-To: <43729ED9.9050204@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Poul-Henning Kamp , 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 02:22:15 -0000 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org"