From dchieu@sac.sfbay.sun.com Wed Dec 5 10:51:00 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB5IoxIp009953 for ; Wed, 5 Dec 2007 10:51:00 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lB5IowMO010833; Thu, 6 Dec 2007 02:50:58 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL00401B0XIQ00@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Dec 2007 10:50:57 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL00IFBB0WRGF0@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Dec 2007 10:50:57 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB5IouIc058048; Wed, 05 Dec 2007 10:50:56 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB5Ios4L009937; Wed, 05 Dec 2007 10:50:54 -0800 (PST) Received: (from dchieu@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id lB5IosEY009933; Wed, 05 Dec 2007 10:50:54 -0800 (PST) Date: Wed, 05 Dec 2007 10:50:54 -0800 (PST) From: David Chieu Subject: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] To: PSARC-ext@sun.com Cc: Mark.Haywood@sun.com, Napanda.Pemmaiah@sun.com, Phi.Tran@sun.com Message-id: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 7609 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: CPUFreq HAL 1.2. Name of Document Author/Supplier: Author: Anup Pemmaiah 1.3 Date of This Document: 05 December, 2007 4. Technical Description 4.0 Introduction =============== This project delivers the CPU power management related support for the HAL interfaces used by the GNOME Power Manager (GPM) desktop application to control CPU power management behavior. 4.1 Background and Summary ========================= LSARC/2006/462 proposed adding GNOME Power Manager (GPM), a workstation power management GUI, to the Solaris GNOME desktop. One of the components provided by GPM is a preference dialog used to configure CPU power management settings. In order to support the CPU power management dialog, the host OS (Solaris) is required to provide backend support for the pre-defined Hardware Abstraction Layer (HAL) interfaces [1]. See PSARC/2005/399 for more information on HAL. HAL defines a CPU Freq interface that it uses to support CPU power management. This case, defines those interfaces and explains what existing Solaris interfaces will be used to support the HAL CPU Freq interface. 4.2 Block Diagram ================= An end-to-end GNOME CPU power management system diagram. The dotted lines indicate the boundaries of the pieces implemented by this project. +--------------------------+ | | |GNOME CPU power management| LSARC/2006/462 GNOME-2.16 | applet GUI | +--------------------------+ ^ | (D-bus) | JDS consolidation (up) -------------+-------------------------------------------------- | ON consolidation (below) | (D-bus) v +-------------------------+ | HAL daemon (hald) | PSARC/2005/399 Tamarack ............................... : | | : : +--------------------+ | : : | CPU Freq | | : : | daemon | | : +-----------+ : | hald-addon-cpufreq | |<---->| kstat(1M) | : +--------------------+----+ : +-----------+ : ^ : ^ :.........|...................: | | | | | v | +-------------------------+ | | power.conf | | | | | | pmconfig utility | | +-------------------------+ | ^ | | | | (ioctl) | USER -----------+------------------------------+--------------- | | KERNEL | | v | +------------------+ | | | | (kstat) | cpu driver |<------------------+ | | +------------------+ 4.3 Project Details ================== 4.3.1 Data flow of CPU Freq HAL method interface ---------------------------------------------- GPM uses the HAL CPU Freq Interface to manage CPU power management policies on the host workstation. The Interface has one major CPU power management concept of interest to this case. HAL refers to CPU power management policy types as governors. The two governors that this case intends to support initially are the "On Demand" governor and the "Performance" governor. The "On Demand" governor is a CPU power management policy whereby dynamic CPU frequency scaling is performed by monitoring CPU utilization and scaling the frequency when appropriate. The "Performance" governor is a CPU power management policy intended to allow the desktop to get full CPU utilization all the time (i.e., no frequency scaling). Both governors will be implemented using the power.conf(4) cpupm keyword introduced by PSARC/2005/067. "On Demand" translates to cpupm being enabled and "Performance" translates to cpupm being disabled. Also of interest to this case, is that the CPU Freq interface supports defining a performance property for governors. The performance property is meant to provide the governor with a hint at how aggressively it should manage CPU power. This case proposes to use the frequency performance attribute as a means of calculating a cpu-threshold value for power.conf(4). The cpu-threshold keyword was introduced by PSARC/2005/067. 4.3.2 Interfaces -------------- Interfaces Exported: All the interfaces exported by this project are HAL cpu-freq related and detailed information can be found on the HAL webpage [1]. They are "Committed" level. These interfaces can be used by GPM. Interface Method Name Return Parameters Comments ------------------------------------------------------------------- SetCPUFreqGovernor void string Type of governor (policy) to set as described in 3.1. GetCPUFreqGovernor string None Returns current policy GetCPUFreqAvailable string[] None Returns the list of Governors supported policies SetCPUFreqPerformance void int Set the performance of the (between 1-100) CPU Freq scaling. Higher the value is better perfo- rmance. In our implementa- tion, this value is used to set the CPU Freq scaling by varying the "cpu-threshold" parameter in the power.conf. GetCPUFreqPerformance int None Return the current performance value set by SetCPUFreqPerformance SetCPUFreqConsiderNice void Bool Whether or not niced processes (consider should be considered on CPU niced load calculation. processes) Note: Since none of the current CPU power management policies consider niced processes this method just returns CPUFreq.NoSuitableGovernor) GetCPUFreqConsiderNice bool None Whether nice'ed processes are considered by the governor. Note: Since none of the current CPU power management policies consider niced processes this method just returns CPUFreq.NoSuitableGovernor) The processor specific properties interface Interface Type Comments --------------------------------------------------------------- processor.number int The internal processor number processor.throttle boolean Whether the processor supports throttling to decrease it's own clock speed processor.maximum_speed long The maximum speed of the processor in units of MHz Interfaces Imported: Interface Comments --------------------------------------------------------------- power.conf(4) Used by SetCPUFreqGovernor & SetCPUPerformance to edit the "cpupm" & "cpu-threshold" parameters in power.conf respectively. The other method interfaces reads these values and return the current values that are set pmconfig(1M) When power.conf is edited anytime, pmconfig should be called for the edited power.conf to take effect cpu_info kstat Used by HAL cpu freq interface to get the max "clock_MHz" supported freq cpu_info kstat To check if processor supports power management "supported_frequencies_Hz" FOOTNOTES: ========== [1] More info about HAL interface can be found at http://people.freedesktop.org/~david/hal-spec/hal-spec.html 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Nicolas.Williams@sun.com Wed Dec 5 11:09:45 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB5J9iTD010736 for ; Wed, 5 Dec 2007 11:09:45 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB5J9ers026498; Wed, 5 Dec 2007 19:09:41 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL0020XBW3CM00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 05 Dec 2007 11:09:40 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL00IRDBW3UB20@nwk-avmta-1.sfbay.Sun.COM>; Wed, 05 Dec 2007 11:09:39 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lB5J9cYX008113; Wed, 05 Dec 2007 13:09:38 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lB5J9cJM008112; Wed, 05 Dec 2007 13:09:38 -0600 (CST) Date: Wed, 05 Dec 2007 13:09:38 -0600 From: Nicolas Williams Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> To: David Chieu Cc: psarc-ext@sun.com, Mark.Haywood@sun.com, Napanda.Pemmaiah@sun.com, Phi.Tran@sun.com Mail-followup-to: David Chieu , psarc-ext@sun.com, Mark.Haywood@sun.com, Napanda.Pemmaiah@sun.com, Phi.Tran@sun.com Message-id: <20071205190937.GF6985@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 458 > Method Name Return Parameters Comments > ------------------------------------------------------------------- > > GetCPUFreqPerformance int None Return the current > performance value set by > SetCPUFreqPerformance So this is used in a poll loop, right? Any chance that we could have an async or blocking interface to avoid waking up periodically just to check that, gee, the CPU clock frequency hasn't changed? Nico -- From Artem.Kachitchkin@sun.com Wed Dec 5 11:26:51 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB5JQphu011112 for ; Wed, 5 Dec 2007 11:26:51 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB5JQnNa008944 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 5 Dec 2007 19:26:49 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL00509CONFU00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 11:26:47 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL00IYOCOMUJ30@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 11:26:46 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB5JQkPE028905 for ; Wed, 05 Dec 2007 11:26:46 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSL00601CC5OT00@fe-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 11:26:46 -0800 (PST) Received: from [192.168.1.100] ([75.7.42.131]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSL00062CODGP60@fe-sfbay-10.sun.com>; Wed, 05 Dec 2007 11:26:41 -0800 (PST) Date: Wed, 05 Dec 2007 11:26:01 -0800 From: Artem Kachitchkine Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> Sender: Artem.Kachitchkin@sun.com To: David Chieu Cc: psarc-ext@sun.com, Mark.Haywood@sun.com, Napanda.Pemmaiah@sun.com, Phi.Tran@sun.com Message-id: <4756FB49.5050906@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 459 You described properties and interfaces, but those do not exist in vacuum, they must be associated with device objects that HAL maintains. Could you expand on that. E.g. it appears that processor.* properties belong to device objects with "processor" capability: will HAL create one object per physical CPU? Do clients (such as GPM) usually call Set* methods on each processor object? Any interesting implications wrt massive coring/threading? -Artem From Napanda.Pemmaiah@sun.com Wed Dec 5 12:02:33 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB5K2X6b012236 for ; Wed, 5 Dec 2007 12:02:33 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lB5K2W3m023972 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 5 Dec 2007 12:02:33 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL0071ZEC7GR00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 12:02:31 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL004RSEBNKZ30@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 12:02:12 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB5K2BS1009363 for ; Wed, 05 Dec 2007 12:02:11 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSL00D01EBDVH00@fe-sfbay-10.sun.com> (original mail from Napanda.Pemmaiah@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 12:02:11 -0800 (PST) Received: from [129.146.106.209] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSL001IWEBNDJ40@fe-sfbay-10.sun.com>; Wed, 05 Dec 2007 12:02:11 -0800 (PST) Date: Wed, 05 Dec 2007 12:02:11 -0800 From: Anup Pemmaiah Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <20071205190937.GF6985@Sun.COM> Sender: Napanda.Pemmaiah@sun.com To: David Chieu , psarc-ext@sun.com, Mark.Haywood@sun.com, Napanda.Pemmaiah@sun.com, Phi.Tran@sun.com Message-id: <475703C3.9090605@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <20071205190937.GF6985@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 749 Nicolas Williams wrote: >> Method Name Return Parameters Comments >> ------------------------------------------------------------------- >> >> GetCPUFreqPerformance int None Return the current >> performance value set by >> SetCPUFreqPerformance >> > > So this is used in a poll loop, right? > No, it is not used in a poll loop. It is just used by application mostly once during initialization time to just get the current performance value that is set. In our case the cpu_threshold value that is in the power.conf file Anup > Any chance that we could have an async or blocking interface to avoid > waking up periodically just to check that, gee, the CPU clock frequency > hasn't changed? > > Nico > From Napanda.Pemmaiah@sun.com Wed Dec 5 12:08:02 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB5K81PQ012321 for ; Wed, 5 Dec 2007 12:08:02 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lB5K7ueI019808 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 Dec 2007 04:08:01 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL00C0VEL9O700@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 12:07:57 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL00IU5EL7UB60@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 12:07:55 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB5K7t2P004264 for ; Wed, 05 Dec 2007 12:07:55 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSL00301E6O3L00@fe-sfbay-09.sun.com> (original mail from Napanda.Pemmaiah@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 12:07:55 -0800 (PST) Received: from [129.146.106.209] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSL00LLKEL6PY50@fe-sfbay-09.sun.com>; Wed, 05 Dec 2007 12:07:54 -0800 (PST) Date: Wed, 05 Dec 2007 12:07:54 -0800 From: Anup Pemmaiah Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <4756FB49.5050906@sun.com> Sender: Napanda.Pemmaiah@sun.com To: Artem Kachitchkine Cc: David Chieu , psarc-ext@sun.com, Mark.Haywood@sun.com, Phi.Tran@sun.com Message-id: <4757051A.3090008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 906 Artem Kachitchkine wrote: > > You described properties and interfaces, but those do not exist in > vacuum, they must be associated with device objects that HAL maintains. Yes, the processor properties are associated with the cpu device object. > Could you expand on that. E.g. it appears that processor.* properties > belong to device objects with "processor" capability: will HAL create > one object per physical CPU? Each processor will have a cpu device object, with the device object UDI being differentiated with the cpu id. Under each device object, it will have its associated processor properties. > Do clients (such as GPM) usually call Set* methods on each processor > object? Any interesting implications wrt massive coring/threading? Set* methods will not be called on each processor. It applies for all the processors. No implications wrt massive coring/threading Anup > > -Artem From Artem.Kachitchkin@sun.com Wed Dec 5 12:16:36 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB5KGZsq012396 for ; Wed, 5 Dec 2007 12:16:36 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB5KGVrZ007743 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 5 Dec 2007 20:16:34 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL0070BEZKYS00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 12:16:32 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL004PJEZJKV40@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 12:16:31 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB5KGVAk010934 for ; Wed, 05 Dec 2007 12:16:31 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSL00801EYNTR00@fe-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 12:16:31 -0800 (PST) Received: from [192.168.1.100] ([75.7.42.131]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSL001FIEZHDJB0@fe-sfbay-10.sun.com>; Wed, 05 Dec 2007 12:16:29 -0800 (PST) Date: Wed, 05 Dec 2007 12:15:52 -0800 From: Artem Kachitchkine Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <4757051A.3090008@sun.com> Sender: Artem.Kachitchkin@sun.com To: Anup Pemmaiah Cc: David Chieu , psarc-ext@sun.com, Mark.Haywood@sun.com, Phi.Tran@sun.com Message-id: <475706F8.5090700@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 361 > Each processor will have a cpu device object, What happens when CPUs are DR removed/added ? > Set* methods will not be called on each processor. It applies for all > the processors. Interfaces and methods are associated with objects. So what you're saying is, even though a method is called on a particular CPU object, it will affect all CPUs? -Artem From Napanda.Pemmaiah@Sun.COM Wed Dec 5 17:12:22 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB61CLMc018570 for ; Wed, 5 Dec 2007 17:12:22 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB61CKFg018524 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 Dec 2007 01:12:20 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL00M01SOKQ800@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 18:12:20 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL002CESOJ9UF0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 18:12:19 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB61CJcL011700 for ; Wed, 05 Dec 2007 17:12:19 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSL00801SGGVK00@fe-sfbay-10.sun.com> (original mail from Napanda.Pemmaiah@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 17:12:19 -0800 (PST) Received: from [129.146.106.209] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSL002IFSO85CD0@fe-sfbay-10.sun.com>; Wed, 05 Dec 2007 17:12:08 -0800 (PST) Date: Wed, 05 Dec 2007 17:12:08 -0800 From: Anup Pemmaiah Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <475706F8.5090700@sun.com> Sender: Napanda.Pemmaiah@Sun.COM To: Artem Kachitchkine Cc: David Chieu , psarc-ext@Sun.COM, Mark.Haywood@Sun.COM, Phi.Tran@Sun.COM Message-id: <47574C68.2050809@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 636 Artem Kachitchkine wrote: > >> Each processor will have a cpu device object, > > What happens when CPUs are DR removed/added ? The associated device objects should get removed. > >> Set* methods will not be called on each processor. It applies for all >> the processors. > > Interfaces and methods are associated with objects. So what you're > saying is, even though a method is called on a particular CPU object, > it will affect all CPUs? The CPUFreq interface is associated with the "computer" device object, similar to system power management interface. Since it is global there will be just one method call. Anup > > -Artem From bart.smaalders@sun.com Wed Dec 5 17:37:50 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB61bnrV018735 for ; Wed, 5 Dec 2007 17:37:50 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lB61besZ029869; Thu, 6 Dec 2007 09:37:44 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL0010DTUSRT00@brm-avmta-1.central.sun.com>; Wed, 05 Dec 2007 18:37:40 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL00003TUSFY10@brm-avmta-1.central.sun.com>; Wed, 05 Dec 2007 18:37:40 -0700 (MST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lB61bd3O610912; Wed, 05 Dec 2007 17:37:40 -0800 (PST) Date: Wed, 05 Dec 2007 17:33:33 -0800 From: Bart Smaalders Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <47574C68.2050809@sun.com> To: Anup Pemmaiah Cc: Artem Kachitchkine , David Chieu , psarc-ext@sun.com, Mark.Haywood@sun.com, Phi.Tran@sun.com Message-id: <4757516D.6070608@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 894 Anup Pemmaiah wrote: > Artem Kachitchkine wrote: >> >>> Each processor will have a cpu device object, >> >> What happens when CPUs are DR removed/added ? > The associated device objects should get removed. >> >>> Set* methods will not be called on each processor. It applies for all >>> the processors. >> >> Interfaces and methods are associated with objects. So what you're >> saying is, even though a method is called on a particular CPU object, >> it will affect all CPUs? > The CPUFreq interface is associated with the "computer" device object, > similar to system power management interface. Since it is global there > will be just one method call. > > Anup >> >> -Artem > It seems to me that multi-socket machines need to support different speeds on different sockets. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From Artem.Kachitchkin@sun.com Wed Dec 5 17:38:58 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB61cueV018779 for ; Wed, 5 Dec 2007 17:38:57 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lB61cqjn000283 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 Dec 2007 09:38:56 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL00409TWT6600@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 17:38:53 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL00MXHTWRS970@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 17:38:52 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB61cpcS016618 for ; Wed, 05 Dec 2007 17:38:51 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSL00901TVW6Y00@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Dec 2007 17:38:51 -0800 (PST) Received: from [192.168.1.100] ([75.7.42.131]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSL000K6TWRP930@fe-sfbay-09.sun.com>; Wed, 05 Dec 2007 17:38:51 -0800 (PST) Date: Wed, 05 Dec 2007 17:38:13 -0800 From: Artem Kachitchkine Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <47574C68.2050809@sun.com> Sender: Artem.Kachitchkin@sun.com To: Anup Pemmaiah Cc: David Chieu , psarc-ext@sun.com, Mark.Haywood@sun.com, Phi.Tran@sun.com Message-id: <47575285.7010505@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 838 >> What happens when CPUs are DR removed/added ? > The associated device objects should get removed. Will that be achieved via DR sysevents or some other mechanism? > The CPUFreq interface is associated with the "computer" device object, > similar to system power management interface. Since it is global there > will be just one method call. OK, so based on our little q&a, things missing from the interface table: - DBus interface name (org.freedesktop.Hal.Device.CPUFreq?) - DBus path of the objects that implement that interface (/org/freedesktop/Hal/devices/computer?) - "processor" capability for processor objects - I think also "cpufreq_control" capability for the computer object Could you also place a copy of hal-spec.html in the case directory, because the one at freedesktop.org changes frequently. thanks, -Artem From Mark.Haywood@sun.com Wed Dec 5 17:53:06 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB61r5K6018901 for ; Wed, 5 Dec 2007 17:53:05 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lB61qxtu006146; Thu, 6 Dec 2007 09:53:02 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL00703UKC8000@nwk-avmta-1.sfbay.Sun.COM>; Wed, 05 Dec 2007 17:53:00 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL00MW3UKBS9B0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 05 Dec 2007 17:52:59 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB61qxbg007393; Thu, 06 Dec 2007 01:52:59 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSL00401UILDU00@mail-amer.sun.com> (original mail from Mark.Haywood@Sun.COM); Wed, 05 Dec 2007 18:52:59 -0700 (MST) Received: from [129.148.19.14] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSL00C3DUK62R60@mail-amer.sun.com>; Wed, 05 Dec 2007 18:52:59 -0700 (MST) Date: Wed, 05 Dec 2007 20:51:15 -0500 From: Mark Haywood Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <4757516D.6070608@Sun.COM> Sender: Mark.Haywood@sun.com To: Bart Smaalders Cc: Anup Pemmaiah , Artem Kachitchkine , David Chieu , psarc-ext@sun.com, Phi.Tran@sun.com Message-id: <47575593.9@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> <4757516D.6070608@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060828) Status: RO Content-Length: 947 Bart Smaalders wrote: > Anup Pemmaiah wrote: >> Artem Kachitchkine wrote: >>> >>>> Each processor will have a cpu device object, >>> >>> What happens when CPUs are DR removed/added ? >> The associated device objects should get removed. >>> >>>> Set* methods will not be called on each processor. It applies for >>>> all the processors. >>> >>> Interfaces and methods are associated with objects. So what you're >>> saying is, even though a method is called on a particular CPU object, >>> it will affect all CPUs? >> The CPUFreq interface is associated with the "computer" device object, >> similar to system power management interface. Since it is global there >> will be just one method call. >> >> Anup >>> >>> -Artem >> > > It seems to me that multi-socket machines need to support > different speeds on different sockets. If I remember correctly, GPM doesn't allow you to configure speeds an individual processors or sockets. Mark From Artem.Kachitchkin@sun.com Wed Dec 5 17:57:53 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB61vqGj019287 for ; Wed, 5 Dec 2007 17:57:52 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lB61vib5008319; Thu, 6 Dec 2007 09:57:49 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL00809USA7S00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 05 Dec 2007 17:57:46 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL00M7XUSAS9D0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 05 Dec 2007 17:57:46 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB61vjE4015162; Wed, 05 Dec 2007 17:57:45 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSL00M01UR2X500@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM); Wed, 05 Dec 2007 17:57:45 -0800 (PST) Received: from [192.168.1.100] ([75.7.42.131]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSL000RKUS9P980@fe-sfbay-09.sun.com>; Wed, 05 Dec 2007 17:57:45 -0800 (PST) Date: Wed, 05 Dec 2007 17:57:07 -0800 From: Artem Kachitchkine Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <47575593.9@sun.com> Sender: Artem.Kachitchkin@sun.com To: Mark Haywood Cc: Bart Smaalders , Anup Pemmaiah , David Chieu , psarc-ext@sun.com, Phi.Tran@sun.com Message-id: <475756F3.6060108@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> <4757516D.6070608@Sun.COM> <47575593.9@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 375 >> It seems to me that multi-socket machines need to support >> different speeds on different sockets. > > If I remember correctly, GPM doesn't allow you to configure speeds an > individual processors or sockets. Yes, it appears how this particular API is designed. More sophisticated functionality would require working with the community on extending the API. -Artem From casper@holland.sun.com Thu Dec 6 01:16:50 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB69Goou027316 for ; Thu, 6 Dec 2007 01:16:50 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB69GQPp010927 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 Dec 2007 09:16:48 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSM0051ZF409N00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 01:16:48 -0800 (PST) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSM004I6F3Y6V00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 01:16:47 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [129.159.130.93]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id lB69GbJT008480; Thu, 06 Dec 2007 09:16:38 +0000 (GMT) Date: Thu, 06 Dec 2007 10:16:37 +0100 From: Casper.Dik@sun.com Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <4757516D.6070608@Sun.COM> Sender: casper@holland.sun.com To: Bart Smaalders Cc: Anup Pemmaiah , Artem Kachitchkine , David Chieu , psarc-ext@sun.com, Mark.Haywood@sun.com, Phi.Tran@sun.com Message-id: <200712060916.lB69GbJT008480@dm-holland-01.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> <4757516D.6070608@Sun.COM> Status: RO Content-Length: 200 >It seems to me that multi-socket machines need to support >different speeds on different sockets. And even in some cases different speeds on different cores. (Barcelona in AM3 sockets) Casper From bart.smaalders@Sun.COM Thu Dec 6 09:19:45 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB6HJi0t005135 for ; Thu, 6 Dec 2007 09:19:45 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB6HJcMF027740; Thu, 6 Dec 2007 17:19:38 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSN0070P1GO2400@brm-avmta-1.central.sun.com>; Thu, 06 Dec 2007 10:19:36 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSN003KV1GLNN30@brm-avmta-1.central.sun.com>; Thu, 06 Dec 2007 10:19:33 -0700 (MST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lB6HJWDd823703; Thu, 06 Dec 2007 09:19:33 -0800 (PST) Date: Thu, 06 Dec 2007 09:15:25 -0800 From: Bart Smaalders Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <200712060916.lB69GbJT008480@dm-holland-01.uk.sun.com> To: Casper.Dik@Sun.COM Cc: Anup Pemmaiah , Artem Kachitchkine , David Chieu , psarc-ext@Sun.COM, Mark.Haywood@Sun.COM, Phi.Tran@Sun.COM Message-id: <47582E2D.4040703@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> <4757516D.6070608@Sun.COM> <200712060916.lB69GbJT008480@dm-holland-01.uk.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 699 Casper.Dik@sun.com wrote: > >> It seems to me that multi-socket machines need to support >> different speeds on different sockets. > > > And even in some cases different speeds on different cores. > > (Barcelona in AM3 sockets) > > Casper > Indeed. It would appear that one answer is CPU power management groups. These groups would consist of one or more virtual CPUs depending on the hardware capabilities; a single group would be all the virtual CPUs that run at the same power level. Setting the power level on one of the virtual CPUs would affect all the rest in that group. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From Mark.Haywood@sun.com Thu Dec 6 09:23:33 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB6HNWYA005252 for ; Thu, 6 Dec 2007 09:23:33 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB6HNEBq000196; Thu, 6 Dec 2007 17:23:30 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSN00N0X1N52000@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Dec 2007 09:23:29 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSN000NC1N1EGD0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Dec 2007 09:23:25 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB6HNPMT009940; Thu, 06 Dec 2007 17:23:25 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSN00E0105CFE00@mail-amer.sun.com> (original mail from Mark.Haywood@Sun.COM); Thu, 06 Dec 2007 10:23:25 -0700 (MST) Received: from [129.148.174.28] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSN00DSA1MNQ6D0@mail-amer.sun.com>; Thu, 06 Dec 2007 10:23:12 -0700 (MST) Date: Thu, 06 Dec 2007 12:28:20 -0500 From: Mark Haywood Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <47582E2D.4040703@Sun.COM> Sender: Mark.Haywood@sun.com To: Bart Smaalders Cc: Casper.Dik@sun.com, Anup Pemmaiah , Artem Kachitchkine , David Chieu , psarc-ext@sun.com, Phi.Tran@sun.com Message-id: <47583134.8000701@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> <4757516D.6070608@Sun.COM> <200712060916.lB69GbJT008480@dm-holland-01.uk.sun.com> <47582E2D.4040703@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) Status: RO Content-Length: 690 Bart Smaalders wrote: > Casper.Dik@sun.com wrote: >> >>> It seems to me that multi-socket machines need to support >>> different speeds on different sockets. >> >> >> And even in some cases different speeds on different cores. >> >> (Barcelona in AM3 sockets) >> >> Casper >> > > Indeed. It would appear that one answer is CPU power management groups. > These groups would consist of one or more virtual CPUs depending on > the hardware capabilities; a single group would be all the virtual CPUs > that run at the same power level. Setting the power level on one of the > virtual CPUs would affect all the rest in that group. Right. ACPI has a _PSD object to define this grouping. Mark From Napanda.Pemmaiah@sun.com Thu Dec 6 14:54:56 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB6Msuhn017369 for ; Thu, 6 Dec 2007 14:54:56 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lB6MsueK012198 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 Dec 2007 14:54:56 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSN00801GZKXA00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Thu, 06 Dec 2007 15:54:56 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSN0030WGZJOA50@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Thu, 06 Dec 2007 15:54:55 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB6MstXf012392 for ; Thu, 06 Dec 2007 14:54:55 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSN00E01CI0TW00@fe-sfbay-10.sun.com> (original mail from Napanda.Pemmaiah@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Thu, 06 Dec 2007 14:54:55 -0800 (PST) Received: from [129.146.106.209] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSN00HK2GZ3D4A0@fe-sfbay-10.sun.com>; Thu, 06 Dec 2007 14:54:39 -0800 (PST) Date: Thu, 06 Dec 2007 14:54:39 -0800 From: Anup Pemmaiah Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <47575285.7010505@sun.com> Sender: Napanda.Pemmaiah@sun.com To: Artem Kachitchkine Cc: David Chieu , psarc-ext@sun.com, Mark.Haywood@sun.com, Phi.Tran@sun.com Message-id: <47587DAF.9050407@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> <47575285.7010505@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2945 Artem Kachitchkine wrote: > >>> What happens when CPUs are DR removed/added ? >> The associated device objects should get removed. > > Will that be achieved via DR sysevents or some other mechanism? > >> The CPUFreq interface is associated with the "computer" device >> object, similar to system power management interface. Since it is >> global there will be just one method call. > > OK, so based on our little q&a, things missing from the interface table: > > - DBus interface name (org.freedesktop.Hal.Device.CPUFreq?) > - DBus path of the objects that implement that interface > (/org/freedesktop/Hal/devices/computer?) > - "processor" capability for processor objects > - I think also "cpufreq_control" capability for the computer object Have updated the psarc draft with the missing interfaces. I am pasting below the additional interfaces added to the draft The processor specific properties interface Interface Type Comments --------------------------------------------------------------- info.capabilities string list value = "processor" The computer device object specific properties interface. If the property already exists, then the following values will get appended Interface Type Comments --------------------------------------------------------------- info.capabilities string list value = "cpufreq_control" info.interfaces string list value = "org.freedesktop.Hal.Device.CPUFreq" info.addons string list value = "hald-addon-cpufreq" D-Bus specific Information --------------------------- Interface Name: org.freedesktop.Hal.Device.CPUFreq Path to device object /org/freedesktop/Hal/devices/computer that implements the interface Interfaces Imported: Interface Comments ----------------------------------------------------------------------------------------------------------- PM_GET_CPU_THRESHOLD Used by GetCPUFreqPerformance to determine the frequency performance. PM_GET_SYSTEM_THRESHOLD Used by GetCPUFreqPerformance to determine the frequency performance. PM_GET_CPUPM_STATE Used by GetCPUFreqGovernor to determine the current system policy. PM_GET_PM_STATE Used by GetCPUFreqGovernor to determine the current system policy. The new draft can be found at http://sac.eng/arc/PSARC/2007/679/materials/spec.v1.txt Thanks Anup > > Could you also place a copy of hal-spec.html in the case directory, > because the one at freedesktop.org changes frequently. > > thanks, > -Artem From David.Chieu@sun.com Thu Dec 6 14:59:11 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB6MxAHu017434 for ; Thu, 6 Dec 2007 14:59:11 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB6Mx3An010607 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 Dec 2007 22:59:09 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSN00919H6L8300@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 15:59:09 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSN0036QH6KO350@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 15:59:09 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB6Mx8oG005895 for ; Thu, 06 Dec 2007 14:59:08 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSN00I01GZND400@fe-sfbay-09.sun.com> (original mail from David.Chieu@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 14:59:08 -0800 (PST) Received: from [129.153.3.97] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSN00JEPH6FBPD0@fe-sfbay-09.sun.com>; Thu, 06 Dec 2007 14:59:03 -0800 (PST) Date: Thu, 06 Dec 2007 14:59:23 -0800 From: David Chieu Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <47587DAF.9050407@sun.com> Sender: David.Chieu@sun.com To: Anup Pemmaiah , Artem Kachitchkine Cc: David Chieu , psarc-ext@sun.com, Mark.Haywood@sun.com, Phi.Tran@sun.com Message-id: <47587ECB.7040801@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> <47575285.7010505@sun.com> <47587DAF.9050407@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 3188 Artem, HAL spec is placed at: http://sac.eng/arc/PSARC/2007/679/materials/hal-spec.html as well. -- David Chieu Anup Pemmaiah wrote: > Artem Kachitchkine wrote: >> >>>> What happens when CPUs are DR removed/added ? >>> The associated device objects should get removed. >> >> Will that be achieved via DR sysevents or some other mechanism? >> >>> The CPUFreq interface is associated with the "computer" device >>> object, similar to system power management interface. Since it is >>> global there will be just one method call. >> >> OK, so based on our little q&a, things missing from the interface table: >> >> - DBus interface name (org.freedesktop.Hal.Device.CPUFreq?) >> - DBus path of the objects that implement that interface >> (/org/freedesktop/Hal/devices/computer?) >> - "processor" capability for processor objects >> - I think also "cpufreq_control" capability for the computer object > Have updated the psarc draft with the missing interfaces. I am pasting > below the additional interfaces added to the draft > > The processor specific properties interface > Interface Type Comments > --------------------------------------------------------------- > info.capabilities string list value = "processor" > > > The computer device object specific properties interface. If the > property > already exists, then the following values will get appended > > Interface Type Comments > --------------------------------------------------------------- > info.capabilities string list value = "cpufreq_control" > info.interfaces string list value = > "org.freedesktop.Hal.Device.CPUFreq" > info.addons string list value = "hald-addon-cpufreq" > D-Bus specific Information > --------------------------- > > Interface Name: org.freedesktop.Hal.Device.CPUFreq > Path to device object > /org/freedesktop/Hal/devices/computer > that implements the > interface > > Interfaces Imported: > > Interface > Comments > > ----------------------------------------------------------------------------------------------------------- > > PM_GET_CPU_THRESHOLD Used by GetCPUFreqPerformance to determine > the > frequency > performance. > PM_GET_SYSTEM_THRESHOLD Used by GetCPUFreqPerformance to > determine the > > frequency performance. > > > PM_GET_CPUPM_STATE Used by GetCPUFreqGovernor to > determine the > current > system policy. > > PM_GET_PM_STATE Used by GetCPUFreqGovernor to > determine the > current > system policy. > > > The new draft can be found at > http://sac.eng/arc/PSARC/2007/679/materials/spec.v1.txt > > Thanks > Anup >> >> Could you also place a copy of hal-spec.html in the case directory, >> because the one at freedesktop.org changes frequently. >> >> thanks, >> -Artem > From Terry.Whatley@sun.com Thu Dec 6 16:27:59 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB70Rxhh020521 for ; Thu, 6 Dec 2007 16:27:59 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lB70Rx6q059804 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 Dec 2007 17:27:59 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSN00G03LALHH00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 17:27:57 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSN003M7LAJNSA0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 17:27:55 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB70RtlI023052 for ; Thu, 06 Dec 2007 16:27:55 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSN00A01L8VOI00@fe-sfbay-10.sun.com> (original mail from Terry.Whatley@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 16:27:55 -0800 (PST) Received: from [192.168.1.100] ([67.123.136.98]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSN000JDLAIYJ40@fe-sfbay-10.sun.com>; Thu, 06 Dec 2007 16:27:55 -0800 (PST) Date: Thu, 06 Dec 2007 16:27:54 -0800 From: "Terry (Sarito) Whatley" Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <47587DAF.9050407@sun.com> Sender: Terry.Whatley@sun.com To: Anup Pemmaiah Cc: Artem Kachitchkine , psarc-ext@sun.com, Phi.Tran@sun.com, David Chieu , Mark.Haywood@sun.com Message-id: <4758938A.6010805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> <47575285.7010505@sun.com> <47587DAF.9050407@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 3917 Anup Pemmaiah wrote: > Artem Kachitchkine wrote: > >> ... >>> The CPUFreq interface is associated with the "computer" device >>> object, similar to system power management interface. Since it is >>> global there will be just one method call. >>> >> OK, so based on our little q&a, things missing from the interface table: >> >> - DBus interface name (org.freedesktop.Hal.Device.CPUFreq?) >> - DBus path of the objects that implement that interface >> (/org/freedesktop/Hal/devices/computer?) >> - "processor" capability for processor objects >> - I think also "cpufreq_control" capability for the computer object >> > Have updated the psarc draft with the missing interfaces. I am pasting > below the additional interfaces added to the draft > > The processor specific properties interface > Interface Type Comments > --------------------------------------------------------------- > info.capabilities string list value = "processor" > > > The computer device object specific properties interface. If the > property > already exists, then the following values will get appended > > Interface Type Comments > --------------------------------------------------------------- > info.capabilities string list value = "cpufreq_control" > info.interfaces string list value = > "org.freedesktop.Hal.Device.CPUFreq" > info.addons string list value = "hald-addon-cpufreq" > > D-Bus specific Information > --------------------------- > > Interface Name: org.freedesktop.Hal.Device.CPUFreq > > Path to device object /org/freedesktop/Hal/devices/computer > that implements the > interface > > Interfaces Imported: > > Interface > Comments As per PSARC 20005/267, the pm ioctls below are undocumented, consolidation private interfaces. The current case proposes to use /etc/power.conf and pmconfig (both documented and committed interfaces) to control the policy. Since they already have to parse /etc/power.conf to do this, it makes no sense to bypass /etc/power.conf (via the ioctls listed below) when attempting to determine what the current pm state is. It would be better to parse the power.conf file to get this information, since it contains the necessary information in a stable format (though one that needs more decoding). Note that to do what is proposed below would also require adding a line to the diagram in the case materials that bypasses power.conf and pmconfig to go directly to the kernel layer ioctl interface. thanks, Terry (Sarito) Whatley > > ----------------------------------------------------------------------------------------------------------- > PM_GET_CPU_THRESHOLD Used by GetCPUFreqPerformance to determine the > frequency > performance. > > PM_GET_SYSTEM_THRESHOLD Used by GetCPUFreqPerformance to > determine the > > frequency performance. > > > PM_GET_CPUPM_STATE Used by GetCPUFreqGovernor to determine > the > current > system policy. > > PM_GET_PM_STATE Used by GetCPUFreqGovernor to > determine the > current > system policy. > > > The new draft can be found at > http://sac.eng/arc/PSARC/2007/679/materials/spec.v1.txt > > Thanks > Anup > >> Could you also place a copy of hal-spec.html in the case directory, >> because the one at freedesktop.org changes frequently. >> >> thanks, >> -Artem >> > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > From Mark.Haywood@sun.com Thu Dec 6 16:56:20 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB70uJe2020991 for ; Thu, 6 Dec 2007 16:56:20 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB70uCmm011476 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 7 Dec 2007 00:56:18 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSN00F11MLQ1H00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 16:56:14 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSN00EHMMLPHY00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 16:56:14 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB70uDBP020050 for ; Fri, 07 Dec 2007 00:56:13 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSN00D01MLL8X00@mail-amer.sun.com> (original mail from Mark.Haywood@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 17:56:13 -0700 (MST) Received: from [129.148.19.14] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSN008XYMLKDH10@mail-amer.sun.com>; Thu, 06 Dec 2007 17:56:13 -0700 (MST) Date: Thu, 06 Dec 2007 19:54:29 -0500 From: Mark Haywood Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <4758938A.6010805@sun.com> Sender: Mark.Haywood@sun.com To: "Terry (Sarito) Whatley" Cc: Anup Pemmaiah , Artem Kachitchkine , psarc-ext@sun.com, Phi.Tran@sun.com, David Chieu Message-id: <475899C5.4060805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> <47575285.7010505@sun.com> <47587DAF.9050407@sun.com> <4758938A.6010805@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060828) Status: RO Content-Length: 4477 Terry (Sarito) Whatley wrote: > Anup Pemmaiah wrote: >> Artem Kachitchkine wrote: >> >>> ... >>>> The CPUFreq interface is associated with the "computer" device >>>> object, similar to system power management interface. Since it is >>>> global there will be just one method call. >>>> >>> OK, so based on our little q&a, things missing from the interface table: >>> >>> - DBus interface name (org.freedesktop.Hal.Device.CPUFreq?) >>> - DBus path of the objects that implement that interface >>> (/org/freedesktop/Hal/devices/computer?) >>> - "processor" capability for processor objects >>> - I think also "cpufreq_control" capability for the computer object >>> >> Have updated the psarc draft with the missing interfaces. I am pasting >> below the additional interfaces added to the draft >> >> The processor specific properties interface >> Interface Type Comments >> --------------------------------------------------------------- >> info.capabilities string list value = "processor" >> >> >> The computer device object specific properties interface. If the >> property >> already exists, then the following values will get appended >> >> Interface Type Comments >> --------------------------------------------------------------- >> info.capabilities string list value = "cpufreq_control" >> info.interfaces string list value = >> "org.freedesktop.Hal.Device.CPUFreq" >> info.addons string list value = "hald-addon-cpufreq" >> D-Bus specific Information >> --------------------------- >> >> Interface Name: org.freedesktop.Hal.Device.CPUFreq >> Path to device object >> /org/freedesktop/Hal/devices/computer >> that implements the >> interface >> >> Interfaces Imported: >> >> >> Interface >> Comments > As per PSARC 20005/267, the pm ioctls below are undocumented, > consolidation private interfaces. > The current case proposes to use /etc/power.conf and pmconfig (both > documented and committed interfaces) > to control the policy. Since they already have to parse /etc/power.conf > to do this, it makes no > sense to bypass /etc/power.conf (via the ioctls listed below) when > attempting to determine what the current > pm state is. It would be better to parse the power.conf file to get > this information, since it > contains the necessary information in a stable format (though one that > needs more decoding). > Note that to do what is proposed below would also require adding a line > to the diagram > in the case materials that bypasses power.conf and pmconfig to go > directly to the kernel layer ioctl > interface. No, I don't think that it will be sufficient to use the power.conf file to get the information since the power.conf file does not necessarily represent the current state of the system. The only way to know how the system is currently configured it to ask the framework. Since the HAL code resides in the ON consolidation I see no issue with it using the consolidation private interfaces? > > thanks, > Terry (Sarito) Whatley > >> >> ----------------------------------------------------------------------------------------------------------- >> >> PM_GET_CPU_THRESHOLD Used by GetCPUFreqPerformance to >> determine the >> >> frequency performance. >> PM_GET_SYSTEM_THRESHOLD Used by GetCPUFreqPerformance to >> determine the >> >> frequency performance. >> >> >> PM_GET_CPUPM_STATE Used by GetCPUFreqGovernor to >> determine the >> current >> system policy. >> >> PM_GET_PM_STATE Used by GetCPUFreqGovernor to >> determine the >> current >> system policy. >> >> >> The new draft can be found at >> http://sac.eng/arc/PSARC/2007/679/materials/spec.v1.txt >> >> Thanks >> Anup >> >>> Could you also place a copy of hal-spec.html in the case directory, >>> because the one at freedesktop.org changes frequently. >>> >>> thanks, >>> -Artem >>> >> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org >> > From Terry.Whatley@sun.com Thu Dec 6 17:26:59 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB71Qx6Y021144 for ; Thu, 6 Dec 2007 17:26:59 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lB71QwLf001691 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 Dec 2007 17:26:59 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSN00H0NO0YFK00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 17:26:58 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSN00LTJO0XX9A0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 17:26:57 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB71QuIk028479 for ; Thu, 06 Dec 2007 17:26:57 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSN00E01NZ0QE00@fe-sfbay-09.sun.com> (original mail from Terry.Whatley@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 17:26:56 -0800 (PST) Received: from [192.168.1.100] ([67.123.136.98]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSN0004IO0WB060@fe-sfbay-09.sun.com>; Thu, 06 Dec 2007 17:26:56 -0800 (PST) Date: Thu, 06 Dec 2007 17:26:55 -0800 From: "Terry (Sarito) Whatley" Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <475899C5.4060805@sun.com> Sender: Terry.Whatley@sun.com To: Mark Haywood Cc: Anup Pemmaiah , Artem Kachitchkine , psarc-ext@sun.com, Phi.Tran@sun.com, David Chieu Message-id: <4758A15F.6080401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> <47575285.7010505@sun.com> <47587DAF.9050407@sun.com> <4758938A.6010805@sun.com> <475899C5.4060805@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 5769 Mark Haywood wrote: > Terry (Sarito) Whatley wrote: >> Anup Pemmaiah wrote: >>> Artem Kachitchkine wrote: >>> >>>> ... >>>>> The CPUFreq interface is associated with the "computer" device >>>>> object, similar to system power management interface. Since it is >>>>> global there will be just one method call. >>>>> >>>> OK, so based on our little q&a, things missing from the interface >>>> table: >>>> >>>> - DBus interface name (org.freedesktop.Hal.Device.CPUFreq?) >>>> - DBus path of the objects that implement that interface >>>> (/org/freedesktop/Hal/devices/computer?) >>>> - "processor" capability for processor objects >>>> - I think also "cpufreq_control" capability for the computer object >>>> >>> Have updated the psarc draft with the missing interfaces. I am >>> pasting below the additional interfaces added to the draft >>> >>> The processor specific properties interface >>> Interface Type Comments >>> --------------------------------------------------------------- >>> info.capabilities string list value = "processor" >>> >>> >>> The computer device object specific properties interface. If the >>> property >>> already exists, then the following values will get appended >>> >>> Interface Type Comments >>> --------------------------------------------------------------- >>> info.capabilities string list value = "cpufreq_control" >>> info.interfaces string list value = >>> "org.freedesktop.Hal.Device.CPUFreq" >>> info.addons string list value = "hald-addon-cpufreq" >>> D-Bus specific Information >>> --------------------------- >>> >>> Interface Name: org.freedesktop.Hal.Device.CPUFreq >>> Path to device object >>> /org/freedesktop/Hal/devices/computer >>> that implements the >>> interface >>> >>> Interfaces Imported: >>> >>> >>> Interface >>> Comments >> As per PSARC 20005/267, the pm ioctls below are undocumented, >> consolidation private interfaces. >> The current case proposes to use /etc/power.conf and pmconfig (both >> documented and committed interfaces) >> to control the policy. Since they already have to parse >> /etc/power.conf to do this, it makes no >> sense to bypass /etc/power.conf (via the ioctls listed below) when >> attempting to determine what the current >> pm state is. It would be better to parse the power.conf file to get >> this information, since it >> contains the necessary information in a stable format (though one >> that needs more decoding). >> Note that to do what is proposed below would also require adding a >> line to the diagram >> in the case materials that bypasses power.conf and pmconfig to go >> directly to the kernel layer ioctl >> interface. > > No, I don't think that it will be sufficient to use the power.conf > file to get the information since the power.conf file does not > necessarily represent the current state of the system. By what mechanism do you imagine that the power.conf file gets out of sync with the system state? The only one I know is that somebody edited power.conf and didn't run pmconfig. As soon as pmconfig is run, that difference will be erased, so it is transient at best. (The other, of course, is that somebody has written a program that is messing with the state via the ioctls, but if that is the case both you and them are doomed anyhow). > The only way to know how the system is currently configured it to ask > the framework. If you are going to control policy by editing power.conf and doing a pmconfig, at the point that you do the pmconfig the power.conf content and system state will become identical (that is pmconfig's job). Since you plan to blow away any difference anyhow, you might as well just start with doing a pmconfig, and then use the power.conf file content to indicate the state. (Or you could say that if the user edits power.conf and doesn't do a pmconfig then the behavior is undefined). > Since the HAL code resides in the ON consolidation I see no issue with > it using the consolidation private interfaces? It seems to me one ought to use the most stable and documented interfaces available, given that the code has to do the same inferences either way. But I don't get to vote, I'm only a licensee :-). -sarito >> >> thanks, >> Terry (Sarito) Whatley >> >>> >>> ----------------------------------------------------------------------------------------------------------- >>> >>> PM_GET_CPU_THRESHOLD Used by GetCPUFreqPerformance to >>> determine the >>> >>> frequency performance. >>> PM_GET_SYSTEM_THRESHOLD Used by GetCPUFreqPerformance to >>> determine the >>> >>> frequency performance. >>> >>> >>> PM_GET_CPUPM_STATE Used by GetCPUFreqGovernor to >>> determine the >>> current >>> system policy. >>> >>> PM_GET_PM_STATE Used by GetCPUFreqGovernor to >>> determine the >>> current >>> system policy. >>> >>> >>> The new draft can be found at >>> http://sac.eng/arc/PSARC/2007/679/materials/spec.v1.txt >>> >>> Thanks >>> Anup >>> >>>> Could you also place a copy of hal-spec.html in the case directory, >>>> because the one at freedesktop.org changes frequently. >>>> >>>> thanks, >>>> -Artem >>>> >>> >>> _______________________________________________ >>> opensolaris-arc mailing list >>> opensolaris-arc@opensolaris.org >>> >> > From Mark.Haywood@sun.com Thu Dec 6 18:19:47 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB72JkCa022931 for ; Thu, 6 Dec 2007 18:19:46 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB72JbE6020036 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 7 Dec 2007 02:19:45 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSN0050FQGV9Z00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 18:19:43 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSN00LIIQGUX2C0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 18:19:43 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB72Jg3k023048 for ; Fri, 07 Dec 2007 02:19:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSN00I01Q7DWJ00@mail-amer.sun.com> (original mail from Mark.Haywood@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Dec 2007 19:19:42 -0700 (MST) Received: from [129.148.19.14] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSN003HFQGT9Z70@mail-amer.sun.com>; Thu, 06 Dec 2007 19:19:42 -0700 (MST) Date: Thu, 06 Dec 2007 21:18:03 -0500 From: Mark Haywood Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <4758A15F.6080401@sun.com> Sender: Mark.Haywood@sun.com To: "Terry (Sarito) Whatley" Cc: Anup Pemmaiah , Artem Kachitchkine , psarc-ext@sun.com, Phi.Tran@sun.com, David Chieu Message-id: <4758AD5B.4000500@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> <47575285.7010505@sun.com> <47587DAF.9050407@sun.com> <4758938A.6010805@sun.com> <475899C5.4060805@sun.com> <4758A15F.6080401@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060828) Status: RO Content-Length: 7220 Terry (Sarito) Whatley wrote: > Mark Haywood wrote: >> Terry (Sarito) Whatley wrote: >>> Anup Pemmaiah wrote: >>>> Artem Kachitchkine wrote: >>>> >>>>> ... >>>>>> The CPUFreq interface is associated with the "computer" device >>>>>> object, similar to system power management interface. Since it is >>>>>> global there will be just one method call. >>>>>> >>>>> OK, so based on our little q&a, things missing from the interface >>>>> table: >>>>> >>>>> - DBus interface name (org.freedesktop.Hal.Device.CPUFreq?) >>>>> - DBus path of the objects that implement that interface >>>>> (/org/freedesktop/Hal/devices/computer?) >>>>> - "processor" capability for processor objects >>>>> - I think also "cpufreq_control" capability for the computer object >>>>> >>>> Have updated the psarc draft with the missing interfaces. I am >>>> pasting below the additional interfaces added to the draft >>>> >>>> The processor specific properties interface >>>> Interface Type Comments >>>> --------------------------------------------------------------- >>>> info.capabilities string list value = "processor" >>>> >>>> >>>> The computer device object specific properties interface. If the >>>> property >>>> already exists, then the following values will get appended >>>> >>>> Interface Type Comments >>>> --------------------------------------------------------------- >>>> info.capabilities string list value = "cpufreq_control" >>>> info.interfaces string list value = >>>> "org.freedesktop.Hal.Device.CPUFreq" >>>> info.addons string list value = "hald-addon-cpufreq" >>>> D-Bus specific Information >>>> --------------------------- >>>> >>>> Interface Name: org.freedesktop.Hal.Device.CPUFreq >>>> Path to device object >>>> /org/freedesktop/Hal/devices/computer >>>> that implements the >>>> interface >>>> >>>> Interfaces Imported: >>>> >>>> >>>> Interface >>>> Comments >>> As per PSARC 20005/267, the pm ioctls below are undocumented, >>> consolidation private interfaces. >>> The current case proposes to use /etc/power.conf and pmconfig (both >>> documented and committed interfaces) >>> to control the policy. Since they already have to parse >>> /etc/power.conf to do this, it makes no >>> sense to bypass /etc/power.conf (via the ioctls listed below) when >>> attempting to determine what the current >>> pm state is. It would be better to parse the power.conf file to get >>> this information, since it >>> contains the necessary information in a stable format (though one >>> that needs more decoding). >>> Note that to do what is proposed below would also require adding a >>> line to the diagram >>> in the case materials that bypasses power.conf and pmconfig to go >>> directly to the kernel layer ioctl >>> interface. >> >> No, I don't think that it will be sufficient to use the power.conf >> file to get the information since the power.conf file does not >> necessarily represent the current state of the system. > By what mechanism do you imagine that the power.conf file gets out of > sync with the system state? > The only one I know is that somebody edited power.conf and didn't run > pmconfig. > As soon as pmconfig is run, that difference will be erased, so it is > transient at best. > (The other, of course, is that somebody has written a program that is > messing with > the state via the ioctls, but if that is the case both you and them are > doomed anyhow). What you say is entirely true, but this problem is not new. dtpower had the same problem - display the active system policy or display the one currently defined by power.conf. dtpower chose to go the former route (using the PM ioctls). Admittedly, dtpower had the ability to pop up a warning to the user if the system policy and power.conf were out of sync. >> The only way to know how the system is currently configured it to ask >> the framework. > If you are going to control policy by editing power.conf and doing a > pmconfig, at the point that you > do the pmconfig the power.conf content and system state will become > identical (that is pmconfig's job). > Since you plan to blow away any difference anyhow, you might as well > just start with doing a pmconfig, > and then use the power.conf file content to indicate the state. (Or you > could say that if the user edits > power.conf and doesn't do a pmconfig then the behavior is undefined). GPM/HAL executing pmconfig when it is invoked would be really poor behavior. No change should be made to the policy unless the user requests a change. I believe that your last suggestion is the right behavior. If the current system policy and the power.conf contents are not in sync then HAL should consider the current policy as undefined. I believe HAL will have to use the PM ioctls to determine if the system policy and power.conf are telling the same story. >> Since the HAL code resides in the ON consolidation I see no issue with >> it using the consolidation private interfaces? > It seems to me one ought to use the most stable and documented > interfaces available, > given that the code has to do the same inferences either way. But I > don't get to vote, > I'm only a licensee :-). And if the interfaces that you suggest we use were sufficient, I'd agree with you. Since they are not, I think it is reasonable that we use the consolidation private interfaces that were made available by PSARC/2005/067. Of course, I don't get to vote either. If there is a reason that you feel the PM ioctls are likely to change, then we should discuss it before this case proceeds any further. Mark > -sarito >>> >>> thanks, >>> Terry (Sarito) Whatley >>> >>>> >>>> ----------------------------------------------------------------------------------------------------------- >>>> >>>> PM_GET_CPU_THRESHOLD Used by GetCPUFreqPerformance to >>>> determine the >>>> >>>> frequency performance. >>>> PM_GET_SYSTEM_THRESHOLD Used by GetCPUFreqPerformance to >>>> determine the >>>> >>>> frequency performance. >>>> >>>> >>>> PM_GET_CPUPM_STATE Used by GetCPUFreqGovernor to >>>> determine the >>>> current >>>> system policy. >>>> >>>> PM_GET_PM_STATE Used by GetCPUFreqGovernor to >>>> determine the >>>> current >>>> system policy. >>>> >>>> >>>> The new draft can be found at >>>> http://sac.eng/arc/PSARC/2007/679/materials/spec.v1.txt >>>> >>>> Thanks >>>> Anup >>>> >>>>> Could you also place a copy of hal-spec.html in the case directory, >>>>> because the one at freedesktop.org changes frequently. >>>>> >>>>> thanks, >>>>> -Artem >>>>> >>>> >>>> _______________________________________________ >>>> opensolaris-arc mailing list >>>> opensolaris-arc@opensolaris.org >>>> >>> >> > From Darren.Moffat@sun.com Fri Dec 7 03:31:28 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB7BVSGY029360 for ; Fri, 7 Dec 2007 03:31:28 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lB7BVOlN016383 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 7 Dec 2007 03:31:27 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSO00I1TG0F4N00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 07 Dec 2007 03:31:27 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSO004E4G0D6I80@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 07 Dec 2007 03:31:26 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB7BVPlG011625 for ; Fri, 07 Dec 2007 11:31:25 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSO00B01FXMGZ00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 07 Dec 2007 11:31:25 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSO00G9NG06BO10@fe-emea-10.sun.com>; Fri, 07 Dec 2007 11:31:19 +0000 (GMT) Date: Fri, 07 Dec 2007 11:31:18 +0000 From: Darren J Moffat Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <4758938A.6010805@sun.com> Sender: Darren.Moffat@sun.com To: "Terry (Sarito) Whatley" Cc: Anup Pemmaiah , psarc-ext@sun.com, Artem Kachitchkine , Mark.Haywood@sun.com, David Chieu , Phi.Tran@sun.com Message-id: <47592F06.8060102@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> <47575285.7010505@sun.com> <47587DAF.9050407@sun.com> <4758938A.6010805@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071105) Status: RO Content-Length: 1298 Terry (Sarito) Whatley wrote: > As per PSARC 20005/267, the pm ioctls below are undocumented, > consolidation private interfaces. > The current case proposes to use /etc/power.conf and pmconfig (both > documented and committed interfaces) > to control the policy. Since they already have to parse /etc/power.conf > to do this, it makes no > sense to bypass /etc/power.conf (via the ioctls listed below) when > attempting to determine what the current > pm state is. It would be better to parse the power.conf file to get > this information, since it > contains the necessary information in a stable format (though one that > needs more decoding). I very strongly disagree. /etc/power.conf does NOT reflect the current power state it reflects the intended policy not what the machine is actually running. If /etc/power.conf had been updated but pmconfig had not been run then there could be a difference between what reading /etc/power.conf gives you and what using the ioctl to query the kernel directly gives you. We made a similar mistake with cryptoadm and the /etc/crypto/kcf.conf where both the ioctl and config file were private and it only caused us pain and problems with zones and resulted in use always asking the kernel for the current state. -- Darren J Moffat From David.Chieu@sun.com Tue Dec 11 02:21:30 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBBALTDF027619 for ; Tue, 11 Dec 2007 02:21:29 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBBALOLv000260 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 11 Dec 2007 10:21:28 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSV00301RFQD000@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Dec 2007 02:21:26 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSV000D8RFPZ570@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Dec 2007 02:21:25 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBBALPeX021071 for ; Tue, 11 Dec 2007 02:21:25 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSV00701R8SEL00@fe-sfbay-10.sun.com> (original mail from David.Chieu@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Dec 2007 02:21:25 -0800 (PST) Received: from [192.168.1.102] ([76.170.66.246]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSV008HFRFJ3300@fe-sfbay-10.sun.com>; Tue, 11 Dec 2007 02:21:25 -0800 (PST) Date: Tue, 11 Dec 2007 02:21:20 -0800 From: David Chieu Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <4758AD5B.4000500@sun.com> Sender: David.Chieu@sun.com To: Mark Haywood Cc: "Terry (Sarito) Whatley" , Anup Pemmaiah , Artem Kachitchkine , psarc-ext@sun.com, Phi.Tran@sun.com, David Chieu Message-id: <475E64A0.1040704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200712051850.lB5IosEY009933@sac.sfbay.sun.com> <4756FB49.5050906@sun.com> <4757051A.3090008@sun.com> <475706F8.5090700@sun.com> <47574C68.2050809@sun.com> <47575285.7010505@sun.com> <47587DAF.9050407@sun.com> <4758938A.6010805@sun.com> <475899C5.4060805@sun.com> <4758A15F.6080401@sun.com> <4758AD5B.4000500@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 Status: RO Content-Length: 1132 Mark Haywood wrote: > ... > >>> Since the HAL code resides in the ON consolidation I see no issue >>> with it using the consolidation private interfaces? >> >> It seems to me one ought to use the most stable and documented >> interfaces available, >> given that the code has to do the same inferences either way. But I >> don't get to vote, >> I'm only a licensee :-). > > > And if the interfaces that you suggest we use were sufficient, I'd > agree with you. Since they are not, I think it is reasonable that we > use the consolidation private interfaces that were made available by > PSARC/2005/067. Of course, I don't get to vote either. > > If there is a reason that you feel the PM ioctls are likely to change, > then we should discuss it before this case proceeds any further. > > Mark For the record, the project team agrees that PM ioctls are "consolidation private" as they are consistent with PSARC 2005/067. Additionally, HAL interfaces defined by this project are "volatile" they are consistent with PSARC 2005/399. Please ignore previously proposed "committed" level as it was incorrect. -- David Chieu From gww@eng.sun.com Tue Dec 11 13:16:16 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBBLGGsi014916 for ; Tue, 11 Dec 2007 13:16:16 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBBLGGQn003925 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 11 Dec 2007 13:16:16 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSW00103LR45U00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Dec 2007 14:16:16 -0700 (MST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSW00AEPLR37TD0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Dec 2007 14:16:15 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id lBBLGEfw018278; Tue, 11 Dec 2007 13:16:14 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lBBLEQDV016149; Tue, 11 Dec 2007 13:14:26 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lBBLEQ5X016148; Tue, 11 Dec 2007 13:14:26 -0800 (PST) Date: Tue, 11 Dec 2007 13:14:26 -0800 (PST) From: Gary Winiger Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] To: Artem.Kachitchkin@sun.com, Napanda.Pemmaiah@sun.com Cc: Mark.Haywood@sun.com, Phi.Tran@sun.com, dchieu@sac.sfbay.sun.com, psarc-ext@sun.com Message-id: <200712112114.lBBLEQ5X016148@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 230 > The new draft can be found at > http://sac.eng/arc/PSARC/2007/679/materials/spec.v1.txt What is the access control model? How does it fit with Solaris Authorizations? How are changes audited? Who can make changes? Gary.. From David.Chieu@sun.com Tue Dec 11 23:49:59 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBC7nxfS027436 for ; Tue, 11 Dec 2007 23:49:59 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBC7nx4B000483 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 11 Dec 2007 23:49:59 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSX00501F3AMN00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Dec 2007 00:49:58 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSX007D4F33LG70@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Dec 2007 00:49:51 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBC7npIl007051 for ; Tue, 11 Dec 2007 23:49:51 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSX00601EXXK500@fe-sfbay-09.sun.com> (original mail from David.Chieu@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Dec 2007 23:49:51 -0800 (PST) Received: from [192.168.1.102] ([76.170.66.246]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSX000ZMF325M20@fe-sfbay-09.sun.com>; Tue, 11 Dec 2007 23:49:51 -0800 (PST) Date: Tue, 11 Dec 2007 23:49:51 -0800 From: David Chieu Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <200712112114.lBBLEQ5X016148@marduk.eng.sun.com> Sender: David.Chieu@sun.com To: Gary Winiger Cc: Artem.Kachitchkin@sun.com, Napanda.Pemmaiah@sun.com, Mark.Haywood@sun.com, Phi.Tran@sun.com, dchieu@sac.sfbay.sun.com, psarc-ext@sun.com Message-id: <475F929F.2080500@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200712112114.lBBLEQ5X016148@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 Status: RO Content-Length: 625 Gary Winiger wrote: >>The new draft can be found at >>http://sac.eng/arc/PSARC/2007/679/materials/spec.v1.txt >> >> > > What is the access control model? How does it fit with > Solaris Authorizations? How are changes audited? > Who can make changes? > >Gary.. > > Gary, I've just read your preview on "Defining Workstation Owner Infrastructure" proposal. This project fits as one of your consumers on your proposed addition of key=value, "WORKSTATION_OWNER=" to policy.conf(4). We would like to leverage your work to use "workstation owner" to shape and populate the CPUFreq HAL Rights Profile. -- David Chieu From Napanda.Pemmaiah@sun.com Tue Dec 18 15:47:07 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBINl7nb006344 for ; Tue, 18 Dec 2007 15:47:07 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBINl6oB026464 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 18 Dec 2007 15:47:07 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT900F03REJGK00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Dec 2007 15:47:07 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT900L1ZREGDM60@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Dec 2007 15:47:04 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBINl4cm025621 for ; Tue, 18 Dec 2007 15:47:04 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT900H01R7L4H00@fe-sfbay-09.sun.com> (original mail from Napanda.Pemmaiah@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Dec 2007 15:47:04 -0800 (PST) Received: from [129.146.106.209] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT900IHMRE5AK20@fe-sfbay-09.sun.com>; Tue, 18 Dec 2007 15:46:53 -0800 (PST) Date: Tue, 18 Dec 2007 15:46:53 -0800 From: Anup Pemmaiah Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <200712112114.lBBLEQ5X016148@marduk.eng.sun.com> Sender: Napanda.Pemmaiah@sun.com To: Gary Winiger Cc: Artem.Kachitchkin@sun.com, Mark.Haywood@sun.com, Phi.Tran@sun.com, dchieu@sac.sfbay.sun.com, psarc-ext@sun.com Message-id: <47685BED.6000105@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712112114.lBBLEQ5X016148@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1000 Gary Winiger wrote: >> The new draft can be found at >> http://sac.eng/arc/PSARC/2007/679/materials/spec.v1.txt >> > > What is the access control model? How does it fit with > Solaris Authorizations? How are changes audited? > Who can make changes? > > Gary.. > Gary, Will have the following authorization model. Whenever the "set" method interfaces are invoked, it checks if the user has the required authorization to perform the operation. Authorization name with its entry in /etc/security/auth_attr -------------------------------------------------------------- solaris.powermanagement.:::Power Management::help=PowerMgmt.html solaris.powermanagement.halcpufreq::: Manage HAL CPU frequency methods::help=HalCpuFreq.html Profile for HAL CPU Freq in /etc/security/prof_attr ----------------------------------------------------- HAL CPUFreq:::For workstation owners to interact with HAL CPU Freq:auths=solaris.powermanagement.halcpufreq;help=RtHALCPUFreqMngmnt.html Thanks Anup From gww@eng.sun.com Tue Dec 18 17:06:46 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJ16k1V008473 for ; Tue, 18 Dec 2007 17:06:46 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBJ16jlm026679 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 18 Dec 2007 17:06:46 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT900L0BV39R500@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Dec 2007 17:06:45 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT900AWKV38G8B0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Dec 2007 17:06:44 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBJ16iB0014124; Tue, 18 Dec 2007 17:06:44 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lBJ14lHL025507; Tue, 18 Dec 2007 17:04:47 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lBJ14lgW025506; Tue, 18 Dec 2007 17:04:47 -0800 (PST) Date: Tue, 18 Dec 2007 17:04:47 -0800 (PST) From: Gary Winiger Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] To: gww@eng.sun.com, Napanda.Pemmaiah@sun.com Cc: Artem.Kachitchkin@sun.com, Mark.Haywood@sun.com, Phi.Tran@sun.com, dchieu@sac.sfbay.sun.com, psarc-ext@sun.com Message-id: <200712190104.lBJ14lgW025506@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1629 Anup, > > What is the access control model? How does it fit with > > Solaris Authorizations? How are changes audited? > > Who can make changes? > > > > Gary.. > > > Gary, > > Will have the following authorization model. Whenever the "set" method > interfaces are invoked, it checks if the user has the required > authorization to perform the operation. > > Authorization name with its entry in /etc/security/auth_attr > -------------------------------------------------------------- > solaris.powermanagement.:::Power Management::help=PowerMgmt.html > solaris.powermanagement.halcpufreq::: Manage HAL CPU frequency > methods::help=HalCpuFreq.html > > Profile for HAL CPU Freq in /etc/security/prof_attr > ----------------------------------------------------- > HAL CPUFreq:::For workstation owners to interact with HAL CPU > Freq:auths=solaris.powermanagement.halcpufreq;help=RtHALCPUFreqMngmnt.html Hummm, I understand that hald is the mechanism for enforcing the authorization, however I wouldn't expect it to be part of the authorization name. I'd more expect the authorization name to represent the functionality being authorized within the powermanagement authorization hierarchy. Additionally, I'd expect to see mention of how this project will audit. It doesn't appear that any of the present set of audit records that hald produces is appropriate for setting cpu power consumption. The project team needs to commit to work with the Audit project team to correctly implement audit for these new events. That needs to be putback at the same time as the other parts of the project. Gary.. From Artem.Kachitchkin@sun.com Tue Dec 18 17:31:07 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJ1V64X008821 for ; Tue, 18 Dec 2007 17:31:06 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBJ1Ur5o011917 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 19 Dec 2007 09:31:05 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT90070PW7QUA00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Dec 2007 17:31:02 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT900LDWW7QDE90@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Dec 2007 17:31:02 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBJ1V1fe005960 for ; Tue, 18 Dec 2007 17:31:01 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT900B01W74NW00@fe-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Dec 2007 17:31:01 -0800 (PST) Received: from [192.168.1.100] ([75.6.225.50]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT900LMKW7PQP90@fe-sfbay-10.sun.com>; Tue, 18 Dec 2007 17:31:01 -0800 (PST) Date: Tue, 18 Dec 2007 17:29:22 -0800 From: Artem Kachitchkine Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <200712190104.lBJ14lgW025506@marduk.eng.sun.com> Sender: Artem.Kachitchkin@sun.com To: Gary Winiger Cc: Napanda.Pemmaiah@sun.com, Mark.Haywood@sun.com, Phi.Tran@sun.com, dchieu@sac.sfbay.sun.com, psarc-ext@sun.com Message-id: <476873F2.4090409@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712190104.lBJ14lgW025506@marduk.eng.sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 382 > Hummm, I understand that hald is the mechanism for enforcing the > authorization, however I wouldn't expect it to be part of the > authorization name. I'd more expect the authorization name to > represent the functionality being authorized within the powermanagement > authorization hierarchy. +1. I was going to say pretty much the same, only less articulately. -Artem From Napanda.Pemmaiah@sun.com Tue Dec 18 22:39:15 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJ6dENg013755 for ; Tue, 18 Dec 2007 22:39:14 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBJ6crqZ010654 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 19 Dec 2007 06:39:13 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTA00F07AH74400@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Dec 2007 22:39:07 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTA0075JAH6I480@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Dec 2007 22:39:06 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBJ6d6CC018591 for ; Tue, 18 Dec 2007 22:39:06 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTA00K01AFX4X00@fe-sfbay-09.sun.com> (original mail from Napanda.Pemmaiah@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 18 Dec 2007 22:39:06 -0800 (PST) Received: from [129.150.16.134] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTA0021GAH5BL90@fe-sfbay-09.sun.com>; Tue, 18 Dec 2007 22:39:06 -0800 (PST) Date: Tue, 18 Dec 2007 22:39:05 -0800 From: Anup Pemmaiah Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <200712190104.lBJ14lgW025506@marduk.eng.sun.com> Sender: Napanda.Pemmaiah@sun.com To: Gary Winiger Cc: Artem.Kachitchkin@sun.com, Mark.Haywood@sun.com, Phi.Tran@sun.com, dchieu@sac.sfbay.sun.com, PSARC-ext@sun.com Message-id: <4768BC89.2080007@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712190104.lBJ14lgW025506@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20071031) Status: RO Content-Length: 2106 Gary Winiger wrote: > Anup, > > >>> What is the access control model? How does it fit with >>> Solaris Authorizations? How are changes audited? >>> Who can make changes? >>> >>> Gary.. >>> >>> >> Gary, >> >> Will have the following authorization model. Whenever the "set" method >> interfaces are invoked, it checks if the user has the required >> authorization to perform the operation. >> >> Authorization name with its entry in /etc/security/auth_attr >> -------------------------------------------------------------- >> solaris.powermanagement.:::Power Management::help=PowerMgmt.html >> solaris.powermanagement.halcpufreq::: Manage HAL CPU frequency >> methods::help=HalCpuFreq.html >> >> Profile for HAL CPU Freq in /etc/security/prof_attr >> ----------------------------------------------------- >> HAL CPUFreq:::For workstation owners to interact with HAL CPU >> Freq:auths=solaris.powermanagement.halcpufreq;help=RtHALCPUFreqMngmnt.html >> > > Hummm, I understand that hald is the mechanism for enforcing the > authorization, however I wouldn't expect it to be part of the > authorization name. I'd more expect the authorization name to > represent the functionality being authorized within the powermanagement > authorization hierarchy. > > Will replace the authorization name "solaris.powermanagement.halcpufreq" to "solaris.powermanagement.cpupm", so that it represents the cpu power management. > Additionally, I'd expect to see mention of how this project will > audit. It doesn't appear that any of the present set of audit records > that hald produces is appropriate for setting cpu power consumption. > > Will provide audit events in the SetCPUFreqGovernor and SetCPUPerformance methods that provides HAL CPUFreq specific audit records. Will work with the audit project team to insert correct auditing. Thanks Anup > The project team needs to commit to work with the Audit project team > to correctly implement audit for these new events. That needs to be > putback at the same time as the other parts of the project. > > Gary.. > From Darren.Moffat@sun.com Wed Dec 19 03:11:44 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJBBhb2020458 for ; Wed, 19 Dec 2007 03:11:43 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBJBBgS9020915 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 Dec 2007 11:11:42 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTA0040NN3HZN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Dec 2007 03:11:41 -0800 (PST) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTA00MD6N3FYJ60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Dec 2007 03:11:40 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBJBBcmM029198 for ; Wed, 19 Dec 2007 11:11:38 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTA00H01MPVZK00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Dec 2007 11:11:38 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTA007ABN3BBQ10@fe-emea-10.sun.com>; Wed, 19 Dec 2007 11:11:35 +0000 (GMT) Date: Wed, 19 Dec 2007 11:11:34 +0000 From: Darren J Moffat Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <4768BC89.2080007@sun.com> Sender: Darren.Moffat@sun.com To: Anup Pemmaiah Cc: Gary Winiger , Phi.Tran@sun.com, Artem.Kachitchkin@sun.com, PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, Mark.Haywood@sun.com Message-id: <4768FC66.7030308@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712190104.lBJ14lgW025506@marduk.eng.sun.com> <4768BC89.2080007@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 221 In addition to what Gary has said about the auth names I don't think a new top level node in the auth hierarchy is needed here. I would have expected it see something like: solaris.system.power.cpu. -- Darren J Moffat From gww@eng.sun.com Wed Dec 19 08:01:04 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJG14eI024217 for ; Wed, 19 Dec 2007 08:01:04 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBJG11nn021534 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 Dec 2007 08:01:03 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB00H1L0HO2M00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Dec 2007 08:01:00 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB00CEE0HMOXD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Dec 2007 08:00:58 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBJG0uPX059722; Wed, 19 Dec 2007 08:00:56 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lBJFx0Ws026050; Wed, 19 Dec 2007 07:59:00 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lBJFx0F6026049; Wed, 19 Dec 2007 07:59:00 -0800 (PST) Date: Wed, 19 Dec 2007 07:59:00 -0800 (PST) From: Gary Winiger Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] To: Napanda.Pemmaiah@sun.com, Darren.Moffat@sun.com Cc: gww@eng.sun.com, Phi.Tran@sun.com, Artem.Kachitchkin@sun.com, PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, Mark.Haywood@sun.com Message-id: <200712191559.lBJFx0F6026049@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 498 > In addition to what Gary has said about the auth names I don't think a > new top level node in the auth hierarchy is needed here. > > I would have expected it see something like: solaris.system.power.cpu. I hadn't looked recently. And yes this seems much more in line with existant things. solaris.system.:::Machine Administration::help=SysHeader.html solaris.system.date:::Set Date & Time::help=SysDate.html solaris.system.shutdown:::Shutdown the System::help=SysShutdown.html Gary.. From randy.fishel@sun.com Wed Dec 19 08:26:38 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJGQctC024410 for ; Wed, 19 Dec 2007 08:26:38 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBJGQZwl000229 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 Dec 2007 08:26:37 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB0070X1OCVL00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Dec 2007 09:26:36 -0700 (MST) Received: from dm-eng-01.sfbay.sun.com ([129.145.155.198]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB002I11OCN950@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Dec 2007 09:26:36 -0700 (MST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBJGQYDc044545; Wed, 19 Dec 2007 08:26:34 -0800 (PST) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id lBJGQEG7013541; Wed, 19 Dec 2007 08:26:14 -0800 (PST) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10/Submit) with ESMTP id lBJGQEjx013537; Wed, 19 Dec 2007 08:26:14 -0800 (PST) Date: Wed, 19 Dec 2007 08:26:14 -0800 (PST) From: Randy Fishel Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <4768FC66.7030308@Sun.COM> X-X-Sender: randyf@grimmy To: Darren J Moffat Cc: Anup Pemmaiah , Gary Winiger , Phi.Tran@sun.com, Artem.Kachitchkin@sun.com, PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, Mark.Haywood@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712190104.lBJ14lgW025506@marduk.eng.sun.com> <4768BC89.2080007@sun.com> <4768FC66.7030308@Sun.COM> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs Status: RO Content-Length: 602 On Wed, 19 Dec 2007, Darren J Moffat wrote: > In addition to what Gary has said about the auth names I don't think a new top > level node in the auth hierarchy is needed here. > > I would have expected it see something like: solaris.system.power.cpu. > There is a proposal in the works for a 'solaris.powermanagement', and cpupm would (effectively) be the first element (followed later by other power management related items). If the advice is that it is better suited at solaris.system.powermanagement (or even shortened to power), then the project team would be agreeable. ---- Randy From Darren.Moffat@sun.com Wed Dec 19 09:37:56 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJHbtxc026741 for ; Wed, 19 Dec 2007 09:37:56 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBJHbgpD027692; Thu, 20 Dec 2007 01:37:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB00G094Z4G200@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Dec 2007 09:37:52 -0800 (PST) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB00L2O4Z2KE70@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Dec 2007 09:37:51 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBJHbobs025742; Wed, 19 Dec 2007 17:37:50 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTB00F014XG0N00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 19 Dec 2007 17:37:50 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTB005RG4Z14120@fe-emea-09.sun.com>; Wed, 19 Dec 2007 17:37:50 +0000 (GMT) Date: Wed, 19 Dec 2007 17:37:49 +0000 From: Darren J Moffat Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: Sender: Darren.Moffat@sun.com To: Randy Fishel Cc: Anup Pemmaiah , Gary Winiger , Phi.Tran@sun.com, Artem.Kachitchkin@sun.com, psarc-ext@sun.com, dchieu@sac.sfbay.sun.com, Mark.Haywood@sun.com Message-id: <476956ED.1020809@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712190104.lBJ14lgW025506@marduk.eng.sun.com> <4768BC89.2080007@sun.com> <4768FC66.7030308@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 957 Randy Fishel wrote: > On Wed, 19 Dec 2007, Darren J Moffat wrote: > >> In addition to what Gary has said about the auth names I don't think a new top >> level node in the auth hierarchy is needed here. >> >> I would have expected it see something like: solaris.system.power.cpu. >> > > There is a proposal in the works for a 'solaris.powermanagement', > and cpupm would (effectively) be the first element (followed later by > other power management related items). If the advice is that it is > better suited at solaris.system.powermanagement (or even shortened to > power), then the project team would be agreeable. solaris.system.power. would be my preference. I personally think that the extra word "management" is redundant since there this is an authorisation you are implicitly managing something. On "cpu" vs "cpupm" what does the pm suffix add ? Is there likely to be other cpu things under this hierarchy ? -- Darren J Moffat From gww@eng.sun.com Wed Dec 19 10:16:50 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJIGoRo027863 for ; Wed, 19 Dec 2007 10:16:50 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBJIGnh4044337 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 19 Dec 2007 11:16:50 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB00M0P6S11P00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 19 Dec 2007 10:16:49 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB00HSN6S0MI90@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 19 Dec 2007 10:16:48 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBJIGkU5015280; Wed, 19 Dec 2007 10:16:46 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lBJIEodZ026286; Wed, 19 Dec 2007 10:14:50 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lBJIEoPX026285; Wed, 19 Dec 2007 10:14:50 -0800 (PST) Date: Wed, 19 Dec 2007 10:14:50 -0800 (PST) From: Gary Winiger Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] To: randy.fishel@sun.com, Darren.Moffat@sun.com Cc: Napanda.Pemmaiah@sun.com, gww@eng.sun.com, Phi.Tran@sun.com, Artem.Kachitchkin@sun.com, psarc-ext@sun.com, dchieu@sac.sfbay.sun.com, Mark.Haywood@sun.com Message-id: <200712191814.lBJIEoPX026285@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 718 > > power), then the project team would be agreeable. > > solaris.system.power. would be my preference. And mine. > > I personally think that the extra word "management" is redundant since > there this is an authorisation you are implicitly managing something. > > On "cpu" vs "cpupm" what does the pm suffix add ? Is there likely to be > other cpu things under this hierarchy ? Yup. While it's only extra bytes on the file system, admins do see these strings if they look. power.cpupm seens to be stuttering. What other power.cpu stuff is there? If there are other power things to be done to the cpu that shouldn't be covered by this auth, then perhaps it needs to say pm, if not..... Gary.. From randyf@jurassic.eng.sun.com Wed Dec 19 10:18:29 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJIIS86027888 for ; Wed, 19 Dec 2007 10:18:28 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBJIIGFA013218; Thu, 20 Dec 2007 02:18:19 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB00L316UHTQ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Dec 2007 10:18:17 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.224.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB00LW06UEKF90@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Dec 2007 10:18:15 -0800 (PST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id lBJIIE7X486328; Wed, 19 Dec 2007 10:18:14 -0800 (PST) Date: Wed, 19 Dec 2007 10:17:55 -0800 (PST) From: Randy Fishel Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] To: randy.fishel@sun.com, Darren.Moffat@sun.com Cc: Napanda.Pemmaiah@sun.com, gww@eng.sun.com, Phi.Tran@sun.com, Artem.Kachitchkin@sun.com, psarc-ext@sun.com, dchieu@sac.sfbay.sun.com, Mark.Haywood@sun.com Reply-to: Randy Fishel Message-id: <200712191818.lBJIIE7X486328@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_48 SunOS 5.10 sun4u sparc Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-Sun-Text-type: ascii X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1618 > > Randy Fishel wrote: > > On Wed, 19 Dec 2007, Darren J Moffat wrote: > > > >> In addition to what Gary has said about the auth names I don't think a new top > >> level node in the auth hierarchy is needed here. > >> > >> I would have expected it see something like: solaris.system.power.cpu. > >> > > > > There is a proposal in the works for a 'solaris.powermanagement', > > and cpupm would (effectively) be the first element (followed later by > > other power management related items). If the advice is that it is > > better suited at solaris.system.powermanagement (or even shortened to > > power), then the project team would be agreeable. > > solaris.system.power. would be my preference. > > I personally think that the extra word "management" is redundant since > there this is an authorisation you are implicitly managing something. I am OK with this, and it fits into the schemes. > > On "cpu" vs "cpupm" what does the pm suffix add ? Is there likely to be > other cpu things under this hierarchy ? > To some extent, the 'pm' part is also redundant, but was changed as 'freq' seemed too specific. However, there is also some engineering going into disabling cores, so there is the possibility that there could be frequency control and core/chip disabling in the future. However, it could also be argued that they both fit into the system.power.cpu category. So again, I am OK with it being solaris.system.power.cpu, as this is the current expected individual set, and if/when another set comes up that requires something different, it can be revisited then. ---- Randy From gww@eng.sun.com Wed Dec 19 10:25:30 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJIPT9D027987 for ; Wed, 19 Dec 2007 10:25:30 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBJIPR4B016045 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 Dec 2007 02:25:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB00M0976EUS00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Dec 2007 10:25:26 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB00L9A76EKFA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Dec 2007 10:25:26 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBJIPPFY021101; Wed, 19 Dec 2007 10:25:25 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lBJINR5L026320; Wed, 19 Dec 2007 10:23:27 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lBJINR0L026319; Wed, 19 Dec 2007 10:23:27 -0800 (PST) Date: Wed, 19 Dec 2007 10:23:27 -0800 (PST) From: Gary Winiger Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] To: gww@eng.sun.com, Napanda.Pemmaiah@sun.com Cc: Artem.Kachitchkin@sun.com, Mark.Haywood@sun.com, Phi.Tran@sun.com, dchieu@sac.sfbay.sun.com, psarc-ext@sun.com Message-id: <200712191823.lBJINR0L026319@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 609 > Will provide audit events in the SetCPUFreqGovernor and > SetCPUPerformance methods that provides HAL CPUFreq specific audit > records. Will work with the audit project team to insert correct auditing. Well I think we'll need to ensure the event names are consistant with the current naming conventions. Mixed case won't work. If you're looking at the X events, those are all broken and will need to be fixed as they transition out of a TX special and into Solaris audit. Yes, you'll need to work with both the Solaris Audit team and the Hal team to work out the details before putback. Gary.. From Terry.Whatley@sun.com Wed Dec 19 10:35:55 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJIZseG028190 for ; Wed, 19 Dec 2007 10:35:54 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBJIYnrC025868; Wed, 19 Dec 2007 18:35:01 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB001017MA2T00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Dec 2007 10:34:58 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB00LJ27M8KBB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Dec 2007 10:34:56 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBJIYueP016988; Wed, 19 Dec 2007 10:34:56 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTB008017LV9700@fe-sfbay-09.sun.com> (original mail from Terry.Whatley@Sun.COM); Wed, 19 Dec 2007 10:34:55 -0800 (PST) Received: from [192.168.1.100] ([67.123.136.98]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTB00E417M6OUD0@fe-sfbay-09.sun.com>; Wed, 19 Dec 2007 10:34:54 -0800 (PST) Date: Wed, 19 Dec 2007 10:34:53 -0800 From: "Terry (Sarito) Whatley" Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <200712191818.lBJIIE7X486328@jurassic.eng.sun.com> Sender: Terry.Whatley@sun.com To: Randy Fishel Cc: randy.fishel@sun.com, Darren.Moffat@sun.com, dchieu@sac.sfbay.sun.com, gww@eng.sun.com, Phi.Tran@sun.com, Napanda.Pemmaiah@sun.com, Mark.Haywood@sun.com, psarc-ext@sun.com, Artem.Kachitchkin@sun.com Message-id: <4769644D.9000908@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712191818.lBJIIE7X486328@jurassic.eng.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 987 Randy Fishel wrote: > ... >> On "cpu" vs "cpupm" what does the pm suffix add ? Is there likely to be >> other cpu things under this hierarchy ? >> > To some extent, the 'pm' part is also redundant, but was changed as > 'freq' seemed too specific. However, there is also some engineering > going into disabling cores, so there is the possibility that there > could be frequency control and core/chip disabling in the future. > However, it could also be argued that they both fit into the > system.power.cpu category. > A CPU could have both frequency control and core disable as distinct, independent operations. -sarito > So again, I am OK with it being solaris.system.power.cpu, as this is > the current expected individual set, and if/when another set comes up > that requires something different, it can be revisited then. > > > ---- Randy > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > From gww@eng.sun.com Wed Dec 19 10:36:53 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJIaq2w028248 for ; Wed, 19 Dec 2007 10:36:53 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBJIajIC020591 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 20 Dec 2007 02:36:51 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB00M037PCQF00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 19 Dec 2007 10:36:48 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB00H997PCMPB0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 19 Dec 2007 10:36:48 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBJIajkh027946; Wed, 19 Dec 2007 10:36:45 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lBJIYlQT026345; Wed, 19 Dec 2007 10:34:47 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lBJIYlOl026344; Wed, 19 Dec 2007 10:34:47 -0800 (PST) Date: Wed, 19 Dec 2007 10:34:47 -0800 (PST) From: Gary Winiger Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] To: randyf@jurassic.eng.sun.com, Terry.Whatley@sun.com Cc: randy.fishel@sun.com, Darren.Moffat@sun.com, dchieu@sac.sfbay.sun.com, gww@eng.sun.com, Phi.Tran@sun.com, Napanda.Pemmaiah@sun.com, Mark.Haywood@sun.com, psarc-ext@sun.com, Artem.Kachitchkin@sun.com Message-id: <200712191834.lBJIYlOl026344@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 156 > A CPU could have both frequency control and core disable as distinct, > independent operations. But do they warrent separate authorizations? Gary.. From Napanda.Pemmaiah@sun.com Wed Dec 19 10:38:33 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJIcWWX028262 for ; Wed, 19 Dec 2007 10:38:33 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBJIcRAr021209 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 20 Dec 2007 02:38:31 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB001197S5K300@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 19 Dec 2007 10:38:29 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB00LMO7S3K7B0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 19 Dec 2007 10:38:27 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBJIcReh017464 for ; Wed, 19 Dec 2007 10:38:27 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTB005017AXTD00@fe-sfbay-10.sun.com> (original mail from Napanda.Pemmaiah@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 19 Dec 2007 10:38:27 -0800 (PST) Received: from [129.146.106.209] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTB00DBT7RUH1C0@fe-sfbay-10.sun.com>; Wed, 19 Dec 2007 10:38:23 -0800 (PST) Date: Wed, 19 Dec 2007 10:38:18 -0800 From: Anup Pemmaiah Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <200712191823.lBJINR0L026319@marduk.eng.sun.com> Sender: Napanda.Pemmaiah@sun.com To: Gary Winiger Cc: Artem.Kachitchkin@sun.com, Mark.Haywood@sun.com, Phi.Tran@sun.com, dchieu@sac.sfbay.sun.com, psarc-ext@sun.com Message-id: <4769651A.70607@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712191823.lBJINR0L026319@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 794 Gary Winiger wrote: >> Will provide audit events in the SetCPUFreqGovernor and >> SetCPUPerformance methods that provides HAL CPUFreq specific audit >> records. Will work with the audit project team to insert correct auditing. >> > > Well I think we'll need to ensure the event names are consistant > with the current naming conventions. Mixed case won't work. > If you're looking at the X events, those are all broken and will > need to be fixed as they transition out of a TX special and into > Solaris audit. Yes, you'll need to work with both the Solaris > Audit team and the Hal team to work out the details before putback. > Will ensure that correct auditing scheme is incorporated by working with the solaris audit and HAL team before the putback Anup > Gary.. > From randyf@jurassic.eng.sun.com Wed Dec 19 10:46:51 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJIkpdq028352 for ; Wed, 19 Dec 2007 10:46:51 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBJIkkq3012589; Wed, 19 Dec 2007 10:46:48 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB0020R85ZPS00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Dec 2007 10:46:47 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.58.166]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB00L7G85XKAB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Dec 2007 10:46:46 -0800 (PST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id lBJIkf4W486924; Wed, 19 Dec 2007 10:46:41 -0800 (PST) Date: Wed, 19 Dec 2007 10:46:22 -0800 (PST) From: Randy Fishel Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] To: randyf@jurassic.eng.sun.com, Terry.Whatley@sun.com, gww@eng.sun.com Cc: randy.fishel@sun.com, Darren.Moffat@sun.com, dchieu@sac.sfbay.sun.com, gww@eng.sun.com, Phi.Tran@sun.com, Napanda.Pemmaiah@sun.com, Mark.Haywood@sun.com, psarc-ext@sun.com, Artem.Kachitchkin@sun.com Reply-to: Randy Fishel Message-id: <200712191846.lBJIkf4W486924@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_48 SunOS 5.10 sun4u sparc Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-Sun-Text-type: ascii X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 415 > > > > A CPU could have both frequency control and core disable as distinct, > > independent operations. > > But do they warrent separate authorizations? > > Gary.. Which I currently believe to be "no" (or at least was trying to imply in my previous message). And unless I there is a reasonable explanation to the contrary, I believe that we have converged on 'solaris.system.power.cpu'. ---- Randy From gww@eng.sun.com Wed Dec 19 10:54:44 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJIshxt028928 for ; Wed, 19 Dec 2007 10:54:43 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBJIsVik004008 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 19 Dec 2007 18:54:42 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB00I258J3PK00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 19 Dec 2007 11:54:39 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB00IRW8J28J00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 19 Dec 2007 11:54:38 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBJIppAv037331; Wed, 19 Dec 2007 10:51:51 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lBJInrU3026389; Wed, 19 Dec 2007 10:49:53 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lBJInr4e026388; Wed, 19 Dec 2007 10:49:53 -0800 (PST) Date: Wed, 19 Dec 2007 10:49:53 -0800 (PST) From: Gary Winiger Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] To: randyf@jurassic.eng.sun.com, Terry.Whatley@sun.com, gww@eng.sun.com Cc: randy.fishel@sun.com, Darren.Moffat@sun.com, dchieu@sac.sfbay.sun.com, Phi.Tran@sun.com, Napanda.Pemmaiah@sun.com, Mark.Haywood@sun.com, psarc-ext@sun.com, Artem.Kachitchkin@sun.com Message-id: <200712191849.lBJInr4e026388@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 396 > Which I currently believe to be "no" (or at least was trying to > imply in my previous message). And unless I there is a reasonable > explanation to the contrary, I believe that we have converged on > 'solaris.system.power.cpu'. So how about the project team do a final spec with what's been converged on ;-) and we'll have a record of what's going to be done in a single place. Gary.. From Terry.Whatley@sun.com Wed Dec 19 11:19:57 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJJJusk029419 for ; Wed, 19 Dec 2007 11:19:56 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBJJJgdG017090; Wed, 19 Dec 2007 19:19:54 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB007019P48X00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Dec 2007 11:19:52 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB00LLF9P3KEC0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Dec 2007 11:19:51 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBJJJpF1023357; Wed, 19 Dec 2007 11:19:51 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTB00L019AVJH00@fe-sfbay-10.sun.com> (original mail from Terry.Whatley@Sun.COM); Wed, 19 Dec 2007 11:19:51 -0800 (PST) Received: from [192.168.1.100] ([67.123.136.98]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTB004MU9P2GXF0@fe-sfbay-10.sun.com>; Wed, 19 Dec 2007 11:19:51 -0800 (PST) Date: Wed, 19 Dec 2007 11:19:50 -0800 From: "Terry (Sarito) Whatley" Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] In-reply-to: <200712191846.lBJIkf4W486924@jurassic.eng.sun.com> Sender: Terry.Whatley@sun.com To: Randy Fishel Cc: gww@eng.sun.com, randy.fishel@sun.com, Darren.Moffat@sun.com, dchieu@sac.sfbay.sun.com, Phi.Tran@sun.com, Napanda.Pemmaiah@sun.com, Mark.Haywood@sun.com, psarc-ext@sun.com, Artem.Kachitchkin@sun.com Message-id: <47696ED6.2000203@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712191846.lBJIkf4W486924@jurassic.eng.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 637 Randy Fishel wrote: >> >>> A CPU could have both frequency control and core disable as distinct, >>> independent operations. >>> >> But do they warrent separate authorizations? >> >> Gary.. >> > > > Which I currently believe to be "no" (or at least was trying to > imply in my previous message). And unless I there is a reasonable > explanation to the contrary, I believe that we have converged on > 'solaris.system.power.cpu'. > Seems reasonable. I don't offhand see why they would need distinct authorizations, just wanted to make sure somebody else thought about it too. thanks, sarito > ---- Randy > From randyf@jurassic.eng.sun.com Wed Dec 19 12:10:42 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBJKAf4e000538 for ; Wed, 19 Dec 2007 12:10:42 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBJKAW42026864; Thu, 20 Dec 2007 04:10:34 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB0010ZC1K7000@brm-avmta-1.central.sun.com>; Wed, 19 Dec 2007 13:10:32 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.226.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB00INQC1J8F90@brm-avmta-1.central.sun.com>; Wed, 19 Dec 2007 13:10:31 -0700 (MST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id lBJKARB8490575; Wed, 19 Dec 2007 12:10:27 -0800 (PST) Date: Wed, 19 Dec 2007 12:10:08 -0800 (PST) From: Randy Fishel Subject: Re: CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007] To: Terry.Whatley@sun.com, gww@eng.sun.com Cc: Darren.Moffat@sun.com, dchieu@sac.sfbay.sun.com, Phi.Tran@sun.com, Napanda.Pemmaiah@sun.com, Mark.Haywood@sun.com, psarc-ext@sun.com, Artem.Kachitchkin@sun.com Reply-to: Randy Fishel Message-id: <200712192010.lBJKARB8490575@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_48 SunOS 5.10 sun4u sparc Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-Sun-Text-type: ascii X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 590 > > > Which I currently believe to be "no" (or at least was trying to > > imply in my previous message). And unless I there is a reasonable > > explanation to the contrary, I believe that we have converged on > > 'solaris.system.power.cpu'. > > So how about the project team do a final spec with what's been > converged on ;-) and we'll have a record of what's going to be > done in a single place. > > Gary.. There is an updated spec and a diff in the materials directory PSARC/2007/679/materials/spec.v2.txt PSARC/2007/679/materials/spec.v2.diffs ---- Randy