From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 13:09:36 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CB2616A4CE for ; Thu, 11 Dec 2003 13:09:36 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 1527D43D31 for ; Thu, 11 Dec 2003 13:09:34 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 50725 invoked by uid 1000); 11 Dec 2003 21:09:31 -0000 Date: Thu, 11 Dec 2003 13:09:31 -0800 (PST) From: Nate Lawson To: arch@freebsd.org Message-ID: <20031211125356.V50668@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Common device driver classes? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2003 21:09:36 -0000 I'm in the middle of implementing various drivers and all of them have the same problem. I want to have a generic set of functionality that is provided in various hardware specific ways. The two drivers I'm working on are a cpu freq driver (hw-specific drivers: speedstep, longrun, acpi px, amd64) and a laptop buttons/control driver (hw-specific drivers: toshiba, asus, apm). Let's take clock frequency manipulation as an example. There might be a sysctl like "hw.cpu.0.freq" that can be set to change the clock frequency. The actual transition would be handled by a hardware-specific driver that would program the right registers for SpeedStep, for instance. The various drivers would also need to set priorities for how they attach. For instance, certain drivers may implement subsets of other drivers' functionality. If so, the attach routine would return -100 for the simple drivers and 0 for the full-featured ones. If one driver returns -100 and another returns 0, the sysctl function handler should point to the second driver and the first should not be called since it has been superseded. Since this sounds like newbus, here's an example how this might work: cpubusXXX cpu0 cpufreq (speedstep) - hw.cpu.0.freq cpu1 cpufreq (acpi performance states) - hw.cpu.1.freq Note that cpu0 might also support ACPI performance states but speedstep is a more accurate driver for the given hardware. The user could change the frequency for each CPU through a generic sysctl without knowing the underlying technology used to make the transition. Finally, the probe/attach routines of each driver should be called for each logical processor in the system and would then call cpuid or other things for that processor to determine what capabilities it has. Wouldn't we need a bus layer for CPU drivers to hang off of that was filled out by our CPU enumeration? -Nate