From sacadmin Tue Sep 11 09:46:49 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8BGknlw027406 for ; Tue, 11 Sep 2007 09:46:49 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l8BGhwab015639 for ; Tue, 11 Sep 2007 09:43:58 -0700 (PDT) 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 l8BGhr9i018276 for ; Tue, 11 Sep 2007 09:43:53 -0700 (PDT) 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 <0JO700A01PWMXJ00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for FWARC-record@sac.sfbay.sun.com; Tue, 11 Sep 2007 09:43:53 -0700 (PDT) Received: from [192.168.168.4] ([208.74.177.212]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JO700B4XQGT5760@fe-sfbay-09.sun.com> for FWARC-record@sac.sfbay.sun.com; Tue, 11 Sep 2007 09:43:49 -0700 (PDT) Date: Tue, 11 Sep 2007 09:43:18 -0700 From: John Plocher Subject: [Fwd: Configuration Variable Defaults [FWARC/2007/524 FastTrack timeout 09/18/2007]] Sender: John.Plocher@Sun.COM To: FWARC-record@sac.sfbay.sun.com Message-id: <46E6C5A6.9030309@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) Status: RO Content-Length: 825 -------- Original Message -------- Subject: Configuration Variable Defaults [FWARC/2007/524 FastTrack timeout 09/18/2007] Date: Tue, 11 Sep 2007 09:10:05 -0700 (PDT) From: Sunit Jain To: S.Jain@Sun.COM 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: Configuration Variable Defaults 1.2. Name of Document Author/Supplier: Author: Eduardo Horvath 1.3 Date of This Document: 11 September, 2007 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: Firmware 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From sacadmin Tue Sep 11 11:32:25 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 l8BIWPnU001612 for ; Tue, 11 Sep 2007 11:32:25 -0700 (PDT) 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 l8BITWEe028671 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 11 Sep 2007 11:29:36 -0700 (PDT) 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 <0JO700G1LVDBY900@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 12:29:36 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO7006CKVD8J3C0@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 12:29:32 -0600 (MDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l8BITVS4013560; Tue, 11 Sep 2007 11:29:31 -0700 (PDT) Received: from [192.168.0.2] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8BITVCJ049004; Tue, 11 Sep 2007 11:29:31 -0700 (PDT) Date: Tue, 11 Sep 2007 11:29:25 -0700 From: David Kahn Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults To: S.Jain@sun.com Cc: Firmware Arch , Eduardo Horvath Message-id: <46E6DE85.5050700@sun.com> 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 User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 131 Looks like this case just defines the node. Is there going to be another case that defines the contents of the md node? -David From sacadmin Tue Sep 11 11:37:31 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 l8BIbUUK001803 for ; Tue, 11 Sep 2007 11:37:31 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8BIYX35000977 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 11 Sep 2007 19:34:40 +0100 (BST) 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 <0JO700105VLRE800@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 11:34:39 -0700 (PDT) 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 <0JO700LFTVLQ5H50@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 11:34:39 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8BIYcTn011664 for ; Tue, 11 Sep 2007 18:34:38 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JO700901VBYNB00@mail-amer.sun.com> (original mail from Eduardo.Horvath@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 12:34:38 -0600 (MDT) Received: from [129.146.96.43] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JO7007GMVLOLIB7@mail-amer.sun.com>; Tue, 11 Sep 2007 12:34:37 -0600 (MDT) Date: Tue, 11 Sep 2007 11:34:36 -0700 From: Eduardo E Horvath - Sun Microsystems - Newark United States Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46E6DE85.5050700@sun.com> Sender: Eduardo.Horvath@sun.com To: David Kahn Cc: S.Jain@sun.com, Firmware Arch Message-id: <46E6DFBC.2020306@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: <46E6DE85.5050700@sun.com> User-Agent: Thunderbird 2.0.0.7pre (X11/20070910) Status: RO Content-Length: 299 David Kahn wrote: > > Looks like this case just defines the node. > > Is there going to be another case that defines > the contents of the md node? It does define the contents. The contents are an arbitrary set of name value pairs encoded as properties in the md node. -- Eduardo Horvath From sacadmin Tue Sep 11 11:43:39 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 l8BIhdZM002170 for ; Tue, 11 Sep 2007 11:43:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8BIe5vG052234 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 11 Sep 2007 12:40:12 -0600 (MDT) 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 <0JO700C1VVVZ3C00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 11:40:47 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO7008X2VVZQV60@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 11:40:47 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l8BIekS7020640; Tue, 11 Sep 2007 11:40:46 -0700 (PDT) Received: from [192.168.0.2] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8BIejwN049758; Tue, 11 Sep 2007 11:40:46 -0700 (PDT) Date: Tue, 11 Sep 2007 11:40:38 -0700 From: David Kahn Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46E6DFBC.2020306@sun.com> To: Eduardo E Horvath - Sun Microsystems - Newark United States Cc: S.Jain@sun.com, Firmware Arch Message-id: <46E6E126.40106@sun.com> 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: <46E6DE85.5050700@sun.com> <46E6DFBC.2020306@sun.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 801 Eduardo E Horvath - Sun Microsystems - Newark United States wrote: > David Kahn wrote: >> >> Looks like this case just defines the node. >> >> Is there going to be another case that defines >> the contents of the md node? > > It does define the contents. The contents are > an arbitrary set of name value pairs encoded > as properties in the md node. That's not sufficient. The node is going to have actual properties in it, and they need to be defined as well. "var-name" STR_PROP is not sufficient. The variables in the node create an interface between the MD and consumers of the MD. For example, is the node only going to contain a few property name/value pairs for platforms that don't fit the "normal" defaults hardcoded into OBP today, or is it going to contain all the defaults? -Davd From sacadmin Tue Sep 11 11:50:54 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 l8BIos7C002504 for ; Tue, 11 Sep 2007 11:50:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8BIlObI054256 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 11 Sep 2007 12:47:27 -0600 (MDT) 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 <0JO700C11W84OJ00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 11:48:04 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO7008OIW83QY70@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 11:48:03 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8BIm363014613 for ; Tue, 11 Sep 2007 18:48:03 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JO700F01W2ONN00@mail-amer.sun.com> (original mail from Eduardo.Horvath@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 12:48:03 -0600 (MDT) Received: from [129.146.96.43] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JO7007R0W82LED5@mail-amer.sun.com>; Tue, 11 Sep 2007 12:48:03 -0600 (MDT) Date: Tue, 11 Sep 2007 11:48:02 -0700 From: Eduardo E Horvath - Sun Microsystems - Newark United States Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46E6E126.40106@sun.com> Sender: Eduardo.Horvath@sun.com To: David Kahn Cc: S.Jain@sun.com, Firmware Arch Message-id: <46E6E2E2.1010600@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: <46E6DE85.5050700@sun.com> <46E6DFBC.2020306@sun.com> <46E6E126.40106@sun.com> User-Agent: Thunderbird 2.0.0.7pre (X11/20070910) Status: RO Content-Length: 1256 David Kahn wrote: > > > Eduardo E Horvath - Sun Microsystems - Newark United States wrote: >> David Kahn wrote: >>> >>> Looks like this case just defines the node. >>> >>> Is there going to be another case that defines >>> the contents of the md node? >> >> It does define the contents. The contents are >> an arbitrary set of name value pairs encoded >> as properties in the md node. > > That's not sufficient. The node is going to have > actual properties in it, and they need to be defined > as well. > > "var-name" STR_PROP is not sufficient. The variables > in the node create an interface between the MD and > consumers of the MD. > > For example, is the node only going to contain a > few property name/value pairs for platforms that > don't fit the "normal" defaults hardcoded into > OBP today, or is it going to contain all the > defaults? It only has name/value pairs for variables that are not supposed to have the "normal" defaults on that platform. I thought it was covered by the second half of this sentence: These properties indicate the platform specific default values of those configuration variables where the platform's default value differs from the standard default value. -- Eduardo Horvath From sacadmin Tue Sep 11 12:19:31 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 l8BJJUI9003284 for ; Tue, 11 Sep 2007 12:19:31 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8BJGcN0027895 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 11 Sep 2007 20:16:40 +0100 (BST) 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 <0JO700J0BXJQK000@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 13:16:38 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO700I78XJPQD10@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 13:16:37 -0600 (MDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l8BJGb5I011154; Tue, 11 Sep 2007 12:16:37 -0700 (PDT) Received: from [192.168.0.2] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8BJGalW051608; Tue, 11 Sep 2007 12:16:36 -0700 (PDT) Date: Tue, 11 Sep 2007 12:16:38 -0700 From: David Kahn Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46E6E2E2.1010600@sun.com> To: Eduardo E Horvath - Sun Microsystems - Newark United States Cc: S.Jain@sun.com, Firmware Arch Message-id: <46E6E996.3000404@sun.com> 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: <46E6DE85.5050700@sun.com> <46E6DFBC.2020306@sun.com> <46E6E126.40106@sun.com> <46E6E2E2.1010600@sun.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 699 Eduardo E Horvath - Sun Microsystems - Newark United States wrote: > It only has name/value pairs for variables that are not > supposed to have the "normal" defaults on that platform. > I thought it was covered by the second half of this sentence: Yes, it was there, but I don't really know what that means? Are the standard defaults the one's that just happen to work on Ontario, etc? Anyway, this case, or platform bindings (which might be a better place for it) need to list whatever properties are going to exist in that node for that platform. All this case does is create a node with no contents. That's fine as long as you define the per-platform contents in platform bindings. -David From sacadmin Tue Sep 11 12:49: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 l8BJnkS9003833 for ; Tue, 11 Sep 2007 12:49:47 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8BJko5h011846 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 11 Sep 2007 20:46:56 +0100 (BST) 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 <0JO700401YY7HV00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 12:46:55 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO700L4EYY75C90@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 12:46:55 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8BJktbi011718 for ; Tue, 11 Sep 2007 19:46:55 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JO700901YLU9I00@mail-amer.sun.com> (original mail from S.Jain@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 11 Sep 2007 13:46:55 -0600 (MDT) Received: from [129.145.155.71] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JO70020QYY5CJH8@mail-amer.sun.com>; Tue, 11 Sep 2007 13:46:54 -0600 (MDT) Date: Tue, 11 Sep 2007 12:46:53 -0700 From: S.Jain@sun.com Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46E6E996.3000404@sun.com> Sender: S.Jain@sun.com To: David Kahn Cc: Eduardo E Horvath - Sun Microsystems - Newark United States , Firmware Arch Message-id: <46E6F0AD.7020808@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_unvWCoN8tP0zEB3IKGh/MQ)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <46E6DE85.5050700@sun.com> <46E6DFBC.2020306@sun.com> <46E6E126.40106@sun.com> <46E6E2E2.1010600@sun.com> <46E6E996.3000404@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 9881 This is a multi-part message in MIME format. --Boundary_(ID_unvWCoN8tP0zEB3IKGh/MQ) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT There is a single OBP binary for all N2 based platforms. So, the list of config variables and their default values are same for all N2 based platforms. This may be different for N1 based platforms. The "normal" default refer to what has been defined in the OBP binary for a specific CPU type. List of variables and their defaults, as defined by OBP, is out-of-scope for this case. This case only defines a way for a platform to override the default values as defined by the OBP binary. Platform bindings should define the contents of "variable-defaults" node if they are changing any of the OBP defaults. I can update the 1-pager with this detail. Regards, Sunit David Kahn wrote: > > > Eduardo E Horvath - Sun Microsystems - Newark United States wrote: > >> It only has name/value pairs for variables that are not >> supposed to have the "normal" defaults on that platform. >> I thought it was covered by the second half of this sentence: > > > Yes, it was there, but I don't really know what that means? > Are the standard defaults the one's that just happen to > work on Ontario, etc? > > Anyway, this case, or platform bindings (which might be a > better place for it) need to list whatever properties are > going to exist in that node for that platform. > > All this case does is create a node with no contents. > That's fine as long as you define the per-platform > contents in platform bindings. > > -David -- Sunit Jain Sun Microsystems, Inc. 4110 Nework Circle, Mailstop USCA11-206, Santa Clara, CA 95054 Phone/Fax 510-996-7099 Internal x31726 --Boundary_(ID_unvWCoN8tP0zEB3IKGh/MQ) Content-type: multipart/related; boundary="Boundary_(ID_p+V7R/FLncwn2kQs1xC+8A)" --Boundary_(ID_p+V7R/FLncwn2kQs1xC+8A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
There is a single OBP binary for all N2 based platforms. So, the list of config variables and their default values are same for all N2 based platforms. This may be different for N1 based platforms.
The "normal" default refer to what has been defined in the OBP binary for a specific CPU type. List of variables and their defaults, as defined by OBP, is out-of-scope for this case.

This case only defines a way for a platform to override the default values as defined by the OBP binary. Platform bindings should define the contents of "variable-defaults" node if they are changing any of the OBP defaults.

I can update the 1-pager with this detail.

Regards,
Sunit


David Kahn wrote:


Eduardo E Horvath - Sun Microsystems - Newark United States wrote:

It only has name/value pairs for variables that are not
supposed to have the "normal" defaults on that platform.
I thought it was covered by the second half of this sentence:

Yes, it was there, but I don't really know what that means?
Are the standard defaults the one's that just happen to
work on Ontario, etc?

Anyway, this case, or platform bindings (which might be a
better place for it) need to list whatever properties are
going to exist in that node for that platform.

All this case does is create a node with no contents.
That's fine as long as you define the per-platform
contents in platform bindings.

-David

--
Sunit Signature



Sunit Jain
Sun Microsystems, Inc.
4110 Nework Circle,
Mailstop USCA11-206,
Santa Clara, CA 95054
Phone/Fax 510-996-7099
Internal x31726


--Boundary_(ID_p+V7R/FLncwn2kQs1xC+8A) Content-id: Content-type: image/gif; name=Sunlogo.gif Content-transfer-encoding: BASE64 Content-disposition: inline; filename=Sunlogo.gif R0lGODlhYgBcALMAAP///1iDn2KLpdXg54Kit+Do7b3O2aG5yZeyw3easfX3+W2T q+rv86vBz4yqvcvY4SwAAAAAYgBcAAAE/xDISau9OOvNu/9gKI5kaZ5oqq5s675w LM90bd94ru987//AoHBILBqPyKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0 es1uu9/wuHxOr9vv+FyBECAU2gsBggJ/a4KBAYQkDAYNDQaFTAULBYMHg5EeA3x9 AocGSwyeApeJpYoeBoIHChKqgkqTCZa0iZkZD6sVDgEJSQqjs6a1AgwciMYUDQEH SJOnwqS0CZQalbAVAwEPRwWjy4nRpwejyRfaggPZAd2evQvQg6oJ7tS3E+h9FQwN EgoInkBRKOBIIIB/tiYwABgAgQlvguglAicA0QAD9cpduCbI4EB3+v8o8OolAaKg fgAegAzgEYRJiQ0BvBK0LaMghxgQCeJGQdQCdw4oKKAJShS1kzL7FBCGMsTLerwS lOpls0/Ue+AwUUiQYGhHCjONcQW2UxtOYS09CIMJM9GABg/WAhWWqFUFugEW2MXI iKY5AGsBNCDEcYAAnAxo3utwqKo7dQAaR3T32IJJQQQkLADFKbNCogAEcHvFNagE iiRoTl4dIJlqqqz/Tpj5tV/irxMQ+AVQKJoAuwAQ4RQxla07AnwScILNfLiFqSRP DwJ+O6SE6gEgJ01XgiBG1gh0Cmj0vbkGBTrZab5JQTduVzQ9S+C0AEVVh4cw3Rea lra6fNrl09r/VrtdR1NTJcxTDyXEXAKTc0ldANIf7tXnj06+AOBQdc5NZQyCI6gk iAOjjDPIYOxVoNsFy0ngjkEOcPUVRtsNOAEiQdF4wjzwNEgLhBLMwiJ7HCVDDkcF ANOPMKaVRBQwaYVYoo+JRBmZjRN4NSA4GapSADoCABCjAtVpJ9ggABCQYQqvSDPM MEA6yVIFpQg0Ule6gfLKAgD9sWcF9JE4AAJ+sEnleBlcg8p2TS3nlnQ08TRSMxQ4 +oABysU5QpunqKLpbIggFwgBZs5EgDltRuLOLSMt8N8CBFBqaCKcDGCmBowUtJit silggAHAnWcATxJcFCwKtGGZxkyfdiDfuAhr9kDQYhn8ioABCNjaj3eMGMBPAwwo 4IitgnmnSj+NFMDIAQYcgC64RMSKQAIGnMqOaF9SQkAjDjTgwABxPUAAAg4UUMlF UiUwwAK5PMDgA8f+QOq4mbGj3gDNBKDAJgU4sAADsBowADWRCUbAI28BlibGiA4x cQOblAwPzP04YDPNepGz8WCRwbXAuP1kNvG+RCTJQLh/qMOArWQeRO7SxmALANS8 qfOl0bzxtvGtVhzwcR4xRAAAOw== --Boundary_(ID_p+V7R/FLncwn2kQs1xC+8A) Content-id: Content-type: image/gif; name=Sun1.gif Content-transfer-encoding: BASE64 Content-disposition: inline; filename=Sun1.gif R0lGODlhrAB2AMQAAO6LL/jGmfWvcq7D0cfV31qEoP738oKituHq7Z62x9Xg5vGd U/vYuPa6hP3z6f3q2fvhyfGVROyBHv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAACsAHYAAAX/4CSKRFGMaKqubOu+cCzP dG1PRzHcfO//wKAMYTIIj8ikEpkoHJbQqHSKyhGo2KzWpjBtv+DwqJkQm89SkwLN bgOJBaN7TpeVnvW8XkXe+/cmV3+DcyYIhIhoXSeJjWEDTo6SW5Blk5dTOTuYnEua naBIOWuhpT9qpqk8qKqtM4ausTBesrUstLa5I7i6uby9tazAwQWkw7LCZwwQPBAM KQ4NDkLLUA8M00CjYAIL3t4QEgs0EAEiCxIpDRINQuLN5inlIuvM2gWCWw0RABIR EeHGzegmIkI6FBAaPHAn0AbBFA/XPbu3CQy6ieIeNJg44UGAAAtRMAAA0AE6Bx+n /z2AMI3BA4/xJqBsEIDjiIQgRWQMYE9mgwb2ri285mBkyRFGWdYLoBApTRpNKn65 qLOfBAnmwgHoZ/PqVQbovAqYIHGCBKvsJkDoZ/DgiLZnF5712i6cWLJpJXqVwHEv g3VeAZwT528GJDwW+eqMcO3dSQcSxqJ4NwEdy354n/lrPM6yWbciQq4zt5nB2coS LkvQmBovM8qTBY5G7SzyBAGtYxwWQ9WswHdnf15NQdlgwXRlC5uNsFwnaJlMDbaj jFk57r+KkzccQbmsxHUCGqCL+WIRb8W+dY7z9/MncYHoBmdOn57y8BEO+HVLWzxd d771uEZfbPS0Vg947dnkgv8BRYTRm33rSZCNCpTFh9p8EH4GwQP3iWBaO+tMNw5k zN2HDmsgKgYbd7JlB2BaNiSjxYO/jYMbAN1INkI/G1kYn3bq4XUWZjexJ51ZAOyj GG4LrDOOaQAs0A8zPNpUZYD1cBiZNwq68Ak3C9jT5DntOCDAPwIoGEAECzDwEEFr MrOAZHOKwNQD/EDEJljmsInjRCahmU0DUQYQ5gRrRmBTogwYyoyjiC7ApjSGFWAJ MC9NYNp2oJTACDCAfZUKHHJg6syEpgRyTC19rBqLp67G8ACqLjgQ0hkMFnBIEh/+ 0OEXRMKAGzMO9ASGFUr06sOvW9QZg3jTiGfGbkmEU5f/PMaKsCEKjT3HQrG3ylQN ftvKE64K18jAZgvYIJStCuUixAKpvPrTDwALheXPNPZeZY5Je5Goqb8TbJWfVwLh 5tUzAVi1AL9SEkxgqO8e95moHhJ21UIHx4WbORKtdRVzZp3p7QjIIrGpm2kxsMx4 yzFl28eQpWNQNFeNZVtNIhcV2cEu+cPydBHIrGOQ+87KQnymHZVxm+i0M2w4AgRg m2X84EyaOF2OQO0RvYZD8jW4iYi0YJ9ldiZJHLajFgMGwb3aBHGXFVBzeLP4WQC0 omDhigO30+tZLp8l8EWRNWqb4S7Qe4S1QeLGD3810jfchxEIMCxfB08O1kGWlVVf /+UENnxWxRcOmLHg/EX5DWqQpXnWNzpzukLK1LTMtW0h4l3YaWnHjtU6N5d1EVUX zcZh7UES6NM7tqZgnOqBVw/8COBhZdrRebfwdRDby11bmFFbPo5B4d3nuVbjgDfS iyR91TTLpJGud03gFZybfBre2muv6FgAU7LiFQc4gEc/qR8MHAe+wDyjY73LkMi8 cRCFOacuYsmOAMuiMNv4jmQseoBVGIMam1hIYTH5X1pEFhwR9EMyphMa9W6BjyQY EBoy6FutWDC90PBgQg3ToQiEuAIi4ucGrQKFUfphOx8ckDx6ME8p/rKRZCFCRrEq xZeymIo7cFEVcJBC1wo0xv8ziM4RWMxdC844BzYmYotJwA0KwFWgnkyjKKhyiQzG 5QOJFGWO7eJWSCCAOhUU5VxA+N4R9CUNuLSPL1RDFF06YpWjwWw0LASAnBRjITvx 7iobEoeTRubJq6TIanxrC75Q0I9p3MxqV3lY2mYogy4gBgkQiNtCeNZKiZDEVjNb zWyMtT3UiBAAH3GMhFI3xMKEpSbDi4zIQjkW3LAmSQ+YmgfJiCQOKapsvmtiDHJV KiR08m11G1K02EE/8GQLMoLhRzH1R7eD9NBiOIqM1bDzjO+wczyzQVLh0ObJh0Vm mMCxX4yKsQQLdY4r65gSXtjkDb6FhXsnEgfkLuSj53z/DCtRWgfO+vkiirZJdLN7 HSsVFU17JLR5N4DjIg9ivBdZ7ZFQVAtXUGC1j23KhenwzDkHNix0/GM+/iQPSgmq AtxYU3nAQRvgoKKDhmIlIYmDKF98GpyfOMNlBgkXPCV0QGT2FC/hCVYzMRPRFJF0 GV0FiujQER738PQszBEb/erZACb1QJG502gG+ckhAOAsZ6yRGArQV0pxTENkbPKW QZ4kKu8sCWGsmUgmoVizeHQQhjlbFw+8uARUGfGIc+Th3EaASEQ6cYdFvJ4P53ja GEgxEc8khFUKiYQwNuIvvJ3DnbTwiy+CIo3GvQRykyuJbTAXFM6NhbTUIc5ORNcV /95QQXZbIVM38ClSC5hVkyAQMYBEak1Xw2tP0EESZgDmUHOMGI4KpFE6dLcNHLKR /NiREOE8MgKEEmZwbtVW1mhOtqjxL1pvZN+q6sE4/2DHPieDnMtqxnb2QVvcikTZ EpGsN224bxs2d9N1zKqDFXZva6aaIQFpa4UvdXGIHZyHnvJFSlK6jYoq/NYZ2odk 10HKO35qHfTMWCp0KGyFM2dMLSFVRUytynFYkifW5iyA9aRyOkbCvTCIuA1skeRl R8bj+bTFbceR8F6gaLUkFQaWBLspG77MBmcQaxnZcMZLmEGUjrQLJe/kSWhc5toX u+0aOdFWobeAu+eOQHMBznppHa7raER1Q4CEoHSl0cjQTSu3056WRHFDTQjfkroR tz01IkirakQAttV7iAqsEUHnWbthubZuAzlz7YdU87oOlfj1HmotbDHguthhMDWy 3fDqZZuB2M4mrq6i3QZYUZsNSby2GVSlbTNYu9tiyDa4v8DtcZv73OcOAQA7 --Boundary_(ID_p+V7R/FLncwn2kQs1xC+8A)-- --Boundary_(ID_unvWCoN8tP0zEB3IKGh/MQ)-- From sacadmin Fri Sep 14 15:51:43 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 l8EMph9b008114 for ; Fri, 14 Sep 2007 15:51:43 -0700 (PDT) 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 l8EMmpPG002693 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Fri, 14 Sep 2007 15:48:51 -0700 (PDT) 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 <0JOD00407RDF7100@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@Sun.COM); Fri, 14 Sep 2007 16:48:51 -0600 (MDT) 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 <0JOD003UORDD8Z00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@Sun.COM); Fri, 14 Sep 2007 16:48:49 -0600 (MDT) 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 l8EMmnqr010635 for ; Fri, 14 Sep 2007 15:48:49 -0700 (PDT) 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 <0JOD00101R7QXY00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Fri, 14 Sep 2007 15:48:49 -0700 (PDT) Received: from [129.150.34.26] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOD00LEYRD9Q2B0@fe-sfbay-10.sun.com> for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Fri, 14 Sep 2007 15:48:46 -0700 (PDT) Date: Fri, 14 Sep 2007 15:50:14 -0700 From: Hitendra Zhangada Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46E6F0AD.7020808@Sun.COM> Sender: Hitendra.Zhangada@sun.com To: Firmware Arch Cc: Eduardo E Horvath - Sun Microsystems - Newark United States Message-id: <46EB1026.4040803@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_WOFBd1b+kmeLOGjHneVlwQ)" X-PMX-Version: 5.2.0.264296 References: <46E6DE85.5050700@sun.com> <46E6DFBC.2020306@sun.com> <46E6E126.40106@sun.com> <46E6E2E2.1010600@sun.com> <46E6E996.3000404@sun.com> <46E6F0AD.7020808@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 15190 This is a multi-part message in MIME format. --Boundary_(ID_WOFBd1b+kmeLOGjHneVlwQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT S.Jain@Sun.COM wrote: > > There is a single OBP binary for all N2 based platforms. So, the list > of config variables and their default values are same for all N2 based > platforms. This may be different for N1 based platforms. > The "normal" default refer to what has been defined in the OBP binary > for a specific CPU type. List of variables and their defaults, as > defined by OBP, is out-of-scope for this case. > > This case only defines a way for a platform to override the default > values as defined by the OBP binary. Platform bindings should define > the contents of "variable-defaults" node if they are changing any of > the OBP defaults. > > I can update the 1-pager with this detail. Couple of comments. 1. The MD node changes from vBSC can only dictate defaults for Control domain. They do not apply to Guest domains. I don't think there is a way to do this for guest domain unless this node is populated by LDOM manager for each guest domain and there is a way to set defaults from LDOM manager. Do we want to limit this to control domain only? I guess the definition of MD node is ok for either guest or control domain. To implement this for guest domains will mean the "guest" domains can be platform specific which I don't think is the case. I think we should limit the change to the control domain only. If you agree then lets clarify that in the technical description section. 2. Why not put this node as sub-ordinate to "Variables" node? Is there a reason to keep it under "root" (and peer to "variable" node)? 3. We may want to clarify that the defaults are determined at the OpenBoot compile time. This node can change that default. We don't need to mention anything about N2 based platforms etc. Also, it is OK to have the same default value in this node as the one compiled in. What this means is that this node allows a way to define default values for one or more variables. We can remove mentioning of "platform specific default" and replace it with "a way to define default value". For example in section 4.1, To support this using a common OpenBoot image, a new machine descriptor node is defined to provide new platform specific default values to Openboot. can be changed to, To support this using a common OpenBoot image, a new machine descriptor node is defined to provide a way to define a default values for a variable. 4. Add note that this case defines MD node only. A platform binding defines the default values for a variable as appropriate. > > Regards, > Sunit > > > David Kahn wrote: >> >> >> Eduardo E Horvath - Sun Microsystems - Newark United States wrote: >> >>> It only has name/value pairs for variables that are not >>> supposed to have the "normal" defaults on that platform. >>> I thought it was covered by the second half of this sentence: >> >> Yes, it was there, but I don't really know what that means? >> Are the standard defaults the one's that just happen to >> work on Ontario, etc? >> >> Anyway, this case, or platform bindings (which might be a >> better place for it) need to list whatever properties are >> going to exist in that node for that platform. >> >> All this case does is create a node with no contents. >> That's fine as long as you define the per-platform >> contents in platform bindings. >> >> -David > > -- > > > > Sunit Jain > Sun Microsystems, Inc. > 4110 Nework Circle, > Mailstop USCA11-206, > Santa Clara, CA 95054 > Phone/Fax 510-996-7099 > Internal x31726 > > > > -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu --Boundary_(ID_WOFBd1b+kmeLOGjHneVlwQ) Content-type: multipart/related; boundary="Boundary_(ID_kGYYdYs+7g2QfKn0RjN+2Q)" --Boundary_(ID_kGYYdYs+7g2QfKn0RjN+2Q) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT S.Jain@Sun.COM wrote:

There is a single OBP binary for all N2 based platforms. So, the list of config variables and their default values are same for all N2 based platforms. This may be different for N1 based platforms.
The "normal" default refer to what has been defined in the OBP binary for a specific CPU type. List of variables and their defaults, as defined by OBP, is out-of-scope for this case.

This case only defines a way for a platform to override the default values as defined by the OBP binary. Platform bindings should define the contents of "variable-defaults" node if they are changing any of the OBP defaults.

I can update the 1-pager with this detail.

Couple of comments.

1.  The MD node changes from vBSC can only dictate defaults for Control domain.
     They do not apply to Guest domains.  I don't think there is a way to do this for
     guest domain unless this node is populated by LDOM manager for each guest
     domain and there is a way to set defaults from LDOM manager.

     Do we want to limit this to control domain only?  I guess the definition of MD
     node is ok for either guest or control domain.  To implement this for guest domains
     will mean the "guest" domains can be platform specific which I don't think is
     the case.  I think we should limit the change to the control domain only.  If you
     agree then lets clarify that in the technical description section.

2.  Why not put this node as sub-ordinate to "Variables" node?  Is there a reason to
     keep it under "root" (and peer to "variable" node)?

3.  We may want to clarify that the defaults are determined at the OpenBoot compile
     time.  This node can change that default.  We don't need to mention anything about
     N2 based platforms etc.  Also, it is OK to have the same default value in this
     node as the one compiled in.  What this means is that this node allows a way to
     define default values for one or more variables.

    We can remove mentioning of "platform specific default" and replace it with
    "a way to define default value".  For example in section 4.1, 

        To support this using a common OpenBoot
	image, a new machine descriptor node is defined to provide new
	platform specific default values to Openboot.
    can be changed to,

        To support this using a common OpenBoot
	image, a new machine descriptor node is defined to provide a way
        to define a default values for a variable.

4.  Add note that this case defines MD node only.  A platform binding defines the default
     values for a variable as appropriate.


Regards,
Sunit


David Kahn wrote:


Eduardo E Horvath - Sun Microsystems - Newark United States wrote:

It only has name/value pairs for variables that are not
supposed to have the "normal" defaults on that platform.
I thought it was covered by the second half of this sentence:

Yes, it was there, but I don't really know what that means?
Are the standard defaults the one's that just happen to
work on Ontario, etc?

Anyway, this case, or platform bindings (which might be a
better place for it) need to list whatever properties are
going to exist in that node for that platform.

All this case does is create a node with no contents.
That's fine as long as you define the per-platform
contents in platform bindings.

-David

--
Sunit Signature



Sunit Jain
Sun Microsystems, Inc.
4110 Nework Circle,
Mailstop USCA11-206,
Santa Clara, CA 95054
Phone/Fax 510-996-7099
Internal x31726
 




-- 
Hitendra Zhangada
=============================================
SPS Common SW Features Engineering
Software Group, Sun Microsystems, Inc.
Work Ph# (858) 625 3757, Ext. x53757
SUN Internal homepage http://esp.west/~hitu
--Boundary_(ID_kGYYdYs+7g2QfKn0RjN+2Q) Content-id: Content-type: image/gif Content-transfer-encoding: BASE64 R0lGODlhYgBcALMAAP///1iDn2KLpdXg54Kit+Do7b3O2aG5yZeyw3easfX3+W2T q+rv86vBz4yqvcvY4SwAAAAAYgBcAAAE/xDISau9OOvNu/9gKI5kaZ5oqq5s675w LM90bd94ru987//AoHBILBqPyKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0 es1uu9/wuHxOr9vv+FyBECAU2gsBggJ/a4KBAYQkDAYNDQaFTAULBYMHg5EeA3x9 AocGSwyeApeJpYoeBoIHChKqgkqTCZa0iZkZD6sVDgEJSQqjs6a1AgwciMYUDQEH SJOnwqS0CZQalbAVAwEPRwWjy4nRpwejyRfaggPZAd2evQvQg6oJ7tS3E+h9FQwN EgoInkBRKOBIIIB/tiYwABgAgQlvguglAicA0QAD9cpduCbI4EB3+v8o8OolAaKg fgAegAzgEYRJiQ0BvBK0LaMghxgQCeJGQdQCdw4oKKAJShS1kzL7FBCGMsTLerwS lOpls0/Ue+AwUUiQYGhHCjONcQW2UxtOYS09CIMJM9GABg/WAhWWqFUFugEW2MXI iKY5AGsBNCDEcYAAnAxo3utwqKo7dQAaR3T32IJJQQQkLADFKbNCogAEcHvFNagE iiRoTl4dIJlqqqz/Tpj5tV/irxMQ+AVQKJoAuwAQ4RQxla07AnwScILNfLiFqSRP DwJ+O6SE6gEgJ01XgiBG1gh0Cmj0vbkGBTrZab5JQTduVzQ9S+C0AEVVh4cw3Rea lra6fNrl09r/VrtdR1NTJcxTDyXEXAKTc0ldANIf7tXnj06+AOBQdc5NZQyCI6gk iAOjjDPIYOxVoNsFy0ngjkEOcPUVRtsNOAEiQdF4wjzwNEgLhBLMwiJ7HCVDDkcF ANOPMKaVRBQwaYVYoo+JRBmZjRN4NSA4GapSADoCABCjAtVpJ9ggABCQYQqvSDPM MEA6yVIFpQg0Ule6gfLKAgD9sWcF9JE4AAJ+sEnleBlcg8p2TS3nlnQ08TRSMxQ4 +oABysU5QpunqKLpbIggFwgBZs5EgDltRuLOLSMt8N8CBFBqaCKcDGCmBowUtJit silggAHAnWcATxJcFCwKtGGZxkyfdiDfuAhr9kDQYhn8ioABCNjaj3eMGMBPAwwo 4IitgnmnSj+NFMDIAQYcgC64RMSKQAIGnMqOaF9SQkAjDjTgwABxPUAAAg4UUMlF UiUwwAK5PMDgA8f+QOq4mbGj3gDNBKDAJgU4sAADsBowADWRCUbAI28BlibGiA4x cQOblAwPzP04YDPNepGz8WCRwbXAuP1kNvG+RCTJQLh/qMOArWQeRO7SxmALANS8 qfOl0bzxtvGtVhzwcR4xRAAAOw== --Boundary_(ID_kGYYdYs+7g2QfKn0RjN+2Q) Content-id: Content-type: image/gif Content-transfer-encoding: BASE64 R0lGODlhrAB2AMQAAO6LL/jGmfWvcq7D0cfV31qEoP738oKituHq7Z62x9Xg5vGd U/vYuPa6hP3z6f3q2fvhyfGVROyBHv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAACsAHYAAAX/4CSKRFGMaKqubOu+cCzP dG1PRzHcfO//wKAMYTIIj8ikEpkoHJbQqHSKyhGo2KzWpjBtv+DwqJkQm89SkwLN bgOJBaN7TpeVnvW8XkXe+/cmV3+DcyYIhIhoXSeJjWEDTo6SW5Blk5dTOTuYnEua naBIOWuhpT9qpqk8qKqtM4ausTBesrUstLa5I7i6uby9tazAwQWkw7LCZwwQPBAM KQ4NDkLLUA8M00CjYAIL3t4QEgs0EAEiCxIpDRINQuLN5inlIuvM2gWCWw0RABIR EeHGzegmIkI6FBAaPHAn0AbBFA/XPbu3CQy6ieIeNJg44UGAAAtRMAAA0AE6Bx+n /z2AMI3BA4/xJqBsEIDjiIQgRWQMYE9mgwb2ri285mBkyRFGWdYLoBApTRpNKn65 qLOfBAnmwgHoZ/PqVQbovAqYIHGCBKvsJkDoZ/DgiLZnF5712i6cWLJpJXqVwHEv g3VeAZwT528GJDwW+eqMcO3dSQcSxqJ4NwEdy354n/lrPM6yWbciQq4zt5nB2coS LkvQmBovM8qTBY5G7SzyBAGtYxwWQ9WswHdnf15NQdlgwXRlC5uNsFwnaJlMDbaj jFk57r+KkzccQbmsxHUCGqCL+WIRb8W+dY7z9/MncYHoBmdOn57y8BEO+HVLWzxd d771uEZfbPS0Vg947dnkgv8BRYTRm33rSZCNCpTFh9p8EH4GwQP3iWBaO+tMNw5k zN2HDmsgKgYbd7JlB2BaNiSjxYO/jYMbAN1INkI/G1kYn3bq4XUWZjexJ51ZAOyj GG4LrDOOaQAs0A8zPNpUZYD1cBiZNwq68Ak3C9jT5DntOCDAPwIoGEAECzDwEEFr MrOAZHOKwNQD/EDEJljmsInjRCahmU0DUQYQ5gRrRmBTogwYyoyjiC7ApjSGFWAJ MC9NYNp2oJTACDCAfZUKHHJg6syEpgRyTC19rBqLp67G8ACqLjgQ0hkMFnBIEh/+ 0OEXRMKAGzMO9ASGFUr06sOvW9QZg3jTiGfGbkmEU5f/PMaKsCEKjT3HQrG3ylQN ftvKE64K18jAZgvYIJStCuUixAKpvPrTDwALheXPNPZeZY5Je5Goqb8TbJWfVwLh 5tUzAVi1AL9SEkxgqO8e95moHhJ21UIHx4WbORKtdRVzZp3p7QjIIrGpm2kxsMx4 yzFl28eQpWNQNFeNZVtNIhcV2cEu+cPydBHIrGOQ+87KQnymHZVxm+i0M2w4AgRg m2X84EyaOF2OQO0RvYZD8jW4iYi0YJ9ldiZJHLajFgMGwb3aBHGXFVBzeLP4WQC0 omDhigO30+tZLp8l8EWRNWqb4S7Qe4S1QeLGD3810jfchxEIMCxfB08O1kGWlVVf /+UENnxWxRcOmLHg/EX5DWqQpXnWNzpzukLK1LTMtW0h4l3YaWnHjtU6N5d1EVUX zcZh7UES6NM7tqZgnOqBVw/8COBhZdrRebfwdRDby11bmFFbPo5B4d3nuVbjgDfS iyR91TTLpJGud03gFZybfBre2muv6FgAU7LiFQc4gEc/qR8MHAe+wDyjY73LkMi8 cRCFOacuYsmOAMuiMNv4jmQseoBVGIMam1hIYTH5X1pEFhwR9EMyphMa9W6BjyQY EBoy6FutWDC90PBgQg3ToQiEuAIi4ucGrQKFUfphOx8ckDx6ME8p/rKRZCFCRrEq xZeymIo7cFEVcJBC1wo0xv8ziM4RWMxdC844BzYmYotJwA0KwFWgnkyjKKhyiQzG 5QOJFGWO7eJWSCCAOhUU5VxA+N4R9CUNuLSPL1RDFF06YpWjwWw0LASAnBRjITvx 7iobEoeTRubJq6TIanxrC75Q0I9p3MxqV3lY2mYogy4gBgkQiNtCeNZKiZDEVjNb zWyMtT3UiBAAH3GMhFI3xMKEpSbDi4zIQjkW3LAmSQ+YmgfJiCQOKapsvmtiDHJV KiR08m11G1K02EE/8GQLMoLhRzH1R7eD9NBiOIqM1bDzjO+wczyzQVLh0ObJh0Vm mMCxX4yKsQQLdY4r65gSXtjkDb6FhXsnEgfkLuSj53z/DCtRWgfO+vkiirZJdLN7 HSsVFU17JLR5N4DjIg9ivBdZ7ZFQVAtXUGC1j23KhenwzDkHNix0/GM+/iQPSgmq AtxYU3nAQRvgoKKDhmIlIYmDKF98GpyfOMNlBgkXPCV0QGT2FC/hCVYzMRPRFJF0 GV0FiujQER738PQszBEb/erZACb1QJG502gG+ckhAOAsZ6yRGArQV0pxTENkbPKW QZ4kKu8sCWGsmUgmoVizeHQQhjlbFw+8uARUGfGIc+Th3EaASEQ6cYdFvJ4P53ja GEgxEc8khFUKiYQwNuIvvJ3DnbTwiy+CIo3GvQRykyuJbTAXFM6NhbTUIc5ORNcV /95QQXZbIVM38ClSC5hVkyAQMYBEak1Xw2tP0EESZgDmUHOMGI4KpFE6dLcNHLKR /NiREOE8MgKEEmZwbtVW1mhOtqjxL1pvZN+q6sE4/2DHPieDnMtqxnb2QVvcikTZ EpGsN224bxs2d9N1zKqDFXZva6aaIQFpa4UvdXGIHZyHnvJFSlK6jYoq/NYZ2odk 10HKO35qHfTMWCp0KGyFM2dMLSFVRUytynFYkifW5iyA9aRyOkbCvTCIuA1skeRl R8bj+bTFbceR8F6gaLUkFQaWBLspG77MBmcQaxnZcMZLmEGUjrQLJe/kSWhc5toX u+0aOdFWobeAu+eOQHMBznppHa7raER1Q4CEoHSl0cjQTSu3056WRHFDTQjfkroR tz01IkirakQAttV7iAqsEUHnWbthubZuAzlz7YdU87oOlfj1HmotbDHguthhMDWy 3fDqZZuB2M4mrq6i3QZYUZsNSby2GVSlbTNYu9tiyDa4v8DtcZv73OcOAQA7 --Boundary_(ID_kGYYdYs+7g2QfKn0RjN+2Q)-- --Boundary_(ID_WOFBd1b+kmeLOGjHneVlwQ)-- From sacadmin Mon Sep 17 09:28:34 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 l8HGSYgH026136 for ; Mon, 17 Sep 2007 09:28:34 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8HGPd8K028261 for ; Mon, 17 Sep 2007 09:25:39 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8HGPdbb016299 for ; Mon, 17 Sep 2007 16:25:39 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 <0JOI00I01RYSLM00@mail-amer.sun.com> (original mail from Eduardo.Horvath@Sun.COM) for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Mon, 17 Sep 2007 10:25:39 -0600 (MDT) Received: from [129.146.96.43] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOI0034QTMJNUB0@mail-amer.sun.com> for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Mon, 17 Sep 2007 10:25:31 -0600 (MDT) Date: Mon, 17 Sep 2007 09:25:31 -0700 From: Eduardo E Horvath - Sun Microsystems - Newark United States Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46EB1026.4040803@sun.com> Sender: Eduardo.Horvath@Sun.COM To: Hitendra Zhangada Cc: Firmware Arch Message-id: <46EEAA7B.3090906@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46E6DE85.5050700@sun.com> <46E6DFBC.2020306@sun.com> <46E6E126.40106@sun.com> <46E6E2E2.1010600@sun.com> <46E6E996.3000404@sun.com> <46E6F0AD.7020808@Sun.COM> <46EB1026.4040803@sun.com> User-Agent: Thunderbird 2.0.0.7pre (X11/20070910) Status: RO Content-Length: 4892 Hitendra Zhangada wrote: > S.Jain@Sun.COM wrote: >> >> There is a single OBP binary for all N2 based platforms. So, the list >> of config variables and their default values are same for all N2 based >> platforms. This may be different for N1 based platforms. >> The "normal" default refer to what has been defined in the OBP binary >> for a specific CPU type. List of variables and their defaults, as >> defined by OBP, is out-of-scope for this case. >> >> This case only defines a way for a platform to override the default >> values as defined by the OBP binary. Platform bindings should define >> the contents of "variable-defaults" node if they are changing any of >> the OBP defaults. >> >> I can update the 1-pager with this detail. > > Couple of comments. > > 1. The MD node changes from vBSC can only dictate defaults for Control > domain. > They do not apply to Guest domains. I don't think there is a way > to do this for > guest domain unless this node is populated by LDOM manager for each > guest > domain and there is a way to set defaults from LDOM manager. > > Do we want to limit this to control domain only? I guess the > definition of MD > node is ok for either guest or control domain. To implement this > for guest domains > will mean the "guest" domains can be platform specific which I > don't think is > the case. I think we should limit the change to the control domain > only. If you > agree then lets clarify that in the technical description section. I don't think we want to limit this to the control domain. While I admit this feature doesn't make much sense for a guest domain since the LDOMs manager would just set the variables to the desired values and `set-defaults' is usually not an issue for guest domains, it will make the implementation much more difficult if OBP needs to determine it's in the a non-control domain and change its behavior. Although, if we ever separate configuration variable maintenance from Zeus you would want to change defaults based on I/O device assignment. The domain with the video controller is the one with keyboard/screen console defaults. > 2. Why not put this node as sub-ordinate to "Variables" node? Is there > a reason to > keep it under "root" (and peer to "variable" node)? Having it under the root node reduces the interdependencies between common MD config files and platform MD config files. But it doesn't make a huge difference to move it. Eduardo > > 3. We may want to clarify that the defaults are determined at the > OpenBoot compile > time. This node can change that default. We don't need to mention > anything about > N2 based platforms etc. Also, it is OK to have the same default > value in this > node as the one compiled in. What this means is that this node > allows a way to > define default values for one or more variables. > > We can remove mentioning of "platform specific default" and replace > it with > "a way to define default value". For example in section 4.1, > > To support this using a common OpenBoot > image, a new machine descriptor node is defined to provide new > platform specific default values to Openboot. > > can be changed to, > > To support this using a common OpenBoot > image, a new machine descriptor node is defined to provide a way > to define a default values for a variable. > > > 4. Add note that this case defines MD node only. A platform binding > defines the default > values for a variable as appropriate. > >> >> Regards, >> Sunit >> >> >> David Kahn wrote: >>> >>> >>> Eduardo E Horvath - Sun Microsystems - Newark United States wrote: >>> >>>> It only has name/value pairs for variables that are not >>>> supposed to have the "normal" defaults on that platform. >>>> I thought it was covered by the second half of this sentence: >>> >>> Yes, it was there, but I don't really know what that means? >>> Are the standard defaults the one's that just happen to >>> work on Ontario, etc? >>> >>> Anyway, this case, or platform bindings (which might be a >>> better place for it) need to list whatever properties are >>> going to exist in that node for that platform. >>> >>> All this case does is create a node with no contents. >>> That's fine as long as you define the per-platform >>> contents in platform bindings. >>> >>> -David >> >> -- >> >> >> >> Sunit Jain >> Sun Microsystems, Inc. >> 4110 Nework Circle, >> Mailstop USCA11-206, >> Santa Clara, CA 95054 >> Phone/Fax 510-996-7099 >> Internal x31726 >> >> >> >> > > > -- > Hitendra Zhangada > ============================================= > SPS Common SW Features Engineering > Software Group, Sun Microsystems, Inc. > Work Ph# (858) 625 3757, Ext. x53757 > SUN Internal homepage http://esp.west/~hitu > -- Eduardo Horvath From sacadmin Mon Sep 17 09:37:34 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 l8HGbYld026335 for ; Mon, 17 Sep 2007 09:37:34 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8HGXuQO043809 for ; Mon, 17 Sep 2007 10:33:56 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8HGYduL020100 for ; Mon, 17 Sep 2007 16:34:39 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 <0JOI00A01T8L4L00@mail-amer.sun.com> (original mail from S.Jain@Sun.COM) for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Mon, 17 Sep 2007 10:34:39 -0600 (MDT) Received: from [129.145.155.71] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOI00L1WU1I0O00@mail-amer.sun.com> for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Mon, 17 Sep 2007 10:34:30 -0600 (MDT) Date: Mon, 17 Sep 2007 09:34:30 -0700 From: S.Jain@Sun.COM Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46EB1026.4040803@sun.com> Sender: S.Jain@Sun.COM To: Hitendra Zhangada Cc: Firmware Arch , Eduardo E Horvath - Sun Microsystems - Newark United States Message-id: <46EEAC96.9070205@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TE35gs2GYj1q7+UiXXLgiQ)" X-Accept-Language: en-us, en References: <46E6DE85.5050700@sun.com> <46E6DFBC.2020306@sun.com> <46E6E126.40106@sun.com> <46E6E2E2.1010600@sun.com> <46E6E996.3000404@sun.com> <46E6F0AD.7020808@Sun.COM> <46EB1026.4040803@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 20306 This is a multi-part message in MIME format. --Boundary_(ID_TE35gs2GYj1q7+UiXXLgiQ) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Hitendra Zhangada wrote: > > 2. Why not put this node as sub-ordinate to "Variables" node? Is > there a reason to > keep it under "root" (and peer to "variable" node)? Basically, we did not want to redefine the "variables" node that is defined to contain NON DEFAULT config values only. Adding a subordinate node to define DAFULTS is not a very good fit unless we change the definition of "variables" node. The only reason the "variable-defaults" node is defined under root and peer to "variable" node is to keep a parallel definition for "variables" and "variable-defaults" nodes. > > 3. We may want to clarify that the defaults are determined at the > OpenBoot compile > time. This node can change that default. We don't need to > mention anything about > N2 based platforms etc. Also, it is OK to have the same default > value in this > node as the one compiled in. What this means is that this node > allows a way to > define default values for one or more variables. > > We can remove mentioning of "platform specific default" and > replace it with > "a way to define default value". For example in section 4.1, > > To support this using a common OpenBoot > image, a new machine descriptor node is defined to provide new > platform specific default values to Openboot. > > can be changed to, > > To support this using a common OpenBoot > image, a new machine descriptor node is defined to provide a way > to define a default values for a variable. > > The default value is already provided by the OpenBoot binary. This node actually defines a way to override the defaults provided by OpenBoot as required by the platform. How about this -- To support this using a common OpenBoot image, a new machine descriptor node is defined to provide a way to override the default values for the variable(s). > 4. Add note that this case defines MD node only. A platform binding > defines the default > values for a variable as appropriate. > A note was added to section 4.1.1. Maybe you are not looking at the latest 1-pager. Does that resolve your issue? Regards, Sunit >> >> Regards, >> Sunit >> >> >> David Kahn wrote: >> >>> >>> >>> Eduardo E Horvath - Sun Microsystems - Newark United States wrote: >>> >>>> It only has name/value pairs for variables that are not >>>> supposed to have the "normal" defaults on that platform. >>>> I thought it was covered by the second half of this sentence: >>> >>> >>> Yes, it was there, but I don't really know what that means? >>> Are the standard defaults the one's that just happen to >>> work on Ontario, etc? >>> >>> Anyway, this case, or platform bindings (which might be a >>> better place for it) need to list whatever properties are >>> going to exist in that node for that platform. >>> >>> All this case does is create a node with no contents. >>> That's fine as long as you define the per-platform >>> contents in platform bindings. >>> >>> -David >> >> >> -- >> >> >> >> Sunit Jain >> Sun Microsystems, Inc. >> 4110 Nework Circle, >> Mailstop USCA11-206, >> Santa Clara, CA 95054 >> Phone/Fax 510-996-7099 >> Internal x31726 >> >> >> >> > > >-- >Hitendra Zhangada >============================================= >SPS Common SW Features Engineering >Software Group, Sun Microsystems, Inc. >Work Ph# (858) 625 3757, Ext. x53757 >SUN Internal homepage http://esp.west/~hitu > > -- Sunit Jain Sun Microsystems, Inc. 4110 Nework Circle, Mailstop USCA11-206, Santa Clara, CA 95054 Phone/Fax 510-996-7099 Internal x31726 --Boundary_(ID_TE35gs2GYj1q7+UiXXLgiQ) Content-type: multipart/related; boundary="Boundary_(ID_6BN3YeM/57adW8CCBSIEWQ)" --Boundary_(ID_6BN3YeM/57adW8CCBSIEWQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hitendra Zhangada wrote:

2.  Why not put this node as sub-ordinate to "Variables" node?  Is there a reason to
     keep it under "root" (and peer to "variable" node)?

Basically, we did not want to redefine the "variables" node that is defined to contain NON DEFAULT config values only. Adding a subordinate node to define DAFULTS is not a very good fit unless we change the definition of "variables" node. The only reason the "variable-defaults" node is defined under root and peer to "variable" node is to keep a parallel definition for "variables" and "variable-defaults" nodes.
 

3.  We may want to clarify that the defaults are determined at the OpenBoot compile
     time.  This node can change that default.  We don't need to mention anything about
     N2 based platforms etc.  Also, it is OK to have the same default value in this
     node as the one compiled in.  What this means is that this node allows a way to
     define default values for one or more variables.

    We can remove mentioning of "platform specific default" and replace it with
    "a way to define default value".  For example in section 4.1, 

        To support this using a common OpenBoot
	image, a new machine descriptor node is defined to provide new
	platform specific default values to Openboot.
    can be changed to,

        To support this using a common OpenBoot
	image, a new machine descriptor node is defined to provide a way
        to define a default values for a variable.

The default value is already provided by the OpenBoot binary. This node actually defines a way to override the defaults provided by OpenBoot as required by the platform.
How about this --
        To support this using a common OpenBoot
	image, a new machine descriptor node is defined to provide a way
        to override the default values for the variable(s).

4.  Add note that this case defines MD node only.  A platform binding defines the default
     values for a variable as appropriate.

A note was added to section 4.1.1. Maybe you are not looking at the latest 1-pager. Does that resolve your issue?

Regards,
Sunit


Regards,
Sunit


David Kahn wrote:


Eduardo E Horvath - Sun Microsystems - Newark United States wrote:

It only has name/value pairs for variables that are not
supposed to have the "normal" defaults on that platform.
I thought it was covered by the second half of this sentence:

Yes, it was there, but I don't really know what that means?
Are the standard defaults the one's that just happen to
work on Ontario, etc?

Anyway, this case, or platform bindings (which might be a
better place for it) need to list whatever properties are
going to exist in that node for that platform.

All this case does is create a node with no contents.
That's fine as long as you define the per-platform
contents in platform bindings.

-David

--
Sunit Signature



Sunit Jain
Sun Microsystems, Inc.
4110 Nework Circle,
Mailstop USCA11-206,
Santa Clara, CA 95054
Phone/Fax 510-996-7099
Internal x31726
 




-- 
Hitendra Zhangada
=============================================
SPS Common SW Features Engineering
Software Group, Sun Microsystems, Inc.
Work Ph# (858) 625 3757, Ext. x53757
SUN Internal homepage http://esp.west/~hitu

--
Sunit Signature



Sunit Jain
Sun Microsystems, Inc.
4110 Nework Circle,
Mailstop USCA11-206,
Santa Clara, CA 95054
Phone/Fax 510-996-7099
Internal x31726


--Boundary_(ID_6BN3YeM/57adW8CCBSIEWQ) Content-id: Content-type: image/gif Content-transfer-encoding: BASE64 R0lGODlhYgBcALMAAP///1iDn2KLpdXg54Kit+Do7b3O2aG5yZeyw3easfX3+W2T q+rv86vBz4yqvcvY4SwAAAAAYgBcAAAE/xDISau9OOvNu/9gKI5kaZ5oqq5s675w LM90bd94ru987//AoHBILBqPyKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0 es1uu9/wuHxOr9vv+FyBECAU2gsBggJ/a4KBAYQkDAYNDQaFTAULBYMHg5EeA3x9 AocGSwyeApeJpYoeBoIHChKqgkqTCZa0iZkZD6sVDgEJSQqjs6a1AgwciMYUDQEH SJOnwqS0CZQalbAVAwEPRwWjy4nRpwejyRfaggPZAd2evQvQg6oJ7tS3E+h9FQwN EgoInkBRKOBIIIB/tiYwABgAgQlvguglAicA0QAD9cpduCbI4EB3+v8o8OolAaKg fgAegAzgEYRJiQ0BvBK0LaMghxgQCeJGQdQCdw4oKKAJShS1kzL7FBCGMsTLerwS lOpls0/Ue+AwUUiQYGhHCjONcQW2UxtOYS09CIMJM9GABg/WAhWWqFUFugEW2MXI iKY5AGsBNCDEcYAAnAxo3utwqKo7dQAaR3T32IJJQQQkLADFKbNCogAEcHvFNagE iiRoTl4dIJlqqqz/Tpj5tV/irxMQ+AVQKJoAuwAQ4RQxla07AnwScILNfLiFqSRP DwJ+O6SE6gEgJ01XgiBG1gh0Cmj0vbkGBTrZab5JQTduVzQ9S+C0AEVVh4cw3Rea lra6fNrl09r/VrtdR1NTJcxTDyXEXAKTc0ldANIf7tXnj06+AOBQdc5NZQyCI6gk iAOjjDPIYOxVoNsFy0ngjkEOcPUVRtsNOAEiQdF4wjzwNEgLhBLMwiJ7HCVDDkcF ANOPMKaVRBQwaYVYoo+JRBmZjRN4NSA4GapSADoCABCjAtVpJ9ggABCQYQqvSDPM MEA6yVIFpQg0Ule6gfLKAgD9sWcF9JE4AAJ+sEnleBlcg8p2TS3nlnQ08TRSMxQ4 +oABysU5QpunqKLpbIggFwgBZs5EgDltRuLOLSMt8N8CBFBqaCKcDGCmBowUtJit silggAHAnWcATxJcFCwKtGGZxkyfdiDfuAhr9kDQYhn8ioABCNjaj3eMGMBPAwwo 4IitgnmnSj+NFMDIAQYcgC64RMSKQAIGnMqOaF9SQkAjDjTgwABxPUAAAg4UUMlF UiUwwAK5PMDgA8f+QOq4mbGj3gDNBKDAJgU4sAADsBowADWRCUbAI28BlibGiA4x cQOblAwPzP04YDPNepGz8WCRwbXAuP1kNvG+RCTJQLh/qMOArWQeRO7SxmALANS8 qfOl0bzxtvGtVhzwcR4xRAAAOw== --Boundary_(ID_6BN3YeM/57adW8CCBSIEWQ) Content-id: Content-type: image/gif Content-transfer-encoding: BASE64 R0lGODlhrAB2AMQAAO6LL/jGmfWvcq7D0cfV31qEoP738oKituHq7Z62x9Xg5vGd U/vYuPa6hP3z6f3q2fvhyfGVROyBHv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAACsAHYAAAX/4CSKRFGMaKqubOu+cCzP dG1PRzHcfO//wKAMYTIIj8ikEpkoHJbQqHSKyhGo2KzWpjBtv+DwqJkQm89SkwLN bgOJBaN7TpeVnvW8XkXe+/cmV3+DcyYIhIhoXSeJjWEDTo6SW5Blk5dTOTuYnEua naBIOWuhpT9qpqk8qKqtM4ausTBesrUstLa5I7i6uby9tazAwQWkw7LCZwwQPBAM KQ4NDkLLUA8M00CjYAIL3t4QEgs0EAEiCxIpDRINQuLN5inlIuvM2gWCWw0RABIR EeHGzegmIkI6FBAaPHAn0AbBFA/XPbu3CQy6ieIeNJg44UGAAAtRMAAA0AE6Bx+n /z2AMI3BA4/xJqBsEIDjiIQgRWQMYE9mgwb2ri285mBkyRFGWdYLoBApTRpNKn65 qLOfBAnmwgHoZ/PqVQbovAqYIHGCBKvsJkDoZ/DgiLZnF5712i6cWLJpJXqVwHEv g3VeAZwT528GJDwW+eqMcO3dSQcSxqJ4NwEdy354n/lrPM6yWbciQq4zt5nB2coS LkvQmBovM8qTBY5G7SzyBAGtYxwWQ9WswHdnf15NQdlgwXRlC5uNsFwnaJlMDbaj jFk57r+KkzccQbmsxHUCGqCL+WIRb8W+dY7z9/MncYHoBmdOn57y8BEO+HVLWzxd d771uEZfbPS0Vg947dnkgv8BRYTRm33rSZCNCpTFh9p8EH4GwQP3iWBaO+tMNw5k zN2HDmsgKgYbd7JlB2BaNiSjxYO/jYMbAN1INkI/G1kYn3bq4XUWZjexJ51ZAOyj GG4LrDOOaQAs0A8zPNpUZYD1cBiZNwq68Ak3C9jT5DntOCDAPwIoGEAECzDwEEFr MrOAZHOKwNQD/EDEJljmsInjRCahmU0DUQYQ5gRrRmBTogwYyoyjiC7ApjSGFWAJ MC9NYNp2oJTACDCAfZUKHHJg6syEpgRyTC19rBqLp67G8ACqLjgQ0hkMFnBIEh/+ 0OEXRMKAGzMO9ASGFUr06sOvW9QZg3jTiGfGbkmEU5f/PMaKsCEKjT3HQrG3ylQN ftvKE64K18jAZgvYIJStCuUixAKpvPrTDwALheXPNPZeZY5Je5Goqb8TbJWfVwLh 5tUzAVi1AL9SEkxgqO8e95moHhJ21UIHx4WbORKtdRVzZp3p7QjIIrGpm2kxsMx4 yzFl28eQpWNQNFeNZVtNIhcV2cEu+cPydBHIrGOQ+87KQnymHZVxm+i0M2w4AgRg m2X84EyaOF2OQO0RvYZD8jW4iYi0YJ9ldiZJHLajFgMGwb3aBHGXFVBzeLP4WQC0 omDhigO30+tZLp8l8EWRNWqb4S7Qe4S1QeLGD3810jfchxEIMCxfB08O1kGWlVVf /+UENnxWxRcOmLHg/EX5DWqQpXnWNzpzukLK1LTMtW0h4l3YaWnHjtU6N5d1EVUX zcZh7UES6NM7tqZgnOqBVw/8COBhZdrRebfwdRDby11bmFFbPo5B4d3nuVbjgDfS iyR91TTLpJGud03gFZybfBre2muv6FgAU7LiFQc4gEc/qR8MHAe+wDyjY73LkMi8 cRCFOacuYsmOAMuiMNv4jmQseoBVGIMam1hIYTH5X1pEFhwR9EMyphMa9W6BjyQY EBoy6FutWDC90PBgQg3ToQiEuAIi4ucGrQKFUfphOx8ckDx6ME8p/rKRZCFCRrEq xZeymIo7cFEVcJBC1wo0xv8ziM4RWMxdC844BzYmYotJwA0KwFWgnkyjKKhyiQzG 5QOJFGWO7eJWSCCAOhUU5VxA+N4R9CUNuLSPL1RDFF06YpWjwWw0LASAnBRjITvx 7iobEoeTRubJq6TIanxrC75Q0I9p3MxqV3lY2mYogy4gBgkQiNtCeNZKiZDEVjNb zWyMtT3UiBAAH3GMhFI3xMKEpSbDi4zIQjkW3LAmSQ+YmgfJiCQOKapsvmtiDHJV KiR08m11G1K02EE/8GQLMoLhRzH1R7eD9NBiOIqM1bDzjO+wczyzQVLh0ObJh0Vm mMCxX4yKsQQLdY4r65gSXtjkDb6FhXsnEgfkLuSj53z/DCtRWgfO+vkiirZJdLN7 HSsVFU17JLR5N4DjIg9ivBdZ7ZFQVAtXUGC1j23KhenwzDkHNix0/GM+/iQPSgmq AtxYU3nAQRvgoKKDhmIlIYmDKF98GpyfOMNlBgkXPCV0QGT2FC/hCVYzMRPRFJF0 GV0FiujQER738PQszBEb/erZACb1QJG502gG+ckhAOAsZ6yRGArQV0pxTENkbPKW QZ4kKu8sCWGsmUgmoVizeHQQhjlbFw+8uARUGfGIc+Th3EaASEQ6cYdFvJ4P53ja GEgxEc8khFUKiYQwNuIvvJ3DnbTwiy+CIo3GvQRykyuJbTAXFM6NhbTUIc5ORNcV /95QQXZbIVM38ClSC5hVkyAQMYBEak1Xw2tP0EESZgDmUHOMGI4KpFE6dLcNHLKR /NiREOE8MgKEEmZwbtVW1mhOtqjxL1pvZN+q6sE4/2DHPieDnMtqxnb2QVvcikTZ EpGsN224bxs2d9N1zKqDFXZva6aaIQFpa4UvdXGIHZyHnvJFSlK6jYoq/NYZ2odk 10HKO35qHfTMWCp0KGyFM2dMLSFVRUytynFYkifW5iyA9aRyOkbCvTCIuA1skeRl R8bj+bTFbceR8F6gaLUkFQaWBLspG77MBmcQaxnZcMZLmEGUjrQLJe/kSWhc5toX u+0aOdFWobeAu+eOQHMBznppHa7raER1Q4CEoHSl0cjQTSu3056WRHFDTQjfkroR tz01IkirakQAttV7iAqsEUHnWbthubZuAzlz7YdU87oOlfj1HmotbDHguthhMDWy 3fDqZZuB2M4mrq6i3QZYUZsNSby2GVSlbTNYu9tiyDa4v8DtcZv73OcOAQA7 --Boundary_(ID_6BN3YeM/57adW8CCBSIEWQ) Content-id: Content-type: image/gif; name=Sunlogo.gif Content-transfer-encoding: BASE64 Content-disposition: inline; filename=Sunlogo.gif R0lGODlhYgBcALMAAP///1iDn2KLpdXg54Kit+Do7b3O2aG5yZeyw3easfX3+W2T q+rv86vBz4yqvcvY4SwAAAAAYgBcAAAE/xDISau9OOvNu/9gKI5kaZ5oqq5s675w LM90bd94ru987//AoHBILBqPyKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0 es1uu9/wuHxOr9vv+FyBECAU2gsBggJ/a4KBAYQkDAYNDQaFTAULBYMHg5EeA3x9 AocGSwyeApeJpYoeBoIHChKqgkqTCZa0iZkZD6sVDgEJSQqjs6a1AgwciMYUDQEH SJOnwqS0CZQalbAVAwEPRwWjy4nRpwejyRfaggPZAd2evQvQg6oJ7tS3E+h9FQwN EgoInkBRKOBIIIB/tiYwABgAgQlvguglAicA0QAD9cpduCbI4EB3+v8o8OolAaKg fgAegAzgEYRJiQ0BvBK0LaMghxgQCeJGQdQCdw4oKKAJShS1kzL7FBCGMsTLerwS lOpls0/Ue+AwUUiQYGhHCjONcQW2UxtOYS09CIMJM9GABg/WAhWWqFUFugEW2MXI iKY5AGsBNCDEcYAAnAxo3utwqKo7dQAaR3T32IJJQQQkLADFKbNCogAEcHvFNagE iiRoTl4dIJlqqqz/Tpj5tV/irxMQ+AVQKJoAuwAQ4RQxla07AnwScILNfLiFqSRP DwJ+O6SE6gEgJ01XgiBG1gh0Cmj0vbkGBTrZab5JQTduVzQ9S+C0AEVVh4cw3Rea lra6fNrl09r/VrtdR1NTJcxTDyXEXAKTc0ldANIf7tXnj06+AOBQdc5NZQyCI6gk iAOjjDPIYOxVoNsFy0ngjkEOcPUVRtsNOAEiQdF4wjzwNEgLhBLMwiJ7HCVDDkcF ANOPMKaVRBQwaYVYoo+JRBmZjRN4NSA4GapSADoCABCjAtVpJ9ggABCQYQqvSDPM MEA6yVIFpQg0Ule6gfLKAgD9sWcF9JE4AAJ+sEnleBlcg8p2TS3nlnQ08TRSMxQ4 +oABysU5QpunqKLpbIggFwgBZs5EgDltRuLOLSMt8N8CBFBqaCKcDGCmBowUtJit silggAHAnWcATxJcFCwKtGGZxkyfdiDfuAhr9kDQYhn8ioABCNjaj3eMGMBPAwwo 4IitgnmnSj+NFMDIAQYcgC64RMSKQAIGnMqOaF9SQkAjDjTgwABxPUAAAg4UUMlF UiUwwAK5PMDgA8f+QOq4mbGj3gDNBKDAJgU4sAADsBowADWRCUbAI28BlibGiA4x cQOblAwPzP04YDPNepGz8WCRwbXAuP1kNvG+RCTJQLh/qMOArWQeRO7SxmALANS8 qfOl0bzxtvGtVhzwcR4xRAAAOw== --Boundary_(ID_6BN3YeM/57adW8CCBSIEWQ) Content-id: Content-type: image/gif; name=Sun1.gif Content-transfer-encoding: BASE64 Content-disposition: inline; filename=Sun1.gif R0lGODlhrAB2AMQAAO6LL/jGmfWvcq7D0cfV31qEoP738oKituHq7Z62x9Xg5vGd U/vYuPa6hP3z6f3q2fvhyfGVROyBHv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAACsAHYAAAX/4CSKRFGMaKqubOu+cCzP dG1PRzHcfO//wKAMYTIIj8ikEpkoHJbQqHSKyhGo2KzWpjBtv+DwqJkQm89SkwLN bgOJBaN7TpeVnvW8XkXe+/cmV3+DcyYIhIhoXSeJjWEDTo6SW5Blk5dTOTuYnEua naBIOWuhpT9qpqk8qKqtM4ausTBesrUstLa5I7i6uby9tazAwQWkw7LCZwwQPBAM KQ4NDkLLUA8M00CjYAIL3t4QEgs0EAEiCxIpDRINQuLN5inlIuvM2gWCWw0RABIR EeHGzegmIkI6FBAaPHAn0AbBFA/XPbu3CQy6ieIeNJg44UGAAAtRMAAA0AE6Bx+n /z2AMI3BA4/xJqBsEIDjiIQgRWQMYE9mgwb2ri285mBkyRFGWdYLoBApTRpNKn65 qLOfBAnmwgHoZ/PqVQbovAqYIHGCBKvsJkDoZ/DgiLZnF5712i6cWLJpJXqVwHEv g3VeAZwT528GJDwW+eqMcO3dSQcSxqJ4NwEdy354n/lrPM6yWbciQq4zt5nB2coS LkvQmBovM8qTBY5G7SzyBAGtYxwWQ9WswHdnf15NQdlgwXRlC5uNsFwnaJlMDbaj jFk57r+KkzccQbmsxHUCGqCL+WIRb8W+dY7z9/MncYHoBmdOn57y8BEO+HVLWzxd d771uEZfbPS0Vg947dnkgv8BRYTRm33rSZCNCpTFh9p8EH4GwQP3iWBaO+tMNw5k zN2HDmsgKgYbd7JlB2BaNiSjxYO/jYMbAN1INkI/G1kYn3bq4XUWZjexJ51ZAOyj GG4LrDOOaQAs0A8zPNpUZYD1cBiZNwq68Ak3C9jT5DntOCDAPwIoGEAECzDwEEFr MrOAZHOKwNQD/EDEJljmsInjRCahmU0DUQYQ5gRrRmBTogwYyoyjiC7ApjSGFWAJ MC9NYNp2oJTACDCAfZUKHHJg6syEpgRyTC19rBqLp67G8ACqLjgQ0hkMFnBIEh/+ 0OEXRMKAGzMO9ASGFUr06sOvW9QZg3jTiGfGbkmEU5f/PMaKsCEKjT3HQrG3ylQN ftvKE64K18jAZgvYIJStCuUixAKpvPrTDwALheXPNPZeZY5Je5Goqb8TbJWfVwLh 5tUzAVi1AL9SEkxgqO8e95moHhJ21UIHx4WbORKtdRVzZp3p7QjIIrGpm2kxsMx4 yzFl28eQpWNQNFeNZVtNIhcV2cEu+cPydBHIrGOQ+87KQnymHZVxm+i0M2w4AgRg m2X84EyaOF2OQO0RvYZD8jW4iYi0YJ9ldiZJHLajFgMGwb3aBHGXFVBzeLP4WQC0 omDhigO30+tZLp8l8EWRNWqb4S7Qe4S1QeLGD3810jfchxEIMCxfB08O1kGWlVVf /+UENnxWxRcOmLHg/EX5DWqQpXnWNzpzukLK1LTMtW0h4l3YaWnHjtU6N5d1EVUX zcZh7UES6NM7tqZgnOqBVw/8COBhZdrRebfwdRDby11bmFFbPo5B4d3nuVbjgDfS iyR91TTLpJGud03gFZybfBre2muv6FgAU7LiFQc4gEc/qR8MHAe+wDyjY73LkMi8 cRCFOacuYsmOAMuiMNv4jmQseoBVGIMam1hIYTH5X1pEFhwR9EMyphMa9W6BjyQY EBoy6FutWDC90PBgQg3ToQiEuAIi4ucGrQKFUfphOx8ckDx6ME8p/rKRZCFCRrEq xZeymIo7cFEVcJBC1wo0xv8ziM4RWMxdC844BzYmYotJwA0KwFWgnkyjKKhyiQzG 5QOJFGWO7eJWSCCAOhUU5VxA+N4R9CUNuLSPL1RDFF06YpWjwWw0LASAnBRjITvx 7iobEoeTRubJq6TIanxrC75Q0I9p3MxqV3lY2mYogy4gBgkQiNtCeNZKiZDEVjNb zWyMtT3UiBAAH3GMhFI3xMKEpSbDi4zIQjkW3LAmSQ+YmgfJiCQOKapsvmtiDHJV KiR08m11G1K02EE/8GQLMoLhRzH1R7eD9NBiOIqM1bDzjO+wczyzQVLh0ObJh0Vm mMCxX4yKsQQLdY4r65gSXtjkDb6FhXsnEgfkLuSj53z/DCtRWgfO+vkiirZJdLN7 HSsVFU17JLR5N4DjIg9ivBdZ7ZFQVAtXUGC1j23KhenwzDkHNix0/GM+/iQPSgmq AtxYU3nAQRvgoKKDhmIlIYmDKF98GpyfOMNlBgkXPCV0QGT2FC/hCVYzMRPRFJF0 GV0FiujQER738PQszBEb/erZACb1QJG502gG+ckhAOAsZ6yRGArQV0pxTENkbPKW QZ4kKu8sCWGsmUgmoVizeHQQhjlbFw+8uARUGfGIc+Th3EaASEQ6cYdFvJ4P53ja GEgxEc8khFUKiYQwNuIvvJ3DnbTwiy+CIo3GvQRykyuJbTAXFM6NhbTUIc5ORNcV /95QQXZbIVM38ClSC5hVkyAQMYBEak1Xw2tP0EESZgDmUHOMGI4KpFE6dLcNHLKR /NiREOE8MgKEEmZwbtVW1mhOtqjxL1pvZN+q6sE4/2DHPieDnMtqxnb2QVvcikTZ EpGsN224bxs2d9N1zKqDFXZva6aaIQFpa4UvdXGIHZyHnvJFSlK6jYoq/NYZ2odk 10HKO35qHfTMWCp0KGyFM2dMLSFVRUytynFYkifW5iyA9aRyOkbCvTCIuA1skeRl R8bj+bTFbceR8F6gaLUkFQaWBLspG77MBmcQaxnZcMZLmEGUjrQLJe/kSWhc5toX u+0aOdFWobeAu+eOQHMBznppHa7raER1Q4CEoHSl0cjQTSu3056WRHFDTQjfkroR tz01IkirakQAttV7iAqsEUHnWbthubZuAzlz7YdU87oOlfj1HmotbDHguthhMDWy 3fDqZZuB2M4mrq6i3QZYUZsNSby2GVSlbTNYu9tiyDa4v8DtcZv73OcOAQA7 --Boundary_(ID_6BN3YeM/57adW8CCBSIEWQ)-- --Boundary_(ID_TE35gs2GYj1q7+UiXXLgiQ)-- From sacadmin Mon Sep 17 17:49: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 l8I0nBJw007900 for ; Mon, 17 Sep 2007 17:49:36 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l8I0k2dY005575 for ; Tue, 18 Sep 2007 08:46:07 +0800 (SGT) 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 l8I0jkvV015016 for ; Mon, 17 Sep 2007 17:45:46 -0700 (PDT) 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 <0JOJ00B01GQ97D00@fe-sfbay-09.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Mon, 17 Sep 2007 17:45:46 -0700 (PDT) Received: from [129.153.85.46] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOJ00DPXGS5WZ80@fe-sfbay-09.sun.com> for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Mon, 17 Sep 2007 17:45:41 -0700 (PDT) Date: Mon, 17 Sep 2007 17:45:40 -0700 From: Hitendra Zhangada Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46EEAA7B.3090906@sun.com> Sender: Hitendra.Zhangada@Sun.COM To: Eduardo E Horvath - Sun Microsystems - Newark United States Cc: Firmware Arch Message-id: <46EF1FB4.4050000@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46E6DE85.5050700@sun.com> <46E6DFBC.2020306@sun.com> <46E6E126.40106@sun.com> <46E6E2E2.1010600@sun.com> <46E6E996.3000404@sun.com> <46E6F0AD.7020808@Sun.COM> <46EB1026.4040803@sun.com> <46EEAA7B.3090906@sun.com> User-Agent: Thunderbird 2.0.0.7pre (X11/20070910) Status: RO Content-Length: 5855 Eduardo E Horvath - Sun Microsystems - Newark United States wrote: > Hitendra Zhangada wrote: >> S.Jain@Sun.COM wrote: >>> >>> There is a single OBP binary for all N2 based platforms. So, the >>> list of config variables and their default values are same for all >>> N2 based platforms. This may be different for N1 based platforms. >>> The "normal" default refer to what has been defined in the OBP >>> binary for a specific CPU type. List of variables and their >>> defaults, as defined by OBP, is out-of-scope for this case. >>> >>> This case only defines a way for a platform to override the default >>> values as defined by the OBP binary. Platform bindings should define >>> the contents of "variable-defaults" node if they are changing any of >>> the OBP defaults. >>> >>> I can update the 1-pager with this detail. >> >> Couple of comments. >> >> 1. The MD node changes from vBSC can only dictate defaults for >> Control domain. >> They do not apply to Guest domains. I don't think there is a >> way to do this for >> guest domain unless this node is populated by LDOM manager for >> each guest >> domain and there is a way to set defaults from LDOM manager. >> >> Do we want to limit this to control domain only? I guess the >> definition of MD >> node is ok for either guest or control domain. To implement >> this for guest domains >> will mean the "guest" domains can be platform specific which I >> don't think is >> the case. I think we should limit the change to the control >> domain only. If you >> agree then lets clarify that in the technical description section. > > I don't think we want to limit this to the control domain. While I admit > this feature doesn't make much sense for a guest domain since the LDOMs > manager would just set the variables to the desired values and > `set-defaults' > is usually not an issue for guest domains, it will make the > implementation > much more difficult if OBP needs to determine it's in the a non-control > domain and change its behavior. Implementing this Zeus and providing a way to change the default is the problem. I don't think we will ever implement ldm interface to specify a "default" value for a variable. That said, I agree that the interface can work for any domain and hence we need not restrict it to control domain only. If there is a need in future to specify different defaults to variables for guest domains then that can be developed. For now, Zeus will never create the MD node and hence variables will have defaults defined at the compile time. > > Although, if we ever separate configuration variable maintenance from > Zeus > you would want to change defaults based on I/O device assignment. The > domain with the video controller is the one with keyboard/screen console > defaults. > >> 2. Why not put this node as sub-ordinate to "Variables" node? Is >> there a reason to >> keep it under "root" (and peer to "variable" node)? > > Having it under the root node reduces the interdependencies between > common MD config files and platform MD config files. But it doesn't make > a huge difference to move it. > > Eduardo > >> >> 3. We may want to clarify that the defaults are determined at the >> OpenBoot compile >> time. This node can change that default. We don't need to >> mention anything about >> N2 based platforms etc. Also, it is OK to have the same default >> value in this >> node as the one compiled in. What this means is that this node >> allows a way to >> define default values for one or more variables. >> >> We can remove mentioning of "platform specific default" and >> replace it with >> "a way to define default value". For example in section 4.1, >> >> To support this using a common OpenBoot >> image, a new machine descriptor node is defined to provide new >> platform specific default values to Openboot. >> >> can be changed to, >> >> To support this using a common OpenBoot >> image, a new machine descriptor node is defined to provide a way >> to define a default values for a variable. >> >> >> 4. Add note that this case defines MD node only. A platform binding >> defines the default >> values for a variable as appropriate. >> >>> >>> Regards, >>> Sunit >>> >>> >>> David Kahn wrote: >>>> >>>> >>>> Eduardo E Horvath - Sun Microsystems - Newark United States wrote: >>>> >>>>> It only has name/value pairs for variables that are not >>>>> supposed to have the "normal" defaults on that platform. >>>>> I thought it was covered by the second half of this sentence: >>>> >>>> Yes, it was there, but I don't really know what that means? >>>> Are the standard defaults the one's that just happen to >>>> work on Ontario, etc? >>>> >>>> Anyway, this case, or platform bindings (which might be a >>>> better place for it) need to list whatever properties are >>>> going to exist in that node for that platform. >>>> >>>> All this case does is create a node with no contents. >>>> That's fine as long as you define the per-platform >>>> contents in platform bindings. >>>> >>>> -David >>> >>> -- >>> >>> >>> >>> Sunit Jain >>> Sun Microsystems, Inc. >>> 4110 Nework Circle, >>> Mailstop USCA11-206, >>> Santa Clara, CA 95054 >>> Phone/Fax 510-996-7099 >>> Internal x31726 >>> >>> >>> >>> >> >> >> -- >> Hitendra Zhangada >> ============================================= >> SPS Common SW Features Engineering >> Software Group, Sun Microsystems, Inc. >> Work Ph# (858) 625 3757, Ext. x53757 >> SUN Internal homepage http://esp.west/~hitu >> > > -- Hitendra Zhangada ==================================== SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. Sun Ph# (858) 625 3757, Sun Ext. x53757 Internal homepage http://esp.west/~hitu From sacadmin Mon Sep 17 17:53:13 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 l8I0rDi6008143 for ; Mon, 17 Sep 2007 17:53:13 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8I0oIxa028488 for ; Mon, 17 Sep 2007 17:50:18 -0700 (PDT) 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 l8I0oCAv012473 for ; Mon, 17 Sep 2007 17:50:12 -0700 (PDT) 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 <0JOJ00E01GXK3H00@fe-sfbay-09.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Mon, 17 Sep 2007 17:50:12 -0700 (PDT) Received: from [129.153.85.46] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOJ00DUCGZOWZ90@fe-sfbay-09.sun.com> for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Mon, 17 Sep 2007 17:50:12 -0700 (PDT) Date: Mon, 17 Sep 2007 17:50:12 -0700 From: Hitendra Zhangada Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46EEAC96.9070205@Sun.COM> Sender: Hitendra.Zhangada@Sun.COM To: Firmware Arch Cc: Eduardo E Horvath - Sun Microsystems - Newark United States Message-id: <46EF20C4.5020507@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_PJWMBQ+GZBWHvvU1MMnHTA)" References: <46E6DE85.5050700@sun.com> <46E6DFBC.2020306@sun.com> <46E6E126.40106@sun.com> <46E6E2E2.1010600@sun.com> <46E6E996.3000404@sun.com> <46E6F0AD.7020808@Sun.COM> <46EB1026.4040803@sun.com> <46EEAC96.9070205@Sun.COM> User-Agent: Thunderbird 2.0.0.7pre (X11/20070910) Status: RO Content-Length: 7409 This is a multi-part message in MIME format. --Boundary_(ID_PJWMBQ+GZBWHvvU1MMnHTA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT S.Jain@Sun.COM wrote: > > Hitendra Zhangada wrote: >> >> 2. Why not put this node as sub-ordinate to "Variables" node? Is >> there a reason to >> keep it under "root" (and peer to "variable" node)? > > Basically, we did not want to redefine the "variables" node that is > defined to contain NON DEFAULT config values only. Adding a > subordinate node to define DAFULTS is not a very good fit unless we > change the definition of "variables" node. The only reason the > "variable-defaults" node is defined under root and peer to "variable" > node is to keep a parallel definition for "variables" and > "variable-defaults" nodes. > Ok. >> >> 3. We may want to clarify that the defaults are determined at the >> OpenBoot compile >> time. This node can change that default. We don't need to >> mention anything about >> N2 based platforms etc. Also, it is OK to have the same default >> value in this >> node as the one compiled in. What this means is that this node >> allows a way to >> define default values for one or more variables. >> >> We can remove mentioning of "platform specific default" and >> replace it with >> "a way to define default value". For example in section 4.1, >> >> To support this using a common OpenBoot >> image, a new machine descriptor node is defined to provide new >> platform specific default values to Openboot. >> can be changed to, >> >> To support this using a common OpenBoot >> image, a new machine descriptor node is defined to provide a way >> to define a default values for a variable. >> > The default value is already provided by the OpenBoot binary. This > node actually defines a way to override the defaults provided by > OpenBoot as required by the platform. > How about this -- > To support this using a common OpenBoot > image, a new machine descriptor node is defined to provide a way > to override the default values for the variable(s). > I am fine with that. This comment was sort of a nit but I would be happy if we re-write it such that the node defines a "default" for one or more variables. MD node takes precedence over compile time defaults. These changes are not changing the specification itself and hence will not change the timer for this case. >> 4. Add note that this case defines MD node only. A platform binding >> defines the default >> values for a variable as appropriate. >> > A note was added to section 4.1.1. Maybe you are not looking at the > latest 1-pager. Does that resolve your issue? > Yes, I see that now. Thanks. > Regards, > Sunit > -- Hitendra Zhangada ==================================== SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. Sun Ph# (858) 625 3757, Sun Ext. x53757 Internal homepage http://esp.west/~hitu --Boundary_(ID_PJWMBQ+GZBWHvvU1MMnHTA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT S.Jain@Sun.COM wrote:

Hitendra Zhangada wrote:

2.  Why not put this node as sub-ordinate to "Variables" node?  Is there a reason to
     keep it under "root" (and peer to "variable" node)?

Basically, we did not want to redefine the "variables" node that is defined to contain NON DEFAULT config values only. Adding a subordinate node to define DAFULTS is not a very good fit unless we change the definition of "variables" node. The only reason the "variable-defaults" node is defined under root and peer to "variable" node is to keep a parallel definition for "variables" and "variable-defaults" nodes.
 

Ok.


3.  We may want to clarify that the defaults are determined at the OpenBoot compile
     time.  This node can change that default.  We don't need to mention anything about
     N2 based platforms etc.  Also, it is OK to have the same default value in this
     node as the one compiled in.  What this means is that this node allows a way to
     define default values for one or more variables.

    We can remove mentioning of "platform specific default" and replace it with
    "a way to define default value".  For example in section 4.1, 

        To support this using a common OpenBoot
	image, a new machine descriptor node is defined to provide new
	platform specific default values to Openboot.
    can be changed to,

        To support this using a common OpenBoot
	image, a new machine descriptor node is defined to provide a way
        to define a default values for a variable.

The default value is already provided by the OpenBoot binary. This node actually defines a way to override the defaults provided by OpenBoot as required by the platform.
How about this --
        To support this using a common OpenBoot
	image, a new machine descriptor node is defined to provide a way
        to override the default values for the variable(s).


I am fine with that.  This comment was sort of a nit but I would be happy if we
re-write it such that the node defines a "default" for one or more variables.
MD node takes precedence over compile time defaults.  These changes are
not changing the specification itself and hence will not change the timer for
this case.
4.  Add note that this case defines MD node only.  A platform binding defines the default
     values for a variable as appropriate.

A note was added to section 4.1.1. Maybe you are not looking at the latest 1-pager. Does that resolve your issue?


Yes, I see that now.


Thanks.
Regards,
Sunit



-- 
Hitendra Zhangada
====================================
SPS Common SW Features Engineering
Software Group, Sun Microsystems, Inc.
Sun Ph# (858) 625 3757, Sun Ext. x53757
Internal homepage http://esp.west/~hitu
--Boundary_(ID_PJWMBQ+GZBWHvvU1MMnHTA)-- From sacadmin Mon Sep 17 19:05:07 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 l8I256fj009261 for ; Mon, 17 Sep 2007 19:05:06 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8I22ALg023775 for ; Tue, 18 Sep 2007 03:02:10 +0100 (BST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8I229jj026713 for ; Tue, 18 Sep 2007 02:02:09 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 <0JOJ00I01K879S00@mail-amer.sun.com> (original mail from Eric.Sharakan@Sun.COM) for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Mon, 17 Sep 2007 20:02:09 -0600 (MDT) Received: from [192.168.100.100] (c-24-62-226-231.hsd1.ma.comcast.net [24.62.226.231]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOJ00DBIKBHFN00@mail-amer.sun.com> for fwarc@Sun.COM (ORCPT fwarc@Sun.COM); Mon, 17 Sep 2007 20:02:07 -0600 (MDT) Date: Mon, 17 Sep 2007 22:01:33 -0400 From: Eric Sharakan Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46EF1FB4.4050000@sun.com> Sender: Eric.Sharakan@Sun.COM To: Hitendra Zhangada Cc: Eduardo E Horvath - Sun Microsystems - Newark United States , Firmware Arch Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=Apple-Mail-5--827187672; micalg=sha1 References: <46E6DE85.5050700@sun.com> <46E6DFBC.2020306@sun.com> <46E6E126.40106@sun.com> <46E6E2E2.1010600@sun.com> <46E6E996.3000404@sun.com> <46E6F0AD.7020808@Sun.COM> <46EB1026.4040803@sun.com> <46EEAA7B.3090906@sun.com> <46EF1FB4.4050000@sun.com> Status: RO Content-Length: 10070 --Apple-Mail-5--827187672 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Sep 17, 2007, at 8:45 PM, Hitendra Zhangada wrote: > Eduardo E Horvath - Sun Microsystems - Newark United States wrote: >> Hitendra Zhangada wrote: >>> S.Jain@Sun.COM wrote: >>>> >>>> There is a single OBP binary for all N2 based platforms. So, the >>>> list of config variables and their default values are same for >>>> all N2 based platforms. This may be different for N1 based >>>> platforms. >>>> The "normal" default refer to what has been defined in the OBP >>>> binary for a specific CPU type. List of variables and their >>>> defaults, as defined by OBP, is out-of-scope for this case. >>>> >>>> This case only defines a way for a platform to override the >>>> default values as defined by the OBP binary. Platform bindings >>>> should define the contents of "variable-defaults" node if they >>>> are changing any of the OBP defaults. >>>> >>>> I can update the 1-pager with this detail. >>> >>> Couple of comments. >>> >>> 1. The MD node changes from vBSC can only dictate defaults for >>> Control domain. >>> They do not apply to Guest domains. I don't think there is >>> a way to do this for >>> guest domain unless this node is populated by LDOM manager >>> for each guest >>> domain and there is a way to set defaults from LDOM manager. >>> >>> Do we want to limit this to control domain only? I guess >>> the definition of MD >>> node is ok for either guest or control domain. To implement >>> this for guest domains >>> will mean the "guest" domains can be platform specific which >>> I don't think is >>> the case. I think we should limit the change to the control >>> domain only. If you >>> agree then lets clarify that in the technical description >>> section. >> >> I don't think we want to limit this to the control domain. While >> I admit >> this feature doesn't make much sense for a guest domain since the >> LDOMs >> manager would just set the variables to the desired values and >> `set-defaults' >> is usually not an issue for guest domains, it will make the >> implementation >> much more difficult if OBP needs to determine it's in the a non- >> control >> domain and change its behavior. > > Implementing this Zeus and providing a way to change the default is > the problem. Agreed; this would be a mess for the LDom Manager to have to manage, keep in sync with the "normal" variable store, etc. > I don't think we will ever implement ldm interface to specify a > "default" value > for a variable. That said, I agree that the interface can work for > any domain and > hence we need not restrict it to control domain only. If there is > a need in future > to specify different defaults to variables for guest domains then > that can be developed. > For now, Zeus will never create the MD node and hence variables > will have defaults > defined at the compile time. >> >> Although, if we ever separate configuration variable maintenance >> from Zeus >> you would want to change defaults based on I/O device assignment. >> The >> domain with the video controller is the one with keyboard/screen >> console >> defaults. >> >>> 2. Why not put this node as sub-ordinate to "Variables" node? >>> Is there a reason to >>> keep it under "root" (and peer to "variable" node)? >> >> Having it under the root node reduces the interdependencies between >> common MD config files and platform MD config files. But it >> doesn't make >> a huge difference to move it. It does also mean a small bit of extra work for Zeus, to make sure this new node gets propagated to successive generations of the control domain's MD. -Eric >> >> Eduardo >> >>> >>> 3. We may want to clarify that the defaults are determined at >>> the OpenBoot compile >>> time. This node can change that default. We don't need to >>> mention anything about >>> N2 based platforms etc. Also, it is OK to have the same >>> default value in this >>> node as the one compiled in. What this means is that this >>> node allows a way to >>> define default values for one or more variables. >>> >>> We can remove mentioning of "platform specific default" and >>> replace it with >>> "a way to define default value". For example in section 4.1, >>> >>> To support this using a common OpenBoot >>> image, a new machine descriptor node is defined to provide new >>> platform specific default values to Openboot. >>> >>> can be changed to, >>> >>> To support this using a common OpenBoot >>> image, a new machine descriptor node is defined to provide a way >>> to define a default values for a variable. >>> >>> >>> 4. Add note that this case defines MD node only. A platform >>> binding defines the default >>> values for a variable as appropriate. >>> >>>> >>>> Regards, >>>> Sunit >>>> >>>> >>>> David Kahn wrote: >>>>> >>>>> >>>>> Eduardo E Horvath - Sun Microsystems - Newark United States wrote: >>>>> >>>>>> It only has name/value pairs for variables that are not >>>>>> supposed to have the "normal" defaults on that platform. >>>>>> I thought it was covered by the second half of this sentence: >>>>> >>>>> Yes, it was there, but I don't really know what that means? >>>>> Are the standard defaults the one's that just happen to >>>>> work on Ontario, etc? >>>>> >>>>> Anyway, this case, or platform bindings (which might be a >>>>> better place for it) need to list whatever properties are >>>>> going to exist in that node for that platform. >>>>> >>>>> All this case does is create a node with no contents. >>>>> That's fine as long as you define the per-platform >>>>> contents in platform bindings. >>>>> >>>>> -David >>>> >>>> -- >>>> >>>> >>>> >>>> Sunit Jain >>>> Sun Microsystems, Inc. >>>> 4110 Nework Circle, >>>> Mailstop USCA11-206, >>>> Santa Clara, CA 95054 >>>> Phone/Fax 510-996-7099 >>>> Internal x31726 >>>> >>>> >>>> >>> >>> >>> -- >>> Hitendra Zhangada >>> ============================================= >>> SPS Common SW Features Engineering >>> Software Group, Sun Microsystems, Inc. >>> Work Ph# (858) 625 3757, Ext. x53757 >>> SUN Internal homepage http://esp.west/~hitu >>> >> >> > > > -- > Hitendra Zhangada > ==================================== > SPS Common SW Features Engineering > Software Group, Sun Microsystems, Inc. > Sun Ph# (858) 625 3757, Sun Ext. x53757 > Internal homepage http://esp.west/~hitu > --Apple-Mail-5--827187672 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKzCCAuQw ggJNoAMCAQICEFTfUBSm04O9csLdiMZKo0YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTEwMTA0MDc0N1oXDTA3MTEwMTA0MDc0 N1owRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIGCSqGSIb3DQEJARYVRXJp Yy5TaGFyYWthbkBTdW4uQ09NMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1JWiATbJ kDoiiNur5YXkIb8Jm7RhIPgiF9/m9Pb8P9FWAVVu5sl3OcmCxOnqdPLK0Me9zL8QVJCKZzi/CWyE iRXHcorqn5hJZcLoXpRjiLOqqz1W0hyf/Vi/VNH9p8mAunBpeUln2WRV+2ekZUVV5gqS9FhggcEE EaTeNZI4YrTbOqhMA0VksYMexa7Ygn2KoQiBYtnn52g2FojTfxuwjWIbzGpwLMaLly6MePSqlM3l d3ZrRQiUG396IZI9J6uZ9iTdyVxV5mGa2qMvQF8UnT9z0r121JtZHkSPjQ54PvegzQ76mtBSTqPU Zlo/yfs+gHb9caKjTuZn5glOrACF6QIDAQABozIwMDAgBgNVHREEGTAXgRVFcmljLlNoYXJha2Fu QFN1bi5DT00wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCN8sqiw30hzI1/b5GZKW+t OjvyglKLV0PpoJBzNatTr82ixDXeh6C1CspHEBO7gFPx1vW90obDfG8kjHgZKaZvysrjbeny6eFr Qd/eNNCTHkBCFKadle9w8ERdr7vyHFpZ/3lmo/2ogAK34t3qV5NKjngY978NUNkS4dDnItCqWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVN9QFKbTg71ywt2IxkqjRjAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA5 MTgwMjAxMzNaMCMGCSqGSIb3DQEJBDEWBBTFJo9of7WewcKoFpC2mH5OXC+goDCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFTfUBSm 04O9csLdiMZKo0YwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFTfUBSm04O9csLdiMZKo0YwDQYJKoZIhvcNAQEBBQAEggEAYXSV P6FWMBt11LujI/osQf+I4g14h1hfMRBRMW65ncvCoRv6cDI8sflpJOCevzSIuyIQZRZe8biGGUAk HscoMwp/Wih0J1DPasB6YnSYjguGQD0xuExMn/HiBqEHr+Ut2M/nF6D7UbDYLNA3is7iCbU1PPCF uFdoB1EGTixzjv7YNb81BUMlZtKaEma+qHvfmipjRtWQSGlOPqRhryICgzProVqkkdrtQL6zgi3T 2JjPZw3sVeF8KgE5rN4I+Gi2Zh0a6/OZAnpahskgJqEOu+KHET+0+0nf9oR0ef4F971h0JKNH59u +ffBPHuLskyjVrezWgxpC7dFHCGi4xlIiwAAAAAAAA== --Apple-Mail-5--827187672-- From sacadmin Tue Sep 18 00:23:19 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 l8I7NIop013787 for ; Tue, 18 Sep 2007 00:23:19 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8I7KNMB001110 for ; Tue, 18 Sep 2007 00:20:23 -0700 (PDT) Received: from lightside.sfbay.sun.com (lightside.SFBay.Sun.COM [10.7.80.229]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l8I7KMJu027454; Tue, 18 Sep 2007 00:20:22 -0700 (PDT) Received: from lightside.sfbay.sun.com (localhost [127.0.0.1]) by lightside.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l8I7CuVV007455; Tue, 18 Sep 2007 00:12:56 -0700 (PDT) Received: (from rath@localhost) by lightside.sfbay.sun.com (8.13.7+Sun/8.13.7/Submit) id l8I7CuJQ007454; Tue, 18 Sep 2007 00:12:56 -0700 (PDT) Date: Tue, 18 Sep 2007 00:12:55 -0700 From: Kevin Rathbun To: Eric Sharakan Cc: Hitendra Zhangada , Eduardo E Horvath - Sun Microsystems - Newark United States , Firmware Arch Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults Message-ID: <20070918071255.GL10008@cronopios> Reply-To: Kevin Rathbun References: <46E6DE85.5050700@sun.com> <46E6DFBC.2020306@sun.com> <46E6E126.40106@sun.com> <46E6E2E2.1010600@sun.com> <46E6E996.3000404@sun.com> <46E6F0AD.7020808@Sun.COM> <46EB1026.4040803@sun.com> <46EEAA7B.3090906@sun.com> <46EF1FB4.4050000@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 7333 On Mon, Sep 17, 2007 at 10:01:33PM -0400, Eric Sharakan wrote: > On Sep 17, 2007, at 8:45 PM, Hitendra Zhangada wrote: > > >Eduardo E Horvath - Sun Microsystems - Newark United States wrote: > >>Hitendra Zhangada wrote: > >>>S.Jain@Sun.COM wrote: > >>>> > >>>>There is a single OBP binary for all N2 based platforms. So, the > >>>>list of config variables and their default values are same for > >>>>all N2 based platforms. This may be different for N1 based > >>>>platforms. > >>>>The "normal" default refer to what has been defined in the OBP > >>>>binary for a specific CPU type. List of variables and their > >>>>defaults, as defined by OBP, is out-of-scope for this case. > >>>> > >>>>This case only defines a way for a platform to override the > >>>>default values as defined by the OBP binary. Platform bindings > >>>>should define the contents of "variable-defaults" node if they > >>>>are changing any of the OBP defaults. > >>>> > >>>>I can update the 1-pager with this detail. > >>> > >>>Couple of comments. > >>> > >>>1. The MD node changes from vBSC can only dictate defaults for > >>>Control domain. > >>> They do not apply to Guest domains. I don't think there is > >>>a way to do this for > >>> guest domain unless this node is populated by LDOM manager > >>>for each guest > >>> domain and there is a way to set defaults from LDOM manager. > >>> > >>> Do we want to limit this to control domain only? I guess > >>>the definition of MD > >>> node is ok for either guest or control domain. To implement > >>>this for guest domains > >>> will mean the "guest" domains can be platform specific which > >>>I don't think is > >>> the case. I think we should limit the change to the control > >>>domain only. If you > >>> agree then lets clarify that in the technical description > >>>section. > >> > >>I don't think we want to limit this to the control domain. While > >>I admit > >>this feature doesn't make much sense for a guest domain since the > >>LDOMs > >>manager would just set the variables to the desired values and > >>`set-defaults' > >>is usually not an issue for guest domains, it will make the > >>implementation > >>much more difficult if OBP needs to determine it's in the a non- > >>control > >>domain and change its behavior. > > > >Implementing this Zeus and providing a way to change the default is > >the problem. > > Agreed; this would be a mess for the LDom Manager to have to manage, > keep in sync with the "normal" variable store, etc. > > >I don't think we will ever implement ldm interface to specify a > >"default" value > >for a variable. That said, I agree that the interface can work for > >any domain and > >hence we need not restrict it to control domain only. If there is > >a need in future > >to specify different defaults to variables for guest domains then > >that can be developed. > >For now, Zeus will never create the MD node and hence variables > >will have defaults > >defined at the compile time. > >> > >>Although, if we ever separate configuration variable maintenance > >>from Zeus > >>you would want to change defaults based on I/O device assignment. > >>The > >>domain with the video controller is the one with keyboard/screen > >>console > >>defaults. If we already know this is coming, why not encode this in the MD. For defaults that are related to partitionable resources, have the defaults be in a node that is a child of the resource node. Eg., the keyboard/screen defaults node could be a child of a fb iodevice node. Then the guest domains won't lose their virtual console when they type set-defaults. The new defaults will only appear in the guest to which zeus assigns the resource. If the default is unrelated to a resource then it lives in the root level defaults node and applies to all guests. kvn > >>>2. Why not put this node as sub-ordinate to "Variables" node? > >>>Is there a reason to > >>> keep it under "root" (and peer to "variable" node)? > >> > >>Having it under the root node reduces the interdependencies between > >>common MD config files and platform MD config files. But it > >>doesn't make > >>a huge difference to move it. > > It does also mean a small bit of extra work for Zeus, to make sure > this new node gets propagated to successive generations of the > control domain's MD. > > -Eric > > >> > >>Eduardo > >> > >>> > >>>3. We may want to clarify that the defaults are determined at > >>>the OpenBoot compile > >>> time. This node can change that default. We don't need to > >>>mention anything about > >>> N2 based platforms etc. Also, it is OK to have the same > >>>default value in this > >>> node as the one compiled in. What this means is that this > >>>node allows a way to > >>> define default values for one or more variables. > >>> > >>> We can remove mentioning of "platform specific default" and > >>>replace it with > >>> "a way to define default value". For example in section 4.1, > >>> > >>> To support this using a common OpenBoot > >>> image, a new machine descriptor node is defined to provide new > >>> platform specific default values to Openboot. > >>> > >>> can be changed to, > >>> > >>> To support this using a common OpenBoot > >>> image, a new machine descriptor node is defined to provide a way > >>> to define a default values for a variable. > >>> > >>> > >>>4. Add note that this case defines MD node only. A platform > >>>binding defines the default > >>> values for a variable as appropriate. > >>> > >>>> > >>>>Regards, > >>>>Sunit > >>>> > >>>> > >>>>David Kahn wrote: > >>>>> > >>>>> > >>>>>Eduardo E Horvath - Sun Microsystems - Newark United States wrote: > >>>>> > >>>>>>It only has name/value pairs for variables that are not > >>>>>>supposed to have the "normal" defaults on that platform. > >>>>>>I thought it was covered by the second half of this sentence: > >>>>> > >>>>>Yes, it was there, but I don't really know what that means? > >>>>>Are the standard defaults the one's that just happen to > >>>>>work on Ontario, etc? > >>>>> > >>>>>Anyway, this case, or platform bindings (which might be a > >>>>>better place for it) need to list whatever properties are > >>>>>going to exist in that node for that platform. > >>>>> > >>>>>All this case does is create a node with no contents. > >>>>>That's fine as long as you define the per-platform > >>>>>contents in platform bindings. > >>>>> > >>>>>-David > >>>> > >>>>-- > >>>> > >>>> > >>>> > >>>> Sunit Jain > >>>>Sun Microsystems, Inc. > >>>>4110 Nework Circle, > >>>>Mailstop USCA11-206, > >>>>Santa Clara, CA 95054 > >>>>Phone/Fax 510-996-7099 > >>>>Internal x31726 > >>>> > >>>> > >>>> > >>> > >>> > >>>-- > >>>Hitendra Zhangada > >>>============================================= > >>>SPS Common SW Features Engineering > >>>Software Group, Sun Microsystems, Inc. > >>>Work Ph# (858) 625 3757, Ext. x53757 > >>>SUN Internal homepage http://esp.west/~hitu > >>> > >> > >> > > > > > >-- > >Hitendra Zhangada > >==================================== > >SPS Common SW Features Engineering > >Software Group, Sun Microsystems, Inc. > >Sun Ph# (858) 625 3757, Sun Ext. x53757 > >Internal homepage http://esp.west/~hitu > > > From sacadmin Tue Sep 18 11:11:03 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 l8IIB3gb003160 for ; Tue, 18 Sep 2007 11:11:03 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8II87tN015016 for ; Tue, 18 Sep 2007 11:08:07 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l8II86Cx029197; Tue, 18 Sep 2007 11:08:06 -0700 (PDT) Received: from [127.0.0.1] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8II83la031507; Tue, 18 Sep 2007 11:08:05 -0700 (PDT) Message-ID: <46F01402.3090005@sun.com> Date: Tue, 18 Sep 2007 11:08:02 -0700 From: David Kahn User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sunit jain , Eduardo E Horvath - Sun Microsystems - Newark United States CC: Eric Sharakan , Firmware Arch Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1428 Sunit, Eduardo, Let's please make sure we are solving the entire problem with this single case before it times out. In fact, please extend the time out so we can resolve these issues. As I understand it, the problem is being able to override default variables compiled into the single sun4v openboot binary to permit platform overrides to those defaults. Note that this is not at all the same as a user overriding a configuration variable .. that's already handled for both the control domain and non-control guest domains. The compiled defaults, including the overriden values defined by this case, should apply to all domains, just as a recompiled OBP binary would with those new default values compiled in. Without this, we would need to build separate binaries for each platform even if the only difference is in a platform default for a configuration variable. Maybe that's ok, since the firmware is the only platform specific thing we actually deliver, and that's what we actually do today, right? I believe that the defaults, and their overriden values from the MD need to apply to both control and non-control guest domains for this interface to work properly. If they don't, then I don't see the point of doing this. Am I missing something? If my assumptions are correct, I think the case materials need to be updated to include whatever interfaces need to be extended to support this properly. Thanks, -David From sacadmin Tue Sep 18 11:21:59 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 l8IILwJG003944 for ; Tue, 18 Sep 2007 11:21:59 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8IIIptC012937 for ; Tue, 18 Sep 2007 19:18:52 +0100 (BST) 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 l8IIIpMv020505 for ; Tue, 18 Sep 2007 18:18:51 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 <0JOK00J01RB8HW00@mail-amer.sun.com> (original mail from S.Jain@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 18 Sep 2007 12:18:51 -0600 (MDT) Received: from [129.150.18.70] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOK0074OTJ9P6A0@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 18 Sep 2007 12:18:46 -0600 (MDT) Date: Tue, 18 Sep 2007 11:18:50 -0700 From: Sunit Jain Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46F01402.3090005@sun.com> Sender: S.Jain@Sun.COM To: Firmware Arch Cc: Eduardo E Horvath - Sun Microsystems - Newark United States , Eric Sharakan Reply-to: S.Jain@Sun.COM Message-id: <46F0168A.8000903@Sun.Com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46F01402.3090005@sun.com> User-Agent: Thunderbird 2.0.0.7pre (Windows/20070910) Status: RO Content-Length: 252 As present we are discussing this case and the proposed solution with appropriate teams. The case timer was supposed to expire today but now the IAM* file has been changed to "waiting need spec" until all the issues are resolved. Regards, Sunit From sacadmin Tue Sep 18 12:51:02 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 l8IJp2Mn008899 for ; Tue, 18 Sep 2007 12:51:02 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8IJm6j6029229 for ; Tue, 18 Sep 2007 12:48:06 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8IJm6HN022102 for ; Tue, 18 Sep 2007 19:48:06 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 <0JOK00F01WB63B00@mail-amer.sun.com> (original mail from Eric.Sharakan@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 18 Sep 2007 13:48:06 -0600 (MDT) Received: from [129.148.180.44] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOK00FG5XO1C0A0@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 18 Sep 2007 13:48:02 -0600 (MDT) Date: Tue, 18 Sep 2007 15:47:25 -0400 From: Eric Sharakan Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46F0168A.8000903@Sun.Com> Sender: Eric.Sharakan@Sun.COM To: S.Jain@Sun.COM Cc: Firmware Arch , Eduardo E Horvath - Sun Microsystems - Newark United States Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=Apple-Mail-10--763232219; micalg=sha1 References: <46F01402.3090005@sun.com> <46F0168A.8000903@Sun.Com> Status: RO Content-Length: 4649 --Apple-Mail-10--763232219 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FWIW, I retract any objection I raised against locating the node under /root, with the caveat that we're not trying to solve the problem of different defaults for different domains (e.g. to handle different resources in those domains). If we do want to tackle that as part of this case, then (as already mentioned) we might need to re- think where the variable default info belongs. Also, it turns out that getting this info copied into the guest domain MDs (again, assuming the same defaults for all domains) is something we should be able to accomplish (i.e. without creating a flag day with Zeus) as a detail of the vbsc implementation. I'll take this up offline with Eduardo. -Eric On Sep 18, 2007, at 2:18 PM, Sunit Jain wrote: > > As present we are discussing this case and the proposed solution > with appropriate teams. > > The case timer was supposed to expire today but now the IAM* file > has been changed to "waiting need spec" until all the issues are > resolved. > > Regards, > Sunit > > --Apple-Mail-10--763232219 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKzCCAuQw ggJNoAMCAQICEFTfUBSm04O9csLdiMZKo0YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTEwMTA0MDc0N1oXDTA3MTEwMTA0MDc0 N1owRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIGCSqGSIb3DQEJARYVRXJp Yy5TaGFyYWthbkBTdW4uQ09NMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1JWiATbJ kDoiiNur5YXkIb8Jm7RhIPgiF9/m9Pb8P9FWAVVu5sl3OcmCxOnqdPLK0Me9zL8QVJCKZzi/CWyE iRXHcorqn5hJZcLoXpRjiLOqqz1W0hyf/Vi/VNH9p8mAunBpeUln2WRV+2ekZUVV5gqS9FhggcEE EaTeNZI4YrTbOqhMA0VksYMexa7Ygn2KoQiBYtnn52g2FojTfxuwjWIbzGpwLMaLly6MePSqlM3l d3ZrRQiUG396IZI9J6uZ9iTdyVxV5mGa2qMvQF8UnT9z0r121JtZHkSPjQ54PvegzQ76mtBSTqPU Zlo/yfs+gHb9caKjTuZn5glOrACF6QIDAQABozIwMDAgBgNVHREEGTAXgRVFcmljLlNoYXJha2Fu QFN1bi5DT00wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCN8sqiw30hzI1/b5GZKW+t OjvyglKLV0PpoJBzNatTr82ixDXeh6C1CspHEBO7gFPx1vW90obDfG8kjHgZKaZvysrjbeny6eFr Qd/eNNCTHkBCFKadle9w8ERdr7vyHFpZ/3lmo/2ogAK34t3qV5NKjngY978NUNkS4dDnItCqWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVN9QFKbTg71ywt2IxkqjRjAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA5 MTgxOTQ3MjVaMCMGCSqGSIb3DQEJBDEWBBRbzmzrF+7avqmV6oeJamt3Ev+4ODCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFTfUBSm 04O9csLdiMZKo0YwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFTfUBSm04O9csLdiMZKo0YwDQYJKoZIhvcNAQEBBQAEggEAY7MH PNQLsOlVeSUmu3PQjoh7IbHn3y9lYOMPV1b65VO655mCWLp/MyZNoJtoGfINC5Swd3Y1dYE1oIJD PKfDyJU/2ykkEJMhimThVpZsQnuEqcqxFRWXeg9pzDn8BA2ooS3eoBK/z+b+OZZdWDHphO+Oj667 Xq+164LXOd6BGgIF4nZNU9JeTCxM4N6mTLNNSuBWhKZiRybtWyRjioCGPI8bqbeP3XdBFpC9NMvv UKJwH9EJTbLHtXGzr3/ZE08ZN6WrJ6hUZXtAPDCXzmz/YVb1KMOjg2C1RHx3QIuX/GsvT9yImJ5k D2DDbQTRC8Nc+Lr01cZz3Vj5UpbJzSv39QAAAAAAAA== --Apple-Mail-10--763232219-- From sacadmin Tue Sep 18 13:48:43 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 l8IKmhfP010727 for ; Tue, 18 Sep 2007 13:48:43 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8IKjk4E026500 for ; Tue, 18 Sep 2007 13:45:46 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8IKjkDj005110 for ; Tue, 18 Sep 2007 20:45:46 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 <0JOK00301Y7P8T00@mail-amer.sun.com> (original mail from Eduardo.Horvath@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 18 Sep 2007 14:45:46 -0600 (MDT) Received: from [129.146.96.43] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOL005OA0BXB4D0@mail-amer.sun.com>; Tue, 18 Sep 2007 14:45:33 -0600 (MDT) Date: Tue, 18 Sep 2007 13:45:33 -0700 From: Eduardo E Horvath Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46F01402.3090005@sun.com> Sender: Eduardo.Horvath@Sun.COM To: David Kahn Cc: sunit jain , Eric Sharakan , Firmware Arch Message-id: <46F038ED.4060509@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46F01402.3090005@sun.com> User-Agent: Thunderbird 2.0.0.7pre (X11/20070910) Status: RO Content-Length: 2286 David Kahn wrote: > > Sunit, Eduardo, > > Let's please make sure we are solving the entire > problem with this single case before it times out. > In fact, please extend the time out so we can > resolve these issues. > > As I understand it, the problem is being able to > override default variables compiled into the > single sun4v openboot binary to permit platform > overrides to those defaults. Note that this is > not at all the same as a user overriding a configuration > variable .. that's already handled for both the > control domain and non-control guest domains. > > The compiled defaults, including the overriden values > defined by this case, should apply to all domains, > just as a recompiled OBP binary would with those > new default values compiled in. > > Without this, we would need to build separate binaries > for each platform even if the only difference is in > a platform default for a configuration variable. > Maybe that's ok, since the firmware is the only > platform specific thing we actually deliver, and > that's what we actually do today, right? > > I believe that the defaults, and their overriden > values from the MD need to apply to both control > and non-control guest domains for this interface > to work properly. If they don't, then I don't see > the point of doing this. > > Am I missing something? If my assumptions are correct, > I think the case materials need to be updated to > include whatever interfaces need to be extended to > support this properly. After discussions with the interested parties, the functionality would be: The variables-defaults node will be in the PRI. LDOM manager will automatically propagate the node and its contents to all guests. Having all guests with the same defaults should work fine for Glendale because the planned use, setting the input and output devices to the TTY multiplexer, should work without problems even if the only available input and output devices are the "virtual-console". If this functionality is not appropriate for future platforms then those platforms will need to extend the ARC case by adding support for multiple "variables-defaults" nodes in other parts of the MD, say under individual I/O devices. Do you still see any issues with this case? -- Eduardo Horvath From sacadmin Tue Sep 18 14:14:05 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 l8ILE5hK013664 for ; Tue, 18 Sep 2007 14:14:05 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8ILAOSq060240 for ; Tue, 18 Sep 2007 15:10:24 -0600 (MDT) 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 l8ILB301002097 for ; Tue, 18 Sep 2007 14:11:03 -0700 (PDT) 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 <0JOL00J01176U800@fe-sfbay-09.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 18 Sep 2007 14:11:03 -0700 (PDT) Received: from [129.150.33.2] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOL003EA1IBVYA0@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 18 Sep 2007 14:11:01 -0700 (PDT) Date: Tue, 18 Sep 2007 14:12:29 -0700 From: Hitendra Zhangada Subject: Re: FWARC/2007/524 fasttrack - Configuration Variable Defaults In-reply-to: <46F038ED.4060509@sun.com> Sender: Hitendra.Zhangada@Sun.COM To: Eduardo E Horvath Cc: Firmware Arch Message-id: <46F03F3D.1030507@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46F01402.3090005@sun.com> <46F038ED.4060509@sun.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 3654 Eduardo E Horvath wrote: > David Kahn wrote: >> >> Sunit, Eduardo, >> >> Let's please make sure we are solving the entire >> problem with this single case before it times out. >> In fact, please extend the time out so we can >> resolve these issues. >> >> As I understand it, the problem is being able to >> override default variables compiled into the >> single sun4v openboot binary to permit platform >> overrides to those defaults. Note that this is >> not at all the same as a user overriding a configuration >> variable .. that's already handled for both the >> control domain and non-control guest domains. >> >> The compiled defaults, including the overriden values >> defined by this case, should apply to all domains, >> just as a recompiled OBP binary would with those >> new default values compiled in. >> >> Without this, we would need to build separate binaries >> for each platform even if the only difference is in >> a platform default for a configuration variable. >> Maybe that's ok, since the firmware is the only >> platform specific thing we actually deliver, and >> that's what we actually do today, right? >> >> I believe that the defaults, and their overriden >> values from the MD need to apply to both control >> and non-control guest domains for this interface >> to work properly. If they don't, then I don't see >> the point of doing this. >> >> Am I missing something? If my assumptions are correct, >> I think the case materials need to be updated to >> include whatever interfaces need to be extended to >> support this properly. > > After discussions with the interested parties, the > functionality would be: > > The variables-defaults node will be in the PRI. > > LDOM manager will automatically propagate the node > and its contents to all guests. I don't like this. Some of the options which are valid for control domain may not be valid for guest domains. Thus, I don't think it makes sense to propagate defaults in this fashion to guest domains. An example for this would be the input/output devices can be set to a non-virtual-console as a default in control domain but that default is not a valid default for the guest domains. User can see the defaults when they see output of "printenv". Having anything but virtual-console as a default in guest domain is going to cause confusion at the customer site. If they do "set-defaults" then what will happen in this case? IMO, it should be in the MD for control domain only. If similar support is needed for guest domains then we can go implement that for guests in future. The MD node design will be valid there too. The guest MDs should not have this defaults node at all. > > Having all guests with the same defaults should work > fine for Glendale because the planned use, setting > the input and output devices to the TTY multiplexer, > should work without problems even if the only available > input and output devices are the "virtual-console". It may work for Glendale but we are trying to design something which should work across all sun4v platforms. > > If this functionality is not appropriate for future > platforms then those platforms will need to extend the > ARC case by adding support for multiple "variables-defaults" > nodes in other parts of the MD, say under individual > I/O devices. > No, lets resolve this once and not defer it to future. > Do you still see any issues with this case? > I do, see above. -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu