From owner-freebsd-arch@FreeBSD.ORG Wed Dec 10 10:01:51 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 5D30F16A4CE for ; Wed, 10 Dec 2003 10:01:51 -0800 (PST) Received: from castor.allinfo.com (dsl081-145-015.chi1.dsl.speakeasy.net [64.81.145.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 141D243D29 for ; Wed, 10 Dec 2003 10:01:50 -0800 (PST) (envelope-from ian@all.info) Received: from atlas (atlas.local [192.168.2.75]) by castor.allinfo.com (Postfix) with ESMTP id 513B92A68 for ; Wed, 10 Dec 2003 11:47:59 -0600 (CST) Message-ID: <1130759.1071078880935.JavaMail.jwu@atlas> Date: Wed, 10 Dec 2003 11:54:40 -0600 (CST) From: Ian Lenzen To: freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: UNIX listing 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: Wed, 10 Dec 2003 18:01:51 -0000 We are editing the UNIX section of all.info and would like to include your web site: http://www.ar.freebsd.org/ The all.info search directory addresses the issue of site credibility. Web site producers are an integral part of all.info. As a site contact, your input is essential in helping our users better find and evaluate your website. To update or simply to verify your site's listing, please click this link to access your record: http://all.info/s?a=l&z=1vj6cvggr0sn19zm771wm0&x=freebsd-arch%40freebsd.org More information about all.info and examples of how producer data is displayed on our site is available at: http://www.all.info Thanks in advance. Ian Lenzen Editor, all.info Note: You may use the link below to indicate that you are NOT the proper site contact or to provide a corrected site contact: http://all.info/s?a=nl&z=1vj6cvggr0sn19zm771wm0&x=freebsd-arch%40freebsd.org If you have questions, please email: priority@all.info 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 From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 13:44:10 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 B467916A4CE for ; Thu, 11 Dec 2003 13:44:10 -0800 (PST) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56C4443D29 for ; Thu, 11 Dec 2003 13:44:09 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 28088 invoked from network); 11 Dec 2003 21:44:08 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Dec 2003 21:44:08 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id hBBLi51S012577; Thu, 11 Dec 2003 16:44:05 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031211125356.V50668@root.org> Date: Thu, 11 Dec 2003 16:44:07 -0500 (EST) From: John Baldwin To: Nate Lawson X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org Subject: RE: 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:44:10 -0000 On 11-Dec-2003 Nate Lawson wrote: > 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? Yes, you will need some sort of bus layer. It shouldn't be impossible to do. You could have a cpubus that hangs off of root0 (stick it in kern/subr_smp.c maybe) and then each MD arch could provide a CPU driver in mp_machdep.c that has an identify routine that adds cpu objects for each CPU in system to cpubus. Either that or you could drop cpubus altogether, and just have cpuX hang directly off of root0, or off of something like nexus0 if that's what you want to do. I can do a sample implementation for i386 that creates cpu drivers and hangs them off of nexus0 for i386 if you would like. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 14:39:28 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 08B6416A4D5; Thu, 11 Dec 2003 14:39:28 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBA2C43E56; Thu, 11 Dec 2003 14:22:08 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost.nic.fr [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id hBBMM7Da063602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Thu, 11 Dec 2003 17:22:08 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id hBBMM7rf063601; Thu, 11 Dec 2003 17:22:07 -0500 (EST) (envelope-from wollman) Date: Thu, 11 Dec 2003 17:22:07 -0500 (EST) From: Garrett Wollman Message-Id: <200312112222.hBBMM7rf063601@khavrinen.lcs.mit.edu> To: jhb@freebsd.org X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: References: <20031211125356.V50668@root.org> Organization: MIT Laboratory for Computer Science X-Spam-Score: -9.9 () IN_REP_TO,REFERENCES X-Scanned-By: MIMEDefang 2.37 cc: arch@freebsd.org Subject: Re: 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 22:39:28 -0000 In article you write: >altogether, and just have cpuX hang directly off of root0, or off of >something like nexus0 if that's what you want to do. `nexus' nodes are intended to be the places that CPUs are attached to the rest of the system. (I think it's a bug that ACPI calls itself a bus; functionally, it should be a nexus.) -GAWollman -- Garrett A. Wollman | As the Constitution endures, persons in every wollman@lcs.mit.edu | generation can invoke its principles in their own Opinions not those of| search for greater freedom. MIT, LCS, CRS, or NSA| - A. Kennedy, Lawrence v. Texas, 539 U.S. ___ (2003) From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 15:15:47 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 23B6816A4CE for ; Thu, 11 Dec 2003 15:15:47 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 5314343D2D for ; Thu, 11 Dec 2003 15:15:43 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 51107 invoked by uid 1000); 11 Dec 2003 23:15:44 -0000 Date: Thu, 11 Dec 2003 15:15:44 -0800 (PST) From: Nate Lawson To: John Baldwin In-Reply-To: Message-ID: <20031211145311.Q51054@root.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: RE: 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 23:15:47 -0000 On Thu, 11 Dec 2003, John Baldwin wrote: > On 11-Dec-2003 Nate Lawson wrote: > > 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. > > Yes, you will need some sort of bus layer. It shouldn't be impossible > to do. You could have a cpubus that hangs off of root0 (stick it in > kern/subr_smp.c maybe) and then each MD arch could provide a CPU driver > in mp_machdep.c that has an identify routine that adds cpu objects for > each CPU in system to cpubus. Either that or you could drop cpubus > altogether, and just have cpuX hang directly off of root0, or off of > something like nexus0 if that's what you want to do. I can do a sample > implementation for i386 that creates cpu drivers and hangs them off of > nexus0 for i386 if you would like. Thanks, that would be nice if you can do that in p4. I agree there's no need to have a cpubus. It would be good to be able to get a pointer to the pcpu data via an ivar in cpu0. Also, it would be good for acpi_cpu0 to set the acpi_handle ivar for its associated cpu0 object. That would make it possible for the cpufreq driver in its probe routine to pull out the acpi_handle for the associated \_PR.CPU0 object and check it for _PSS methods, for instance. Hmm, this part needs some more thought. This leaves my second question, which is how to make multiple hw-dependent drivers that implement the same interface (sysctls) such that if one probes ok, others of the same "type" don't attach. For instance, there are multiple ways to control the Centrino -- both SpeedStep and ACPI performance states. However, if the speedstep driver has attached, it should supersede the ACPI driver since it offers more hw-aware control. So each CPU should have exactly one cpufreq driver attached and the one that provides the best control. Warner suggested making a bus driver for cpufreq that attaches to the "winner" of the probe and provides the generic interface like this: cpu0 speedset-cpufreq0 cpufreq0 cpu1 acpi-cpufreq0 cpufreq1 Is that how miibus works? Is that an appropriate approach here? One issue is that other systems in the kernel will need a generic way to control the cpu. For instance, passive cooling by acpi_thermal needs to be able to use the cpufreq0 interface (through devclass_get_device) to find what clock rates are available and adjust the clock rate without caring about the underlying hardware. Advice on the above approach is welcome. -Nate From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 15:24:13 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 9447816A4CE; Thu, 11 Dec 2003 15:24:13 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E003C43D37; Thu, 11 Dec 2003 15:24:10 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id hBBNO85h010510; Thu, 11 Dec 2003 16:24:08 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 11 Dec 2003 16:21:19 -0700 (MST) Message-Id: <20031211.162119.128604849.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20031211145311.Q51054@root.org> References: <20031211145311.Q51054@root.org> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: 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 23:24:13 -0000 In message: <20031211145311.Q51054@root.org> Nate Lawson writes: : This leaves my second question, which is how to make multiple hw-dependent : drivers that implement the same interface (sysctls) such that if one : probes ok, others of the same "type" don't attach. For instance, there : are multiple ways to control the Centrino -- both SpeedStep and ACPI : performance states. However, if the speedstep driver has attached, it : should supersede the ACPI driver since it offers more hw-aware control. acpi driver's probe returns -100, speedstep returns -10. attach routine does the dynamic sysctl creation, detach does the destroy. Only one of the attach routines will get called. This is exactly the same as the pci and the acpi pci goo. : So each CPU should have exactly one cpufreq driver attached and the one : that provides the best control. Warner suggested making a bus driver for : cpufreq that attaches to the "winner" of the probe and provides the : generic interface like this: cpu freq bus not needed, since all the frequency things would attach to a cpu. : Is that how miibus works? Is that an appropriate approach here? Yes and I don't think so. miibus has lots of upstream attachments, which isn't the case here. : One : issue is that other systems in the kernel will need a generic way to : control the cpu. For instance, passive cooling by acpi_thermal needs to : be able to use the cpufreq0 interface (through devclass_get_device) to : find what clock rates are available and adjust the clock rate without : caring about the underlying hardware. Advice on the above approach is : welcome. Sounds like a .m interface to me, but your milage may vary. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 16:29:17 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 9380616A4CE for ; Thu, 11 Dec 2003 16:29:17 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26D1143D33 for ; Thu, 11 Dec 2003 16:29:16 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 482F965319; Fri, 12 Dec 2003 00:29:14 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 86516-04; Fri, 12 Dec 2003 00:29:13 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id E79F16530E; Fri, 12 Dec 2003 00:29:09 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 799DA2F; Fri, 12 Dec 2003 00:29:05 +0000 (GMT) Date: Fri, 12 Dec 2003 00:29:02 +0000 From: Bruce M Simpson To: "M. Warner Losh" Message-ID: <20031212002902.GB83410@saboteur.dek.spc.org> References: <20031211145311.Q51054@root.org> <20031211.162119.128604849.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031211.162119.128604849.imp@bsdimp.com> cc: arch@freebsd.org cc: nate@root.org Subject: Re: 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: Fri, 12 Dec 2003 00:29:17 -0000 I'm tracking the outcome of this discussion so I know where to put things like cache geometry discovery. My original plan was to assume uniform cache and TLB geometry across all CPUs in the system. This may not be the case. In which case implementing it via ivars may be more appropriate if Nate chooses to go down this road -- but this leaves the problem of how to export these properties easily to the userland. This is to facilitate getting at these properties a bit easier and machine-independent (I note that the current NDIS and PowerPC efforts could probably use this stuff). BMS From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 17:04:30 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 E03F516A4CE for ; Thu, 11 Dec 2003 17:04:30 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 0DFFA43D35 for ; Thu, 11 Dec 2003 17:04:30 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 51401 invoked by uid 1000); 12 Dec 2003 01:04:31 -0000 Date: Thu, 11 Dec 2003 17:04:31 -0800 (PST) From: Nate Lawson To: Bruce M Simpson In-Reply-To: <20031212002902.GB83410@saboteur.dek.spc.org> Message-ID: <20031211170335.X51376@root.org> References: <20031211145311.Q51054@root.org> <20031212002902.GB83410@saboteur.dek.spc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: "M. Warner Losh" Subject: Re: 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: Fri, 12 Dec 2003 01:04:31 -0000 On Fri, 12 Dec 2003, Bruce M Simpson wrote: > I'm tracking the outcome of this discussion so I know where to put things > like cache geometry discovery. My original plan was to assume uniform > cache and TLB geometry across all CPUs in the system. This may not be > the case. In which case implementing it via ivars may be more appropriate > if Nate chooses to go down this road -- but this leaves the problem of > how to export these properties easily to the userland. > > This is to facilitate getting at these properties a bit easier and > machine-independent (I note that the current NDIS and PowerPC efforts > could probably use this stuff). Those would definitely be properties of the CPU and could be exported via sysctl. My need is a little different in that I need to attach a child driver to a cpu. -Nate From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 17:32:27 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 1737216A4CE for ; Thu, 11 Dec 2003 17:32:27 -0800 (PST) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32AD943D09 for ; Thu, 11 Dec 2003 17:32:26 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc11) with ESMTP id <2003121201322501300c2ujoe>; Fri, 12 Dec 2003 01:32:25 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA91208; Thu, 11 Dec 2003 17:32:23 -0800 (PST) Date: Thu, 11 Dec 2003 17:32:21 -0800 (PST) From: Julian Elischer To: Nate Lawson In-Reply-To: <20031211170335.X51376@root.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Bruce M Simpson cc: "M. Warner Losh" cc: arch@freebsd.org Subject: Re: 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: Fri, 12 Dec 2003 01:32:27 -0000 On Thu, 11 Dec 2003, Nate Lawson wrote: > > Those would definitely be properties of the CPU and could be exported via > sysctl. My need is a little different in that I need to attach a child > driver to a cpu. If I understand what was said.. then I agree that a buss for each CPU's private "drivers", (one bus per cpu) off the root nexus would make sense. One would assume also that PCPU(mybus) would point to the bus, and that each bus would be able to identify it's CPU. The question is how one schedules that control goes to the correct cpu whe you try run that driver as it is likely if it is reading PCPU registers etc. that it can only successfully run on that CPU. From owner-freebsd-arch@FreeBSD.ORG Fri Dec 12 10:53:00 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 E16BC16A4CF; Fri, 12 Dec 2003 10:53:00 -0800 (PST) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4868543D31; Fri, 12 Dec 2003 10:52:58 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd01.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1AUsPJ-00089W-03; Fri, 12 Dec 2003 19:52:57 +0100 Received: from Andro-Beta.Leidinger.net (rfv9UkZUreQDcT3uchpQ7rcvUZ1oSu02TMQideRshF5bC80NyaTMwL@[217.229.217.137]) by fmrl01.sul.t-online.com with esmtp id 1AUsP0-037aQi0; Fri, 12 Dec 2003 19:52:38 +0100 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) hBCIqmYh052495; Fri, 12 Dec 2003 19:52:49 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (netchild@localhost [127.0.0.1]) hBCIqlx7093521; Fri, 12 Dec 2003 19:52:47 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Fri, 12 Dec 2003 19:52:47 +0100 From: Alexander Leidinger To: arch@freebsd.org Message-Id: <20031212195247.4ff07669.Alexander@Leidinger.net> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: rfv9UkZUreQDcT3uchpQ7rcvUZ1oSu02TMQideRshF5bC80NyaTMwL@t-dialin.net cc: bhughes@trolltech.com cc: freebsd-standards@FreeBSD.org Subject: Patch to support the C++ DSO Object Destruction API (PR 59552) 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: Fri, 12 Dec 2003 18:53:01 -0000 Hi, can someone please look at PR 59552 (author CCed)? I quote the description of the PR here: ---snip--- Below is a test-case and patch to support the cross-vendor C++ DSO Object Destruction API used by GCC 3.x and the Intel C/C++ compilers, defined at http://www.codesourcery.com/cxx-abi/abi.html#dso-dtor Here is a quote from the web-page, describing the motivation/rationale behind this API: The C++ Standard requires that destructors be called for global objects when a program exits in the opposite order of construction. Most implementations have handled this by calling the C library atexit(3) routine to register the destructors. This is problematic because the 1999 C Standard only requires that the implementation support 32 register function, although most implementations support many more. More important, it does not deal at all with the ability in most implementations to remove DSOs (dynamic shared objects) from a running program image by calling dlclose(3) prior to program termination. The API specified below is intended to provide standard-conforming treatment during normal program exit, which includes executing atexit(3)-registered functions in the correct sequence relative to constructor-registered destructors, and reasonable treatment during early DSO unload (e.g. dlclose(3)). ---snip--- I don't know which list is more appropriate, so please decide on your own (I'm not subscribed to the standards list, so please CC me if you follow up to it only). I haven't tested it yet, but I will test it with icc as soon as I get time. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-arch@FreeBSD.ORG Fri Dec 12 12:42:55 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 1FE8416A4CE for ; Fri, 12 Dec 2003 12:42:55 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38FB143D37 for ; Fri, 12 Dec 2003 12:42:54 -0800 (PST) (envelope-from sam@errno.com) Received: from 66.127.85.91 ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id hBCKgpHQ059365 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 12 Dec 2003 12:42:53 -0800 (PST) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: arch@freebsd.org Date: Fri, 12 Dec 2003 12:45:59 -0800 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312121245.59954.sam@errno.com> Subject: bpf cleanup 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: Fri, 12 Dec 2003 20:42:55 -0000 http://people.freebsd.org/~sam/bpf.patch has changes to eliminate the widespread use of stack-based mbufs for use with bpf. The patch replaces them with a new bpf_mtap2 routine that does the right thing w/o exposing the internal workings of bpf. I've restored the M_ASSERTVALID macro to BPF_MTAP but should probably just move this to the bpf_mtap/bpf_mtap2 routines. Buried in this patch are also some changes to make consistent the prepending of the address family for some devices. Previously some code was assuming sizeof(int) == sizeof(u_int) == 4 bytes; they've all been changed to use u_int32_t. Pending feedback I'll commit this stuff after the freeze is lifted. Sam From owner-freebsd-arch@FreeBSD.ORG Fri Dec 12 12:59:04 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 D012A16A4CE for ; Fri, 12 Dec 2003 12:59:04 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB31F43D33 for ; Fri, 12 Dec 2003 12:59:02 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 1E99B5309; Fri, 12 Dec 2003 21:59:01 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 0AC355308; Fri, 12 Dec 2003 21:58:50 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id C281333C90; Fri, 12 Dec 2003 21:58:49 +0100 (CET) To: Sam Leffler References: <200312121245.59954.sam@errno.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Fri, 12 Dec 2003 21:58:49 +0100 In-Reply-To: <200312121245.59954.sam@errno.com> (Sam Leffler's message of "Fri, 12 Dec 2003 12:45:59 -0800") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_SORBS autolearn=no version=2.60 cc: arch@freebsd.org Subject: Re: bpf cleanup 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: Fri, 12 Dec 2003 20:59:04 -0000 Sam Leffler writes: > Pending feedback I'll commit this stuff after the freeze is lifted. The freeze was lifted several days ago... DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Dec 12 12:59:25 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 B55F616A4CE for ; Fri, 12 Dec 2003 12:59:25 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id A775843D2D for ; Fri, 12 Dec 2003 12:59:24 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id E37475308; Fri, 12 Dec 2003 21:59:23 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id E7792530A; Fri, 12 Dec 2003 21:59:10 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id D7D6F33C90; Fri, 12 Dec 2003 21:59:10 +0100 (CET) To: Sam Leffler References: <200312121245.59954.sam@errno.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Fri, 12 Dec 2003 21:59:10 +0100 In-Reply-To: <200312121245.59954.sam@errno.com> (Sam Leffler's message of "Fri, 12 Dec 2003 12:45:59 -0800") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_SORBS autolearn=no version=2.60 cc: arch@freebsd.org Subject: Re: bpf cleanup 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: Fri, 12 Dec 2003 20:59:25 -0000 Sam Leffler writes: > Buried in this patch are also some changes to make consistent the prepend= ing=20 > of the address family for some devices. Previously some code was assumin= g=20 > sizeof(int) =3D=3D sizeof(u_int) =3D=3D 4 bytes; they've all been changed= to use=20 > u_int32_t. uint32_t please, as per style(9). DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Dec 12 13:03:46 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 CAE0E16A4CE for ; Fri, 12 Dec 2003 13:03:46 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED66F43D1F for ; Fri, 12 Dec 2003 13:03:45 -0800 (PST) (envelope-from sam@errno.com) Received: from 66.127.85.91 ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id hBCL3dHQ059446 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 12 Dec 2003 13:03:42 -0800 (PST) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Fri, 12 Dec 2003 13:06:46 -0800 User-Agent: KMail/1.5.3 References: <200312121245.59954.sam@errno.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200312121306.46987.sam@errno.com> cc: arch@freebsd.org Subject: Re: bpf cleanup 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: Fri, 12 Dec 2003 21:03:46 -0000 On Friday 12 December 2003 12:58 pm, Dag-Erling Sm=F8rgrav wrote: > Sam Leffler writes: > > Pending feedback I'll commit this stuff after the freeze is lifted. > > The freeze was lifted several days ago... I wsa told that widespread changes (of the sort my patch does) are discoura= ged=20 until 5.2 ships. Sam From owner-freebsd-arch@FreeBSD.ORG Fri Dec 12 13:04:16 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 CBFFA16A4D0 for ; Fri, 12 Dec 2003 13:04:16 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5363643D2D for ; Fri, 12 Dec 2003 13:04:15 -0800 (PST) (envelope-from sam@errno.com) Received: from 66.127.85.91 ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id hBCL4AHQ059449 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 12 Dec 2003 13:04:12 -0800 (PST) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Fri, 12 Dec 2003 13:07:18 -0800 User-Agent: KMail/1.5.3 References: <200312121245.59954.sam@errno.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200312121307.18991.sam@errno.com> cc: arch@freebsd.org Subject: Re: bpf cleanup 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: Fri, 12 Dec 2003 21:04:16 -0000 On Friday 12 December 2003 12:59 pm, Dag-Erling Sm=F8rgrav wrote: > Sam Leffler writes: > > Buried in this patch are also some changes to make consistent the > > prepending of the address family for some devices. Previously some code > > was assuming sizeof(int) =3D=3D sizeof(u_int) =3D=3D 4 bytes; they've a= ll been > > changed to use u_int32_t. > > uint32_t please, as per style(9). I following existing code. Someone else can make gratuitous changes like t= his=20 separately. Sam From owner-freebsd-arch@FreeBSD.ORG Fri Dec 12 13:09:19 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 5574B16A4CE for ; Fri, 12 Dec 2003 13:09:19 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 4D77E43D09 for ; Fri, 12 Dec 2003 13:09:18 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 59484 invoked by uid 1002); 12 Dec 2003 21:09:15 -0000 Received: from unknown (HELO ?10.4.1.5?) (64.58.1.252) by smtp.mho.net with SMTP; 12 Dec 2003 21:09:15 -0000 Date: Fri, 12 Dec 2003 14:09:11 -0700 (MST) From: Scott Long X-X-Sender: scottl@pooker.samsco.home To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= In-Reply-To: Message-ID: <20031212140803.C16221@pooker.samsco.home> References: <200312121245.59954.sam@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE cc: Sam Leffler cc: arch@freebsd.org Subject: Re: bpf cleanup 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: Fri, 12 Dec 2003 21:09:19 -0000 On Fri, 12 Dec 2003, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > Sam Leffler writes: > > Pending feedback I'll commit this stuff after the freeze is lifted. > > The freeze was lifted several days ago... > > DES > -- I think that he is trying to respect the 'please don't put radical changes into HEAD before we finalize 5.2' request of the RE team. Scott From owner-freebsd-arch@FreeBSD.ORG Fri Dec 12 13:30:23 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 BE6C516A4CE for ; Fri, 12 Dec 2003 13:30:23 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id B31E443D39 for ; Fri, 12 Dec 2003 13:30:18 -0800 (PST) (envelope-from sam@errno.com) Received: from 66.127.85.91 ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id hBCLUHHQ059603 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 12 Dec 2003 13:30:18 -0800 (PST) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: arch@freebsd.org Date: Fri, 12 Dec 2003 13:33:25 -0800 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312121333.25603.sam@errno.com> Subject: MT_TAG removal 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: Fri, 12 Dec 2003 21:30:23 -0000 http://people.freebsd.org/~sam/mt_tag.patch This set of changes eliminates the use of MT_TAG "pseudo mbufs", replacing them mostly with packet tags (one case is handled by using an mbuf flag since the linkage between "caller" and "callee" is direct and there's no need to incur the overhead of a packet tag). I've tested all these changes except for the PACKET_TAG_IPFORWARD stuff. Before I can commit this stuff I need to do more testing (help welcome) and need to evaluate the cost of doing multiple m_tag_find calls in the IP packet processing paths. I suspect we'll want to make this call first check if any tags exist before calling the code that does the actual list search. I'm looking for code review and general feedback. I especially like the way this cleans up divert sockets (in particular in the handling of fragments). Sam From owner-freebsd-arch@FreeBSD.ORG Sat Dec 13 13:12:08 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 5C8BA16A4CF for ; Sat, 13 Dec 2003 13:12:08 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id C1C4543D33 for ; Sat, 13 Dec 2003 13:12:02 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 59183 invoked by uid 1000); 13 Dec 2003 21:12:03 -0000 Date: Sat, 13 Dec 2003 13:12:03 -0800 (PST) From: Nate Lawson To: arch@freebsd.org Message-ID: <20031213130351.N59162@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi-jp@jp.freebsd.org Subject: Power profile script 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: Sat, 13 Dec 2003 21:12:08 -0000 I've implemented a script for changing power profiles in userland when you go on or off AC power. The defaults will just change the CPU idle states to the lowest power ones when off AC power. Throttling will stay at 100%. Of course, the user can override these in rc.conf. In the future, other power profile features will be maintained by the same script. You have to be running devd to use this. The special values LOW and HIGH refer to the lowest and highest performing settings for a given sysctl. So if a system has 8 throttling values, from 1 to 8, HIGH would be 8 and LOW would be 1. You can also specify a particular value ("2") if you know what you want. I'm mostly looking for style input on the /etc/power_profile script since I'm not familiar with our scripting guidelines. Note that it's called from devd (or manually by the user) and is not an rc.d boot-time thing. -Nate Index: etc/Makefile =================================================================== RCS file: /home/ncvs/src/etc/Makefile,v retrieving revision 1.322 diff -u -r1.322 Makefile --- etc/Makefile 2 Nov 2003 22:13:36 -0000 1.322 +++ etc/Makefile 13 Dec 2003 20:56:55 -0000 @@ -33,7 +33,7 @@ .endif # -rwxr-xr-x root:wheel, for the new cron root:wheel -BIN2= netstart pccard_ether rc.suspend rc.resume +BIN2= netstart pccard_ether power_profile rc.suspend rc.resume MTREE= BSD.include.dist BSD.local.dist BSD.root.dist BSD.usr.dist \ BSD.var.dist BSD.x11.dist BSD.x11-4.dist Index: etc/devd.conf =================================================================== RCS file: /home/ncvs/src/etc/devd.conf,v retrieving revision 1.9 diff -u -r1.9 devd.conf --- etc/devd.conf 25 Oct 2003 05:03:25 -0000 1.9 +++ etc/devd.conf 13 Dec 2003 20:59:14 -0000 @@ -70,6 +70,13 @@ # action "logger Unknown device: $pnpinfo $location $bus"; }; +# Switch power profiles when the AC line state changes +notify 10 { + match "system" "ACPI"; + match "subsystem" "ACAD"; + action "/etc/power_profile $notify"; +}; + /* EXAMPLES TO END OF FILE # The following might be an example of something that a vendor might Index: etc/power_profile =================================================================== RCS file: etc/power_profile diff -N etc/power_profile --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ etc/power_profile 13 Dec 2003 20:58:00 -0000 @@ -0,0 +1,87 @@ +#!/bin/sh - +# +# Modify the power profile based on AC line state. This script is +# usually called from devd(8). +# +# Arguments: 0x00 (AC offline, economy) or 0x01 (AC online, performance) +# +# $FreeBSD$ +# + +LOGGER="logger -t power_profile -p daemon.notice" + +# Set a given sysctl node to a value. +# +# Variables: +# $node: sysctl node to set with the new value +# $value: HIGH for the highest performance value, LOW for the best +# economy value, or the value itself. +# $highest_value: maximum value for this sysctl, when $value is "HIGH" +# $lowest_value: minimum value for this sysctl, when $value is "LOW" +# +sysctl_set () { + # Check if the node exists + if [ -z "`sysctl -n ${node} 2> /dev/null`" ]; then + return + fi + + # Get the new value, checking for special types HIGH or LOW + case ${value} in + [Hh][Ii][Gg][Hh]) + value=${highest_value} + ;; + [Ll][Oo][Ww]) + value=${lowest_value} + ;; + *) + ;; + esac + + # Set the desired value + [ -n "${value}" ] && sysctl ${node}=${value} +} + +# Pull in default values. +if [ -r /etc/defaults/rc.conf ]; then + . /etc/defaults/rc.conf + source_rc_confs +elif [ -r /etc/rc.conf ]; then + . /etc/rc.conf +fi + +if [ $# -ne 1 ]; then + echo "Usage: $0 [0x00|0x01]" + exit 1 +fi + +# Find the next state (performance or economy). +state=$1 +case ${state} in +0x01 | '') + ${LOGGER} "changed to 'performance'" + profile="performance" + ;; +0x00) + ${LOGGER} "changed to 'economy'" + profile="economy" + ;; +*) + echo "Usage: $0 [0x00|0x01]" + exit 1 +esac + +# Set the various sysctls based on the profile's values. +node="hw.acpi.cpu.cx_lowest" +highest_value=0 +lowest_value="`sysctl -n hw.acpi.cpu.cx_supported | \ + awk '{ print split($0, a) - 1 }' - 2> /dev/null`" +eval value=\$${profile}_cx_lowest +sysctl_set + +node="hw.acpi.cpu.throttle_state" +highest_value="`sysctl -n hw.acpi.cpu.throttle_max 2> /dev/null`" +lowest_value="1" +eval value=\$${profile}_throttle_state +sysctl_set + +exit 0 Index: etc/defaults/rc.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.191 diff -u -r1.191 rc.conf --- etc/defaults/rc.conf 28 Nov 2003 17:28:42 -0000 1.191 +++ etc/defaults/rc.conf 13 Dec 2003 20:42:24 -0000 @@ -441,6 +441,11 @@ devfs_rulesets="/etc/defaults/devfs.rules /etc/devfs.rules" # Files containing # devfs(8) rules. devfs_system_ruleset="" # The name of a ruleset to apply to /dev +performance_cx_lowest="HIGH" # Online CPU idle state +performance_throttle_state="HIGH" # Online throttling state +economy_cx_lowest="LOW" # Offline CPU idle state +economy_throttle_state="HIGH" # Offline throttling state + ############################################################## ### Jail Configuration ####################################### Index: sys/dev/acpica/acpi_cpu.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v retrieving revision 1.26 diff -u -r1.26 acpi_cpu.c --- sys/dev/acpica/acpi_cpu.c 12 Dec 2003 19:42:16 -0000 1.26 +++ sys/dev/acpica/acpi_cpu.c 13 Dec 2003 04:27:46 -0000 @@ -134,10 +134,8 @@ static int cpu_idle_busy; /* Count of CPUs in acpi_cpu_idle. */ /* Values for sysctl. */ -static uint32_t cpu_current_state; -static uint32_t cpu_performance_state; -static uint32_t cpu_economy_state; -static uint32_t cpu_max_state; +static uint32_t cpu_throttle_state; +static uint32_t cpu_throttle_max; static int cpu_cx_lowest; static char cpu_cx_supported[64]; @@ -165,7 +163,6 @@ static void acpi_pm_ticksub(uint32_t *end, const uint32_t *start); static void acpi_cpu_notify(ACPI_HANDLE h, UINT32 notify, void *context); static int acpi_cpu_quirks(struct acpi_cpu_softc *sc); -static void acpi_cpu_power_profile(void *arg); static int acpi_cpu_throttle_sysctl(SYSCTL_HANDLER_ARGS); static int acpi_cpu_history_sysctl(SYSCTL_HANDLER_ARGS); static int acpi_cpu_cx_lowest_sysctl(SYSCTL_HANDLER_ARGS); @@ -616,10 +613,6 @@ /* Get set of CPU devices */ devclass_get_devices(acpi_cpu_devclass, &cpu_devices, &cpu_ndevices); - /* Register performance profile change handler */ - EVENTHANDLER_REGISTER(power_profile_change, acpi_cpu_power_profile, - NULL, 0); - /* * Make sure all the processors' Cx counts match. We should probably * also check the contents of each. However, no known systems have @@ -647,60 +640,34 @@ static void acpi_cpu_startup_throttling() { - int cpu_temp_speed; ACPI_LOCK_DECL; /* Initialise throttling states */ - cpu_max_state = CPU_MAX_SPEED; - cpu_performance_state = cpu_max_state; - cpu_economy_state = cpu_performance_state / 2; - - /* 0 is 'reserved' */ - if (cpu_economy_state == 0) - cpu_economy_state++; - if (TUNABLE_INT_FETCH("hw.acpi.cpu.performance_speed", &cpu_temp_speed) && - cpu_temp_speed > 0 && cpu_temp_speed <= cpu_max_state) { - - cpu_performance_state = cpu_temp_speed; - } - if (TUNABLE_INT_FETCH("hw.acpi.cpu.economy_speed", &cpu_temp_speed) && - cpu_temp_speed > 0 && cpu_temp_speed <= cpu_max_state) { - - cpu_economy_state = cpu_temp_speed; - } + cpu_throttle_max = CPU_MAX_SPEED; + cpu_throttle_state = CPU_MAX_SPEED; SYSCTL_ADD_INT(&acpi_cpu_sysctl_ctx, SYSCTL_CHILDREN(acpi_cpu_sysctl_tree), - OID_AUTO, "max_speed", CTLFLAG_RD, - &cpu_max_state, 0, "maximum CPU speed"); - SYSCTL_ADD_INT(&acpi_cpu_sysctl_ctx, - SYSCTL_CHILDREN(acpi_cpu_sysctl_tree), - OID_AUTO, "current_speed", CTLFLAG_RD, - &cpu_current_state, 0, "current CPU speed"); - SYSCTL_ADD_PROC(&acpi_cpu_sysctl_ctx, - SYSCTL_CHILDREN(acpi_cpu_sysctl_tree), - OID_AUTO, "performance_speed", - CTLTYPE_INT | CTLFLAG_RW, &cpu_performance_state, - 0, acpi_cpu_throttle_sysctl, "I", ""); + OID_AUTO, "throttle_max", CTLFLAG_RD, + &cpu_throttle_max, 0, "maximum CPU speed"); SYSCTL_ADD_PROC(&acpi_cpu_sysctl_ctx, SYSCTL_CHILDREN(acpi_cpu_sysctl_tree), - OID_AUTO, "economy_speed", - CTLTYPE_INT | CTLFLAG_RW, &cpu_economy_state, - 0, acpi_cpu_throttle_sysctl, "I", ""); + OID_AUTO, "throttle_state", + CTLTYPE_INT | CTLFLAG_RW, &cpu_throttle_state, + 0, acpi_cpu_throttle_sysctl, "I", "current CPU speed"); /* If ACPI 2.0+, signal platform that we are taking over throttling. */ - if (cpu_pstate_cnt != 0) { - ACPI_LOCK; + ACPI_LOCK; + if (cpu_pstate_cnt != 0) AcpiOsWritePort(cpu_smi_cmd, cpu_pstate_cnt, 8); - ACPI_UNLOCK; - } - /* Set initial speed */ - acpi_cpu_power_profile(NULL); + /* Set initial speed to maximum. */ + acpi_cpu_throttle_set(cpu_throttle_max); + ACPI_UNLOCK; printf("acpi_cpu: throttling enabled, %d steps (100%% to %d.%d%%), " "currently %d.%d%%\n", CPU_MAX_SPEED, CPU_SPEED_PRINTABLE(1), - CPU_SPEED_PRINTABLE(cpu_current_state)); + CPU_SPEED_PRINTABLE(cpu_throttle_state)); } static void @@ -787,7 +754,7 @@ ACPI_VPRINT(sc->cpu_dev, acpi_device_get_parent_softc(sc->cpu_dev), "set speed to %d.%d%%\n", CPU_SPEED_PRINTABLE(speed)); } - cpu_current_state = speed; + cpu_throttle_state = speed; } /* @@ -1026,54 +993,14 @@ return (0); } -/* - * Power profile change hook. - * - * Uses the ACPI lock to avoid reentrancy. - */ -static void -acpi_cpu_power_profile(void *arg) -{ - int state; - uint32_t new; - ACPI_LOCK_DECL; - - state = power_profile_get_state(); - if (state != POWER_PROFILE_PERFORMANCE && state != POWER_PROFILE_ECONOMY) - return; - - ACPI_LOCK; - - switch (state) { - case POWER_PROFILE_PERFORMANCE: - new = cpu_performance_state; - break; - case POWER_PROFILE_ECONOMY: - new = cpu_economy_state; - break; - default: - new = cpu_current_state; - break; - } - - if (cpu_current_state != new) - acpi_cpu_throttle_set(new); - - ACPI_UNLOCK; -} - -/* - * Handle changes in the performance/ecomony CPU settings. - * - * Does not need the ACPI lock (although setting *argp should - * probably be atomic). - */ +/* Handle changes in the CPU throttling setting. */ static int acpi_cpu_throttle_sysctl(SYSCTL_HANDLER_ARGS) { uint32_t *argp; uint32_t arg; int error; + ACPI_LOCK_DECL; argp = (uint32_t *)oidp->oid_arg1; arg = *argp; @@ -1082,12 +1009,16 @@ /* Error or no new value */ if (error != 0 || req->newptr == NULL) return (error); - if (arg < 1 || arg > cpu_max_state) + if (arg < 1 || arg > cpu_throttle_max) return (EINVAL); - /* Set new value and possibly switch */ - *argp = arg; - acpi_cpu_power_profile(NULL); + /* If throttling changed, notify the BIOS of the new rate. */ + ACPI_LOCK; + if (*argp != arg) { + *argp = arg; + acpi_cpu_throttle_set(arg); + } + ACPI_UNLOCK; return (0); } Index: share/man/man4/acpi.4 =================================================================== RCS file: /home/ncvs/src/share/man/man4/acpi.4,v retrieving revision 1.20 diff -u -r1.20 acpi.4 --- share/man/man4/acpi.4 19 Nov 2003 20:37:15 -0000 1.20 +++ share/man/man4/acpi.4 13 Dec 2003 05:04:22 -0000 @@ -328,12 +328,12 @@ .El .Sh SYSCTLS .Bl -tag -width indent -.It Va hw.acpi.cpu.performance_speed -Sets the speed of the CPU, if it supports multiple speeds, while in -the performance power profile. -.It Va hw.acpi.cpu.economy_speed -Sets the speed of the CPU, if it supports multiple speeds, while in -the economy power profile. +.It Va hw.acpi.cpu.throttle_max +Maximum value for CPU throttling, equal to 100% of the clock rate. +.It Va hw.acpi.cpu.throttle_state +Get or set the current throttling state, from 1 to +.Va hw.acpi.cpu.throttle_max . +This scales back the CPU clock rate and the corresponding power consumption. .It Va hw.acpi.cpu.cx_history Debugging information listing all sleep states and the number of long and short sleeps for each one. From owner-freebsd-arch@FreeBSD.ORG Sat Dec 13 16:37:46 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 83C6E16A4CE for ; Sat, 13 Dec 2003 16:37:46 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 593AC43D32 for ; Sat, 13 Dec 2003 16:37:45 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id hBE0bhEJ012599; Sat, 13 Dec 2003 17:37:43 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 13 Dec 2003 17:33:39 -0700 (MST) Message-Id: <20031213.173339.91736203.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20031213130351.N59162@root.org> References: <20031213130351.N59162@root.org> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: acpi-jp@jp.freebsd.org Subject: Re: Power profile script 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: Sun, 14 Dec 2003 00:37:46 -0000 Looks OK to me. Warner