From sacadmin Fri Dec 14 17:22:43 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 lBF1Mg75019380 for ; Fri, 14 Dec 2007 17:22:43 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBF1Ma5T016761 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Sat, 15 Dec 2007 09:22:41 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT200001H5SH200@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 14 Dec 2007 17:22:40 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT200IP1H5SRG60@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 14 Dec 2007 17:22:40 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBF1MedB027537 for ; Fri, 14 Dec 2007 17:22:40 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT200D01H275B00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 14 Dec 2007 17:22:40 -0800 (PST) Received: from [129.150.34.93] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT200HUFH5NE470@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 14 Dec 2007 17:22:36 -0800 (PST) Date: Fri, 14 Dec 2007 17:24:18 -0800 From: Hitendra Zhangada Subject: Self-Review : 2007/696 - _boot-script property in mini-Md Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <47632CC2.80803@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_nBL63MoHp+ZByfYr+aCCVQ)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 3884 This is a multi-part message in MIME format. --Boundary_(ID_nBL63MoHp+ZByfYr+aCCVQ) Content-type: multipart/alternative; boundary="Boundary_(ID_RRbrYpIHrRvfLzN8eD4n6A)" --Boundary_(ID_RRbrYpIHrRvfLzN8eD4n6A) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I am sponsoring this self-review case for Fred Gotwald and Mir Jamal Hyder. This case add a new property to mini-MD. The property is as described in the attached document. This case requests a release binding of for minor/micro for any firmware changes and minor/micro/patch for any OS changes. -- 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_RRbrYpIHrRvfLzN8eD4n6A) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I am sponsoring this self-review case for Fred Gotwald and
Mir Jamal Hyder. This case add a new property to mini-MD.
The property is as described in the attached document.

This case requests a release binding of for minor/micro for any
firmware changes and minor/micro/patch for any OS changes.

-- 
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_RRbrYpIHrRvfLzN8eD4n6A)-- --Boundary_(ID_nBL63MoHp+ZByfYr+aCCVQ) Content-type: text/plain; name=boot-script_property.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=boot-script_property.txt Title : _boot-script property in mini-Md Modifications to the mini-MD described in FWARC/2007/294. New properties called "_boot-script" is added to the mini-MD. The value of this property is a string which is interpreted by OpenBoot. Name Tag Required? Description --------------------------------------------------------------------- _boot-script PROP_STR No A string property, if present, is interpreted by OpenBoot. The string consists of one or more OpenBoot words which are interpreted by OpenBoot. See FWARC/2002/228 for details on concept of boot script Interface Table : Imported Interfaces : Interface Classification Comments ==================================================================== sun4v Machine Sun Private MD nodes definitions as Description nodes defined by FWARC/2005/115 Domain Services Sun Private Defined by FWARC/2006/055 Specification (Includes description of Variables DS) mini-MD Sun Private Defined by FWARC/2007/294 Exported Interfaces: Interface Classification Comments ==================================================================== "_boot-script" Sun Private String property in mini-MD as described above --Boundary_(ID_nBL63MoHp+ZByfYr+aCCVQ)-- From sacadmin Fri Dec 14 20:27:44 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBF4Rh1Q029626 for ; Fri, 14 Dec 2007 20:27:43 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBF4RXIu012792 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Sat, 15 Dec 2007 04:27:42 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT200901PQ4WK00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 14 Dec 2007 20:27:40 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT200INOPQ3REE0@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 14 Dec 2007 20:27:39 -0800 (PST) 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 lBF4RdZq016322 for ; Sat, 15 Dec 2007 04:27:39 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT200901PGUV500@mail-amer.sun.com> (original mail from S.Jain@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 14 Dec 2007 21:27:39 -0700 (MST) Received: from [192.168.0.197] ([68.123.46.75]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT200BVTPQ2BB80@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 14 Dec 2007 21:27:39 -0700 (MST) Date: Fri, 14 Dec 2007 20:27:37 -0800 From: Sunit Jain Subject: Re: Self-Review : 2007/696 - _boot-script property in mini-Md In-reply-to: <47632CC2.80803@sun.com> Sender: S.Jain@sun.com To: Hitendra Zhangada Cc: Firmware ARC Reply-to: S.Jain@sun.com Message-id: <476357B9.20108@Sun.Com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Lfalt831zMBCKBXoXbWDoA)" X-PMX-Version: 5.2.0.264296 References: <47632CC2.80803@sun.com> User-Agent: Thunderbird 2.0.0.12pre (Windows/20071213) Status: RO Content-Length: 2147 This is a multi-part message in MIME format. --Boundary_(ID_Lfalt831zMBCKBXoXbWDoA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Why is this property added to mini-MD and not Guest MD? Regards, Sunit Hitendra Zhangada wrote: > I am sponsoring this self-review case for Fred Gotwald and > Mir Jamal Hyder. This case add a new property to mini-MD. > The property is as described in the attached document. > > This case requests a release binding of for minor/micro for any > firmware changes and minor/micro/patch for any OS changes. > > > -- > 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_Lfalt831zMBCKBXoXbWDoA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Why is this property added to mini-MD and not Guest MD?

Regards,
Sunit

Hitendra Zhangada wrote:

I am sponsoring this self-review case for Fred Gotwald and
Mir Jamal Hyder. This case add a new property to mini-MD.
The property is as described in the attached document.

This case requests a release binding of for minor/micro for any
firmware changes and minor/micro/patch for any OS changes.
-- 
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_Lfalt831zMBCKBXoXbWDoA)-- From sacadmin Fri Dec 14 21:58:04 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBF5w4u6002782 for ; Fri, 14 Dec 2007 21:58:04 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBF5w4hB004561 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Fri, 14 Dec 2007 21:58:04 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT200E01TWSLW00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 14 Dec 2007 21:58:04 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT200CMJTWS6R20@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 14 Dec 2007 21:58:04 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBF5w4Yp010915; Fri, 14 Dec 2007 21:58:04 -0800 (PST) Received: from [192.168.0.6] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBF5w3DZ021595; Fri, 14 Dec 2007 21:58:03 -0800 (PST) Date: Fri, 14 Dec 2007 21:58:00 -0800 From: David Kahn Subject: Re: Self-Review : 2007/696 - _boot-script property in mini-Md To: Hitendra Zhangada Cc: Firmware ARC Message-id: <47636CE8.8000603@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.9 (Windows/20071031) Status: RO Content-Length: 1192 What's with the underscore? Why isn't the name just "boot-script"? I'm not sure this is well defined. When does OBP run it and what state is OBP in when it's run? Is probing done, is the console installed, has banner been done? 2002/228 doesn't really provide enough detail either and we may have overlooked that since it seemed to be a one-off implementation. Also the description in that case talks about registers that aren't existent here. One might say that it's run in place of boot-command, but even that is vague. Is this supposed to be something like nvramrc? Why is this needed? Why can't existing facilities be used instead? Please demote this to fast-track at least until these questions are answered. This does not qualify as a self-review case with the information that's been provided. It's not obvious and trivial to me. -David Hitendra Zhangada wrote: > I am sponsoring this self-review case for Fred Gotwald and > Mir Jamal Hyder. This case add a new property to mini-MD. > The property is as described in the attached document. > > This case requests a release binding of for minor/micro for any > firmware changes and minor/micro/patch for any OS changes. > > From sacadmin Sat Dec 15 08:27:45 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 lBFGRi9H024449 for ; Sat, 15 Dec 2007 08:27:44 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBFGRb9Q015467 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Sun, 16 Dec 2007 00:27:43 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT30000DN239O00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sat, 15 Dec 2007 08:27:39 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT300MFSN23HY30@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sat, 15 Dec 2007 08:27:39 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBFGRdBP000419 for ; Sat, 15 Dec 2007 08:27:39 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT300001MXPZ400@fe-sfbay-09.sun.com> (original mail from Fred.Gotwald@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Sat, 15 Dec 2007 08:27:39 -0800 (PST) Received: from [129.153.85.35] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT3000FSN1RI800@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sat, 15 Dec 2007 08:27:39 -0800 (PST) Date: Sat, 15 Dec 2007 08:27:27 -0800 From: Fred Gotwald Subject: Re: Self-Review : 2007/696 - _boot-script property in mini-Md In-reply-to: <47632CC2.80803@sun.com> Sender: Fred.Gotwald@sun.com To: Hitendra Zhangada Cc: Firmware ARC Reply-to: Fred.Gotwald@sun.com Message-id: <4764006F.8040005@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47632CC2.80803@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 377 Hitendra Zhangada wrote: > I am sponsoring this self-review case for Fred Gotwald and > Mir Jamal Hyder. This case add a new property to mini-MD. I think a better description would be to use the term "updates MD" instead of mini-MD. The "updates MD" is passed over the var-config-backup domain service from vbsc to Openboot in response to the VAR_CONFIG_UPDATES_REQ command. From sacadmin Sun Dec 16 13:23:19 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 lBGLNJkM003464 for ; Sun, 16 Dec 2007 13:23:19 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBGLNJR3035414 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Sun, 16 Dec 2007 14:23:19 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT500D03VES9T00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 14:23:16 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT500CD6VERF700@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 14:23:15 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBGLNFtx006492 for ; Sun, 16 Dec 2007 13:23:15 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT500K01VAAP400@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 13:23:14 -0800 (PST) Received: from [192.168.2.5] ([71.136.76.23]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT5009ZXVEQMZE0@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 13:23:14 -0800 (PST) Date: Sun, 16 Dec 2007 13:24:58 -0800 From: Hitendra Zhangada Subject: Re: Self-Review : 2007/696 - _boot-script property in mini-Md In-reply-to: <476357B9.20108@Sun.Com> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <476597AA.1080102@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_QkGpg/Ur7uHpBHQB3jCPOQ)" X-PMX-Version: 5.2.0.264296 References: <47632CC2.80803@sun.com> <476357B9.20108@Sun.Com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 3954 This is a multi-part message in MIME format. --Boundary_(ID_QkGpg/Ur7uHpBHQB3jCPOQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Sunit Jain wrote: > > Why is this property added to mini-MD and not Guest MD? Because GuestMD does not get updated on every reboot. We need a way to get the boot_script updated on every reboot - both power-on and sort resets. This is very much like LDOM variables. FYI. Similar property exists in GuestMD already. This change will move it from GuestMD to mini-MD. I did not identify this in the proposal since the property was never presented to ARC. So, I am treating it as a new property inside of min-MD. > > Regards, > Sunit > > > Hitendra Zhangada wrote: >> I am sponsoring this self-review case for Fred Gotwald and >> Mir Jamal Hyder. This case add a new property to mini-MD. >> The property is as described in the attached document. >> >> This case requests a release binding of for minor/micro for any >> firmware changes and minor/micro/patch for any OS changes. >> >> >> -- >> 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. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu --Boundary_(ID_QkGpg/Ur7uHpBHQB3jCPOQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Sunit Jain wrote:

Why is this property added to mini-MD and not Guest MD?

Because GuestMD does not get updated on every reboot.
We need a way to get the boot_script updated on every
reboot - both power-on and sort resets.

This is very much like LDOM variables.

FYI. Similar property exists in GuestMD already. This change
will move it from GuestMD to mini-MD. I did not identify this in
the proposal since the property was never presented to ARC.
So, I am treating it as a new property inside of min-MD.

Regards,
Sunit

Hitendra Zhangada wrote:
I am sponsoring this self-review case for Fred Gotwald and
Mir Jamal Hyder. This case add a new property to mini-MD.
The property is as described in the attached document.

This case requests a release binding of for minor/micro for any
firmware changes and minor/micro/patch for any OS changes.
-- 
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.
Work Ph# (858) 625 3757, Ext. x53757
SUN Internal homepage http://esp.west/~hitu

--Boundary_(ID_QkGpg/Ur7uHpBHQB3jCPOQ)-- From sacadmin Sun Dec 16 13:37:47 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 lBGLbl1V003502 for ; Sun, 16 Dec 2007 13:37:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBGLblde010834 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Sun, 16 Dec 2007 13:37:47 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT500H01W2ZSW00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 13:37:47 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT500F8JW2ZD3A0@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 13:37:47 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBGLbl6l006771 for ; Sun, 16 Dec 2007 13:37:47 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT500101VVRDB00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 13:37:47 -0800 (PST) Received: from [129.150.32.39] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT5000NGW2YND00@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 13:37:47 -0800 (PST) Date: Sun, 16 Dec 2007 13:39:30 -0800 From: Hitendra Zhangada Subject: Re: Self-Review : 2007/696 - _boot-script property in mini-Md In-reply-to: <47636CE8.8000603@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <47659B12.6010803@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: <47636CE8.8000603@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 3601 David Kahn wrote: > > What's with the underscore? Why isn't the name > just "boot-script"? > Because we need a way to call out properties which are not LDOM variables. mini-MD would have LDOM variables in them. We don't want to call it boot-script and having it confused with a future need for a variable name called boot-script. We currently have _delete property for the same reason (see FWARC/2007/294 for details). > I'm not sure this is well defined. When does OBP > run it and what state is OBP in when it's run? > Is probing done, is the console installed, has > banner been done? > The concept of boot script is not new. We have been using this for many years now, at least since 2002. The proposed change simply presents the "boot script" to OpenBoot is the mini-MD (or update MD as Fred called it out). > 2002/228 doesn't really provide enough detail > either and we may have overlooked that since it > seemed to be a one-off implementation. Also > the description in that case talks about registers > that aren't existent here. As I said earlier, OpenBoot supports "boot script" for a while. This is not new. That said, the boot scripts are interpreted just before Solaris boot. I think some mention of that is in the 2002/228 case. > > One might say that it's run in place of boot-command, > but even that is vague. Is this supposed to be > something like nvramrc? Why is this needed? > Why can't existing facilities be used instead? It is not in NVRAMRC since boot scripts are one time deal. We don't want it to persist. They are interpreted by OpenBoot just once, not on every resets (that is the bug currently present on ALL sun4v platforms - see below). > > Please demote this to fast-track at least until > these questions are answered. This does not > qualify as a self-review case with the information > that's been provided. It's not obvious and trivial > to me. Sure we can demote it to fast-track but IMO, that is because of lack of knowledge on your part on how this works. As I mentioned earlier, this has been around for last 5 years, nothing new. All of sun4v systems also have this and they get it from guestMD. The problem with guestMD is that those are not updates on every resets. We need a way to get them updated just once. Current implementation is buggy and we have lived with that bug for Huron. We would like to fix that for Maramba and hence this change. See http://monaco.sfbay/detail.jsp?cr=6639912 for the details of the bug. Please note that, Fred, Jamal or I do not want to re-visit how boot scripts are supposed to work or the definition of it at this time. That's too much of asking from them for this bug fix. Also, time spent to revisiting it will mean customer will suffer with this issue for Maramba as well (not good). If you still think this is a fast-track then I will change as such. What will this mean is that big fix can not be integrated until after the winter break (we were hoping to get it integrated by Tuesday). Thanks. > > -David > > > Hitendra Zhangada wrote: >> I am sponsoring this self-review case for Fred Gotwald and >> Mir Jamal Hyder. This case add a new property to mini-MD. >> The property is as described in the attached document. >> >> This case requests a release binding of for minor/micro for any >> firmware changes and minor/micro/patch for any OS changes. >> >> -- 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 From sacadmin Sun Dec 16 13:39:45 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 lBGLditL003515 for ; Sun, 16 Dec 2007 13:39:44 -0800 (PST) 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 lBGLdi0W038000 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Sun, 16 Dec 2007 14:39:44 -0700 (MST) 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 <0JT500001W68ZS00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 13:39:44 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT500L10W67FOC0@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 13:39:44 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBGLdhw4006822 for ; Sun, 16 Dec 2007 13:39:43 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT500101VVRDB00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 13:39:43 -0800 (PST) Received: from [129.150.32.39] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT5000S1W66ND00@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 13:39:43 -0800 (PST) Date: Sun, 16 Dec 2007 13:41:27 -0800 From: Hitendra Zhangada Subject: Re: Self-Review : 2007/696 - _boot-script property in mini-Md In-reply-to: <4764006F.8040005@Sun.COM> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <47659B87.7000501@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47632CC2.80803@sun.com> <4764006F.8040005@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 892 Fred Gotwald wrote: > Hitendra Zhangada wrote: >> I am sponsoring this self-review case for Fred Gotwald and >> Mir Jamal Hyder. This case add a new property to mini-MD. > > I think a better description would be to use the term "updates > MD" instead of mini-MD. The "updates MD" is passed over the > var-config-backup domain service from vbsc to Openboot in response > to the VAR_CONFIG_UPDATES_REQ command. FYI. I used "mini-MD" since that's what is called out in FWARC/2007/294. So, from ARC stand point it is called "mini-MD" until we modify that. That said, I have no problem calling it "update MD" but I don't want to confuse FWARC with it either. Thanks. -- 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 From sacadmin Sun Dec 16 14:57:47 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 lBGMvliI004480 for ; Sun, 16 Dec 2007 14:57:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBGMvkLv023911 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Sun, 16 Dec 2007 14:57:47 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT500L05ZSBZJ00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 14:57:47 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT500J7PZSAA820@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 14:57:46 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBGMvjYU063888; Sun, 16 Dec 2007 14:57:45 -0800 (PST) Received: from [192.168.0.4] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBGMvjRw010875; Sun, 16 Dec 2007 14:57:45 -0800 (PST) Date: Sun, 16 Dec 2007 14:57:44 -0800 From: David Kahn Subject: Re: Self-Review : 2007/696 - _boot-script property in mini-Md To: Hitendra Zhangada Cc: Firmware ARC Message-id: <4765AD68.3000004@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.9 (Windows/20071031) Status: RO Content-Length: 2971 Hitendra Zhangada wrote: > David Kahn wrote: >> >> What's with the underscore? Why isn't the name >> just "boot-script"? >> > > Because we need a way to call out properties which are not > LDOM variables. mini-MD would have LDOM variables in them. > We don't want to call it boot-script and having it confused with > a future need for a variable name called boot-script. We currently > have _delete property for the same reason (see FWARC/2007/294 for details). As far as I know there's nothing in that interface that defines properties starting with _ as special. _delete was defined that way as I recall. If you want properties in the mini-MD to have special attributes associated with them, you should be able to do that either by 1) the definition of the property, or 2) the definition of the node where the property lives or other methods. > The concept of boot script is not new. We have been > using this for many years now, at least since 2002. The case you cited was a one-off for Stilleto as far as I understood it. >> 2002/228 doesn't really provide enough detail >> either and we may have overlooked that since it >> seemed to be a one-off implementation. Also >> the description in that case talks about registers >> that aren't existent here. > > As I said earlier, OpenBoot supports "boot script" for > a while. This is not new. That said, the boot scripts > are interpreted just before Solaris boot. I think some > mention of that is in the 2002/228 case. I didn't see it. To me, it's not well-defined by the materials cited by this case or 228. > Sure we can demote it to fast-track but IMO, that is > because of lack of knowledge on your part on how > this works. Right. I haven't inspected the code to see how it works, but I've read the material in this case and in 2002/228 and I still don't know what the exact specification is for it. That's a problem for this case. You shouldn't have to inspect the code, or know what the implementation is in order to completely understand what the specification is. > Please note that, Fred, Jamal or I do not want to re-visit > how boot scripts are supposed to work or the definition > of it at this time. That's too much of asking from them > for this bug fix. Also, time spent to revisiting it will > mean customer will suffer with this issue for Maramba > as well (not good). I don't want to revisit anything either, but I simply am asking that this specification be complete and document exactly what the specification of boot-script is and when it is run and what the interaction is with anything else that's currently defined. That is not too much to ask. > If you still think this is a fast-track then I will change > as such. What will this mean is that big fix can not > be integrated until after the winter break (we were hoping > to get it integrated by Tuesday). It's not self-review IMO. As to how fast you get it done, that's up to you and the project team. -David From sacadmin Sun Dec 16 15:23:45 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 lBGNNiao004651 for ; Sun, 16 Dec 2007 15:23:45 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBGNNcEN001894 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Mon, 17 Dec 2007 07:23:43 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT600H010ZIRA00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 15:23:42 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT600AA90ZIXX50@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 15:23:42 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBGNNfvo009127 for ; Sun, 16 Dec 2007 15:23:41 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT6000010WZNM00@fe-sfbay-09.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 15:23:41 -0800 (PST) Received: from [192.168.2.5] ([71.136.76.23]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT600CJB0ZH4EF0@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 16 Dec 2007 15:23:41 -0800 (PST) Date: Sun, 16 Dec 2007 15:25:25 -0800 From: Hitendra Zhangada Subject: Re: Self-Review : 2007/696 - _boot-script property in mini-Md In-reply-to: <4765AD68.3000004@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <4765B3E5.6020500@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: <4765AD68.3000004@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 5212 David Kahn wrote: > > Hitendra Zhangada wrote: >> David Kahn wrote: >>> >>> What's with the underscore? Why isn't the name >>> just "boot-script"? >>> >> >> Because we need a way to call out properties which are not >> LDOM variables. mini-MD would have LDOM variables in them. >> We don't want to call it boot-script and having it confused with >> a future need for a variable name called boot-script. We currently >> have _delete property for the same reason (see FWARC/2007/294 for >> details). > > As far as I know there's nothing in that interface > that defines properties starting with _ as special. > _delete was defined that way as I recall. > > If you want properties in the mini-MD to have special > attributes associated with them, you should be able to > do that either by 1) the definition of the property, > or 2) the definition of the node where the property > lives or other methods. #1, definition of the property is what we choose to do in this case. Each property has a meaning. _boot-script has a meaning as defined by this case. Underscore is chosen so that "boot-script" can be used in future for a different purpose such as LDOM variable. > > >> The concept of boot script is not new. We have been >> using this for many years now, at least since 2002. > > The case you cited was a one-off for Stilleto as > far as I understood it. No, boot script support is present in all sun4v platforms and many more. > >>> 2002/228 doesn't really provide enough detail >>> either and we may have overlooked that since it >>> seemed to be a one-off implementation. Also >>> the description in that case talks about registers >>> that aren't existent here. >> >> As I said earlier, OpenBoot supports "boot script" for >> a while. This is not new. That said, the boot scripts >> are interpreted just before Solaris boot. I think some >> mention of that is in the 2002/228 case. > > I didn't see it. To me, it's not well-defined by > the materials cited by this case or 228. It may not be well defined as you pointed out but this case is not defining that either. This case is defining how the information is passed from SP to OpenBoot. If you prefer I can add a line stating that the script is interpreted after probe and before boot command (or something like that). > >> Sure we can demote it to fast-track but IMO, that is >> because of lack of knowledge on your part on how >> this works. > > Right. I haven't inspected the code to see how > it works, but I've read the material in this case > and in 2002/228 and I still don't know what the > exact specification is for it. That's a problem > for this case. This property clearly states that this property contains a string which is literally interpreted by OpenBoot. As said above, I can add that the interpretation happens after probe and before booting Solaris. Is that sufficient? Or would you like to see more? Please do advise. > > You shouldn't have to inspect the code, or know > what the implementation is in order to completely > understand what the specification is. I agree with what you are saying. I thought the interface defined by this case was straight forward and clearly defined. That's why I choose to go with self-review case. I don't want you to look at the code. I want you and other members to understand that this is a string property interpreted by OpenBoot before Solaris boot phase. Isn't that simple? Just one property is being defined here which IMO was very clear (to me at least). > >> Please note that, Fred, Jamal or I do not want to re-visit >> how boot scripts are supposed to work or the definition >> of it at this time. That's too much of asking from them >> for this bug fix. Also, time spent to revisiting it will >> mean customer will suffer with this issue for Maramba >> as well (not good). > > I don't want to revisit anything either, but I simply > am asking that this specification be complete and > document exactly what the specification of boot-script > is and when it is run and what the interaction is with > anything else that's currently defined. That is not too > much to ask. It is not too much, as I said above, I can tighten it up. If that's not enough then please do let me know what else is needed here. > >> If you still think this is a fast-track then I will change >> as such. What will this mean is that big fix can not >> be integrated until after the winter break (we were hoping >> to get it integrated by Tuesday). > > It's not self-review IMO. As to how fast you get it done, > that's up to you and the project team. > Ok, I will change it to fast-track tomorrow. IMO, one-week review for this one property is too much for this bug fix but if that's how process goes then let that be. Thanks for your comments. Let me know if you have more questions or any other suggestions. You help or other member's help is appreciated to get this quickly so that we can have the fix for Maramba (and also Huron as a patch). -- 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 From sacadmin Mon Dec 17 00:33:58 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBH8Xv2T011545 for ; Mon, 17 Dec 2007 00:33:58 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBH8Xmlo005627 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Mon, 17 Dec 2007 16:33:57 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT600M1XQGI8C00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 17 Dec 2007 01:33:54 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT600LJKQGIUD20@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 17 Dec 2007 01:33:54 -0700 (MST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBH8XrMp018998; Mon, 17 Dec 2007 00:33:53 -0800 (PST) Received: from [192.168.0.4] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBH8XqKI017978; Mon, 17 Dec 2007 00:33:53 -0800 (PST) Date: Mon, 17 Dec 2007 00:33:52 -0800 From: David Kahn Subject: Re: Self-Review : 2007/696 - _boot-script property in mini-Md To: Hitendra Zhangada Cc: Firmware ARC Message-id: <47663470.7000009@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.9 (Windows/20071031) Status: RO Content-Length: 2179 Hitendra Zhangada wrote: > #1, definition of the property is what we choose to do in > this case. Each property has a meaning. _boot-script has > a meaning as defined by this case. Underscore is chosen > so that "boot-script" can be used in future for a different > purpose such as LDOM variable. How would "boot-script" and "_boot-script" interact? It's a rhetorical question here, but something you should consider if you define a "boot-script" ldoms variable in the future. > It may not be well defined as you pointed out but > this case is not defining that either. This case is > defining how the information is passed from SP > to OpenBoot. If you prefer I can add a line stating > that the script is interpreted after probe and before > boot command (or something like that). If that's what it is, something like this: The contents of "boot-script" (or "_boot-script") if non-NULL are interpreted prior to interpreting the contents of the nvram variable "boot-command". [boot-command is well defined and the sequence of when it runs is well defined in IEEE 1275-1994] ... works for me. That's a reasonable definition that isn't present in 2002/228. Still some questions about how it gets set on the SC side, and if it's a one-time setting that automatically gets reset once done, or if it's something else. Is that covered by a different case? (What are we using this for, anyway?) > Is that sufficient? Or would you like to see more? > Please do advise. All it needs is the definition (specification) of exactly when it's interpreted. If there's any other special treatment for it, that needs to be included as well. (We don't want to guess or look at the code to figure out what the specification is.) > IMO, one-week review for this one property is too much > for this bug fix but if that's how process goes then let that be. Once we see the updated specification, if it looks ok to everybody we don't have to wait the full week for approval. We can vote by email after any discussion on the updated text. I don't want to delay anybody from doing the right thing, I just want to make sure it's well specified before we approve it. Thanks, David From sacadmin Mon Dec 17 10:18:38 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 lBHIIbUp022194 for ; Mon, 17 Dec 2007 10:18:38 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBHIIQM4003819 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Mon, 17 Dec 2007 18:18:36 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT70060DHIXPG00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 17 Dec 2007 10:18:33 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT7001W4HIXMU80@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 17 Dec 2007 10:18:33 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBHIIXcR027029 for ; Mon, 17 Dec 2007 10:18:33 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT700H01H7TE300@fe-sfbay-09.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 17 Dec 2007 10:18:33 -0800 (PST) Received: from [129.150.37.109] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT700MXXHIWF8E0@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 17 Dec 2007 10:18:33 -0800 (PST) Date: Mon, 17 Dec 2007 10:20:16 -0800 From: Hitendra Zhangada Subject: Re: Self-Review : 2007/696 - _boot-script property in mini-Md In-reply-to: <47663470.7000009@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <4766BDE0.9070209@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: <47663470.7000009@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 3536 David Kahn wrote: > > > Hitendra Zhangada wrote: > > >> #1, definition of the property is what we choose to do in >> this case. Each property has a meaning. _boot-script has >> a meaning as defined by this case. Underscore is chosen >> so that "boot-script" can be used in future for a different >> purpose such as LDOM variable. > > How would "boot-script" and "_boot-script" interact? > It's a rhetorical question here, but something you > should consider if you define a "boot-script" ldoms > variable in the future. Sure will do. > >> It may not be well defined as you pointed out but >> this case is not defining that either. This case is >> defining how the information is passed from SP >> to OpenBoot. If you prefer I can add a line stating >> that the script is interpreted after probe and before >> boot command (or something like that). > > If that's what it is, something like this: > > The contents of "boot-script" (or "_boot-script") > if non-NULL are interpreted prior to interpreting > the contents of the nvram variable "boot-command". > > [boot-command is well defined and the sequence of > when it runs is well defined in IEEE 1275-1994] > > ... works for me. That's a reasonable definition that > isn't present in 2002/228. Ok, I can add some text accordingly. > > Still some questions about how it gets set on the > SC side, and if it's a one-time setting that automatically > gets reset once done, or if it's something else. > Is that covered by a different case? (What are we > using this for, anyway?) > ALOM have a CLI called "bootmode". It is described in the ALOM CLI guides available to customers. It has an option to set bootscript. So, that's how it is used on the SP side. I am not aware of any ARC case for it other than one filed long time a go but was later withdrawn. http://sac.sfbay/FWARC/2004/001/inception.materials/ALOM-CLIFuncSpec_v0.5.pdf Note that the CLI we ship do not exactly match to this specification. The CLI does match following CLI guide, http://dlc.sun.com/pdf/819-7981-11/819-7981-11.pdf I could not find any approved ARC case for ALOM CLIs. I think this is a general meta issue. I just want to emphasize that this case does not change the CLI but instead, takes "bootscript" and "reset_nvram" options and passes them to OpenBoot in the new string variable. This is already working from guestMD but it has issues as described by the bug/CR I referenced earlier. > >> Is that sufficient? Or would you like to see more? >> Please do advise. > > All it needs is the definition (specification) of > exactly when it's interpreted. If there's any other > special treatment for it, that needs to be included > as well. (We don't want to guess or look at the > code to figure out what the specification is.) Ok, I will provide one later today (in couple of hours). > > >> IMO, one-week review for this one property is too much >> for this bug fix but if that's how process goes then let that be. > > Once we see the updated specification, if it looks ok to > everybody we don't have to wait the full > week for approval. We can vote by email after any discussion > on the updated text. I don't want to delay anybody from > doing the right thing, I just want to make sure it's well > specified before we approve it. Thank! > > Thanks, > David -- 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 From sacadmin Mon Dec 17 17:45: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 lBI1jknv005886 for ; Mon, 17 Dec 2007 17:45:46 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBI1jhe0000546 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 18 Dec 2007 01:45:45 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT8003012884A00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 17 Dec 2007 17:45:44 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT800MUP288OX20@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 17 Dec 2007 17:45:44 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBI1jixf023211 for ; Mon, 17 Dec 2007 17:45:44 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT800H0127ENW00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 17 Dec 2007 17:45:43 -0800 (PST) Received: from [129.150.37.109] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT800IC5286D6F0@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 17 Dec 2007 17:45:43 -0800 (PST) Date: Mon, 17 Dec 2007 17:47:26 -0800 From: Hitendra Zhangada Subject: Fast-track : 2007/696 - _boot-script property in "Update MD" In-reply-to: <4766BDE0.9070209@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <476726AE.8070601@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_vf61lLnMBQAR6JdafepDkQ)" X-PMX-Version: 5.2.0.264296 References: <47663470.7000009@sun.com> <4766BDE0.9070209@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 4131 This is a multi-part message in MIME format. --Boundary_(ID_vf61lLnMBQAR6JdafepDkQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT As requested I am converting this case into a fast-track case. There are two changes. One is cosmetic change to what we have been calling "mini MD". It is changed to "Update MD". Second is the real change. I have added little more description as David had suggested. The proposal file is copied at, http://sac.sfbay/FWARC/2007/696/materials/boot-script_property.txt and also attached. Please do let us know if you have any further questions. Since I am sending this out today, the timer should set to next Monday but I would like to get this case time-out by this Thursday since next week is winter break and if possible Jamal and Fred would like to get their changes in by early Friday. So, timer is set to December 20, 2007. If anyone needs more time to review then let me know. IAM file is updated to mark this case as fasttrack and with timer for Thursday. Thanks. -- 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_vf61lLnMBQAR6JdafepDkQ) Content-type: text/plain; name=boot-script_property.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=boot-script_property.txt Date : 12/17/2007 Version : 1.0 Title : _boot-script property in Update MD Modifications to the "mini MD" described in FWARC/2007/294. #1 The name "mini MD" as described by FWARC/2007/294 is modified for clarity to "Update MD". The "Update MD" is defined as follows. Update MD - updates to MD passed to OpenBoot by vBSC upon request (part of domain service) The term "mini MD" is also used for some other purpose and causes confusion. The new name is more appropriate to describe the intended purpose. This name change do not change any interfaces. The name of the MD itself are not part of any other interfaces either. #2 New properties called "_boot-script" is added to the "Update MD". The contents of "_boot-script" if non-NULL are interpreted after device probe phase and prior to decision to automatically boot is made. Thus, if the string property is present then it will be interpreted by OpenBoot prior to interpreting the contents of either "boot-command" or "reboot-command" variables or reboot parameter buffer. Name Tag Required? Description --------------------------------------------------------------------- _boot-script PROP_STR No A string property, if present, is interpreted by OpenBoot. The string consists of one or more OpenBoot words which are interpreted by OpenBoot. See FWARC/2002/228 for details on concept of boot script Interface Table : Imported Interfaces : Interface Classification Comments ==================================================================== sun4v Machine Sun Private MD nodes definitions as Description nodes defined by FWARC/2005/115 Domain Services Sun Private Defined by FWARC/2006/055 Specification (Includes description of Variables DS) mini-MD Sun Private Defined by FWARC/2007/294 Exported Interfaces: Interface Classification Comments ==================================================================== "_boot-script" Sun Private String property in Update MD as described above --Boundary_(ID_vf61lLnMBQAR6JdafepDkQ)-- From sacadmin Mon Dec 17 18:59:59 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBI2xxt7007883 for ; Mon, 17 Dec 2007 18:59:59 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBI2xxdn004980 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Mon, 17 Dec 2007 18:59:59 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT800E015NZAM00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 17 Dec 2007 19:59:59 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT800DD75NYT2B0@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 17 Dec 2007 19:59:58 -0700 (MST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBI2xwfP056606; Mon, 17 Dec 2007 18:59:58 -0800 (PST) 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 lBI2xvbU039537; Mon, 17 Dec 2007 18:59:57 -0800 (PST) Date: Mon, 17 Dec 2007 18:59:57 -0800 From: David Kahn Subject: Re: Fast-track : 2007/696 - _boot-script property in "Update MD" To: Hitendra Zhangada Cc: Firmware ARC Message-id: <476737AD.3070807@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.9 (Windows/20071031) Status: RO Content-Length: 25 LGTM. Thanks, -David From sacadmin Wed Dec 19 21:02: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 lBK525qZ011991 for ; Wed, 19 Dec 2007 21:02:05 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBK5258J005068 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Wed, 19 Dec 2007 22:02:05 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTC00K050NHID00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 22:02:05 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTC001060NGWG70@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 22:02:04 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBK524gu028951 for ; Wed, 19 Dec 2007 21:02:04 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTC00M010K9CQ00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 21:02:04 -0800 (PST) Received: from [192.168.2.6] ([71.136.55.140]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTC001ZM0NDTOA0@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 21:02:01 -0800 (PST) Date: Wed, 19 Dec 2007 21:03:45 -0800 From: Hitendra Zhangada Subject: One more addition to the "Update MD" (2007/696) Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <4769F7B1.3080600@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 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 2058 While implementing the boot-script changes, one potential problem was uncovered (thanks to Tarl). This has to do with "bootmode reset_nvram" command from ALOM (SP). This bug has been around for all sun4v platforms. While we are fixing boot-script code we can take care of this potential issue as well. The problem is that, above CLI will result into vBSC passing "set-defaults" to OpenBoot but that gets evaluated by OpenBoot along with the boot-script just before "boot". The intended use of "reset_nvram" is to reset the variables before using them. This can come in handy if someone have some code in nvramrc which breaks their boot or any other variable which may break the boot. "reset_nvram" will force the variable to its factory-default state. I would like to add this to this existing case (or submit a self-review case for it). Any objections to adding this to this case and getting the case timed out by COB tomorrow? Updated specification with above changes added is attached. Thanks. ==== #3 New properties called "_reset-nvram" is added to the "Update MD". This property is of type PROP_STR but property value have no meaning for OpenBoot. The presence of this property tells OpenBoot to reset variables to its factory default settings. OpenBoot should check for the presence of this variable before accessing any of the variables. If this property exists then set all of the variables to its default state. Name Tag Required? Description --------------------------------------------------------------------- _reset-nvram PROP_STR No If present, OpenBoot resets values of all variables to its default values. -- 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 Wed Dec 19 21:04:02 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 lBK542JX012007 for ; Wed, 19 Dec 2007 21:04:02 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBK54132004994 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Wed, 19 Dec 2007 21:04:02 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTC004010QNTI00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 21:03:59 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTC00A5W0QMG3B0@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 21:03:59 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBK53wvA010144 for ; Wed, 19 Dec 2007 21:03:58 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTC000010Q5N800@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 21:03:58 -0800 (PST) Received: from [192.168.2.6] ([71.136.55.140]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTC0012R0QMTOB0@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 21:03:58 -0800 (PST) Date: Wed, 19 Dec 2007 21:05:42 -0800 From: Hitendra Zhangada Subject: One more addition to the "Update MD" (2007/696) Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <4769F826.7090309@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_wkPOr/zlN7yd9T8ANFecEw)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 6178 This is a multi-part message in MIME format. --Boundary_(ID_wkPOr/zlN7yd9T8ANFecEw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT (Re-sending it with the attachment) While implementing the boot-script changes, one potential problem was uncovered (thanks to Tarl). This has to do with "bootmode reset_nvram" command from ALOM (SP). This bug has been around for all sun4v platforms. While we are fixing boot-script code we can take care of this potential issue as well. The problem is that, above CLI will result into vBSC passing "set-defaults" to OpenBoot but that gets evaluated by OpenBoot along with the boot-script just before "boot". The intended use of "reset_nvram" is to reset the variables before using them. This can come in handy if someone have some code in nvramrc which breaks their boot or any other variable which may break the boot. "reset_nvram" will force the variable to its factory-default state. I would like to add this to this existing case (or submit a self-review case for it). Any objections to adding this to this case and getting the case timed out by COB tomorrow? Updated specification with above changes added is attached. Thanks. ==== #3 New properties called "_reset-nvram" is added to the "Update MD". This property is of type PROP_STR but property value have no meaning for OpenBoot. The presence of this property tells OpenBoot to reset variables to its factory default settings. OpenBoot should check for the presence of this variable before accessing any of the variables. If this property exists then set all of the variables to its default state. Name Tag Required? Description --------------------------------------------------------------------- _reset-nvram PROP_STR No If present, OpenBoot resets values of all variables to its default values. -- 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_wkPOr/zlN7yd9T8ANFecEw) Content-type: text/plain; name=boot-script_property.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=boot-script_property.txt Date : 12/19/2007 Version : 1.1 Title : _boot-script and _rest-nvram properties in Update MD Modifications to the "mini MD" described in FWARC/2007/294. #1 The name "mini MD" as described by FWARC/2007/294 is modified for clarity to "Update MD". The "Update MD" is defined as follows. Update MD - updates to MD passed to OpenBoot by vBSC upon request (part of domain service) The term "mini MD" is also used for some other purpose and causes confusion. The new name is more appropriate to describe the intended purpose. This name change do not change any interfaces. The name of the MD itself are not part of any other interfaces either. #2 New properties called "_boot-script" is added to the "Update MD". The contents of "_boot-script" if non-NULL are interpreted after device probe phase and prior to decision to automatically boot is made. Thus, if the string property is present then it will be interpreted by OpenBoot prior to interpreting the contents of either "boot-command" or "reboot-command" variables or reboot parameter buffer. Name Tag Required? Description --------------------------------------------------------------------- _boot-script PROP_STR No A string property, if present, is interpreted by OpenBoot. The string consists of one or more OpenBoot words which are interpreted by OpenBoot. See FWARC/2002/228 for details on concept of boot script #3 New properties called "_reset_nvram" is added to the "Update MD". This property is of type PROP_STR but property value have no meaning for OpenBoot. The presence of this property tells OpenBoot to reset variables to its factory default settings. OpenBoot should check for the presence of this variable before accessing any of the variables. If this property exists then set all of the variables to its default state. Name Tag Required? Description --------------------------------------------------------------------- _reset-nvram PROP_STR No If present, OpenBoot resets values of all variables to its default values. Interface Table : Imported Interfaces : Interface Classification Comments ==================================================================== sun4v Machine Sun Private MD nodes definitions as Description nodes defined by FWARC/2005/115 Domain Services Sun Private Defined by FWARC/2006/055 Specification (Includes description of Variables DS) mini-MD Sun Private Defined by FWARC/2007/294 Exported Interfaces: Interface Classification Comments ==================================================================== "_boot-script" Sun Private String property in Update MD as described above "_reset-nvram" Sun Private String property in Update MD as described above --Boundary_(ID_wkPOr/zlN7yd9T8ANFecEw)-- From sacadmin Wed Dec 19 21:30:38 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 lBK5Ucwq012163 for ; Wed, 19 Dec 2007 21:30:38 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBK5UaWZ012150 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Wed, 19 Dec 2007 21:30:38 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTC00M0Z1Z1XV00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 22:30:37 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTC001EJ1YZWH70@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 22:30:35 -0700 (MST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBK5UYv6060383; Wed, 19 Dec 2007 21:30:34 -0800 (PST) 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 lBK5UYJ1002632; Wed, 19 Dec 2007 21:30:34 -0800 (PST) Date: Wed, 19 Dec 2007 21:30:34 -0800 From: David Kahn Subject: Re: One more addition to the "Update MD" (2007/696) To: Hitendra Zhangada Cc: Firmware ARC Message-id: <4769FDFA.5020404@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.9 (Windows/20071031) Status: RO Content-Length: 1032 The proliferation of the underscore names is annoying. (and that's being nice about it.) The specification does not say where in the MD these properties exist. (Which node?) Doesn't the specification need to say which node(s) this stuff can exist in, or do you expect the client to search every node to see if these properties exist? If you're going to specify a node (which seems like the right thing to do) we can specify a new node for this sort of thing and get rid of the underscores. Properties have meaning not only by their name, but by where they exist in the MD, and putting them in their own node does not preclude properties with the same (or different) names from existing in other nodes for different purposes, such as Ldoms variables. I don't think we want to overload existing nodes with this new stuff. That seems like a hack to me. Plus it proliferates the need for the underscore or something to distinguish the namespace. If you solve the problem properly, then we can get rid of the underscores. -David From sacadmin Wed Dec 19 21:49:15 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBK5nEYj012288 for ; Wed, 19 Dec 2007 21:49:15 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBK5n41D009975 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 20 Dec 2007 05:49:13 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTC00C012U06300@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 21:49:12 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTC007H02TZW450@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 21:49:11 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBK5nBqd011344 for ; Wed, 19 Dec 2007 21:49:11 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTC00D012L8YI00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 21:49:11 -0800 (PST) Received: from [129.150.33.119] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTC00JR62TYOLD0@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 21:49:11 -0800 (PST) Date: Wed, 19 Dec 2007 21:50:54 -0800 From: Hitendra Zhangada Subject: Re: One more addition to the "Update MD" (2007/696) In-reply-to: <4769FDFA.5020404@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <476A02BE.70107@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: <4769FDFA.5020404@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 1988 David Kahn wrote: > > The proliferation of the underscore names is > annoying. (and that's being nice about it.) > > The specification does not say where in the MD > these properties exist. (Which node?) Doesn't > the specification need to say which node(s) > this stuff can exist in, or do you expect the > client to search every node to see if these > properties exist? They are in "Update MD" root node. As per the definition in 2007/294, "Update MD" has a root node and some other nodes for variables etc. > The mini-MD contains a root node and then a forward link to either a > variables or a keystore node depending on the service in question. We can add these properties under root node directly or add a new node. In either cases, we could remove underscore from the name. > > If you're going to specify a node (which seems > like the right thing to do) we can specify > a new node for this sort of thing and get rid > of the underscores. Properties have meaning not > only by their name, but by where they exist in > the MD, and putting them in their own node does not > preclude properties with the same (or different) names > from existing in other nodes for different purposes, > such as Ldoms variables. That's not a bad idea either. We can add a node called "bootmode" and add these properties there and remove underscore. What would you prefer? Under root node or new node? Let me talk to Fred and Jamal about it tomorrow. > > I don't think we want to overload existing nodes > with this new stuff. That seems like a hack to me. > Plus it proliferates the need for the underscore > or something to distinguish the namespace. If you > solve the problem properly, then we can get rid > of the underscores. > > -David > > > Thanks. -- 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 From sacadmin Wed Dec 19 22:19:42 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBK6JfNQ012780 for ; Wed, 19 Dec 2007 22:19:41 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBK6JNST000366 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 20 Dec 2007 14:19:40 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTC0030748Q5400@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 23:19:38 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTC001PB48QWE80@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 23:19:38 -0700 (MST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBK6Jckj031763; Wed, 19 Dec 2007 22:19:38 -0800 (PST) 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 lBK6JbY8003453; Wed, 19 Dec 2007 22:19:37 -0800 (PST) Date: Wed, 19 Dec 2007 22:19:37 -0800 From: David Kahn Subject: Re: One more addition to the "Update MD" (2007/696) To: Hitendra Zhangada Cc: Firmware ARC Message-id: <476A0979.3090503@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.9 (Windows/20071031) Status: RO Content-Length: 191 Hitendra Zhangada wrote: > What would you prefer? Under root node or new node? A new node, but I would get input from Greg, Narayan, Balaji, Kevin etc, and see what they think. -David From sacadmin Wed Dec 19 22:47:21 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 lBK6lKKk012882 for ; Wed, 19 Dec 2007 22:47:20 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBK6lIjG009329 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 20 Dec 2007 14:47:19 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTC0090B5ITXR00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 22:47:17 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTC00AW05ITFZE0@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 22:47:17 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBK6lHO5003010 for ; Wed, 19 Dec 2007 22:47:17 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTC00F015IL6F00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 22:47:17 -0800 (PST) Received: from [192.168.2.6] ([71.136.55.140]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTC00LHB5IT73F0@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 19 Dec 2007 22:47:17 -0800 (PST) Date: Wed, 19 Dec 2007 22:49:01 -0800 From: Hitendra Zhangada Subject: Re: One more addition to the "Update MD" (2007/696) In-reply-to: <476A0979.3090503@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <476A105D.5090203@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: <476A0979.3090503@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 1122 David Kahn wrote: > > > Hitendra Zhangada wrote: > >> What would you prefer? Under root node or new node? > > A new node, but I would get input from Greg, Narayan, > Balaji, Kevin etc, and see what they think. > Just want to point of that this is not a general purpose MD. The only consumer is OpenBoot and it is only needed by OpenBoot. The current use has been to convey the LDOM variables. We are trying to use this existing mechanism to pass two additional properties with a specific meaning for each. My preference would be to leave them in the root node of the "Update MD" and let OpenBoot pick up these two properties from there. We can remove the underscore with this approach. Narayan, Kevin, Balaji, does any of you have any suggestion or preference on this? If new node then any suggestion for the name of the node? How about other FWARC members? Any preference? Thanks. -- 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 From sacadmin Thu Dec 20 00:31:54 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 lBK8VrRF014848 for ; Thu, 20 Dec 2007 00:31:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBK8VqNj016238 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 20 Dec 2007 16:31:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTC00F0HAD38U00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 00:31:51 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTC00E86AD12180@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 00:31:49 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBK8VnJh003171; Thu, 20 Dec 2007 00:31:49 -0800 (PST) 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 lBK8Vm71004934; Thu, 20 Dec 2007 00:31:48 -0800 (PST) Date: Thu, 20 Dec 2007 00:31:48 -0800 From: David Kahn Subject: Re: One more addition to the "Update MD" (2007/696) To: Hitendra Zhangada Cc: Firmware ARC Message-id: <476A2874.8070507@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.9 (Windows/20071031) Status: RO Content-Length: 816 Hitendra Zhangada wrote: > My preference would be to leave them in the root node of the > "Update MD" and let OpenBoot pick up these two properties > from there. We can remove the underscore with this approach. We have a tendency to throw everything into the root node. But the MDs are tree (directed graphs, actually) and we can use the structure of the tree to convey information as well. Let's just create a node for this purpose (control of OF, rather than passing of LDOM variables) and all these new things (boot-script, reset-nvram) can go in the new node. We can call it "open-firmware-control" or something like that. (I'm not stuck on that name if you can suggest something better.) Code has to change anyway to find this new stuff, so we might as well do it right. That's all I'm saying. -David From sacadmin Thu Dec 20 05:57:24 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 lBKDvNTa018819 for ; Thu, 20 Dec 2007 05:57:24 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBKDvLYJ006405 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 20 Dec 2007 13:57:22 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTC00I0BPFKEH00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 05:57:20 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTC00G6IPFKAJ50@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 05:57:20 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBKDvKA6014983 for ; Thu, 20 Dec 2007 05:57:20 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTC00601PBW5H00@fe-sfbay-09.sun.com> (original mail from Fred.Gotwald@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 05:57:20 -0800 (PST) Received: from [129.153.85.10] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTC00EU3PFD2Z50@fe-sfbay-09.sun.com>; Thu, 20 Dec 2007 05:57:19 -0800 (PST) Date: Thu, 20 Dec 2007 05:57:12 -0800 From: Fred Gotwald Subject: Re: One more addition to the "Update MD" (2007/696) In-reply-to: <476A2874.8070507@sun.com> Sender: Fred.Gotwald@sun.com To: David Kahn Cc: Hitendra Zhangada , Firmware ARC Reply-to: Fred.Gotwald@sun.com Message-id: <476A74B8.2080909@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <476A2874.8070507@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1645 David Kahn wrote: > > > Hitendra Zhangada wrote: > > >> My preference would be to leave them in the root node of the >> "Update MD" and let OpenBoot pick up these two properties >> from there. We can remove the underscore with this approach. > > We have a tendency to throw everything into the root node. > But the MDs are tree (directed graphs, actually) and we > can use the structure of the tree to convey information > as well. > > Let's just create a node for this purpose (control of OF, > rather than passing of LDOM variables) and all these new > things (boot-script, reset-nvram) can go in the new node. > We can call it "open-firmware-control" or something like > that. (I'm not stuck on that name if you can suggest > something better.) > > Code has to change anyway to find this new stuff, so we > might as well do it right. > > That's all I'm saying. > > -David The backing store does not contain a MD node for each name-value pair, only for the entire domain service. The current code reads the name-value pairs from the backing store and constructs an MD for transmission across the domain service. Since there is no place to store the info about which name-value pairs go in what node, we would have to embed that logic in the code that builds the MD. Yuck! Please resist your sense of aesthetic at the expense of simple code. How about just using a different prefix? Instead of '_', these 2 variables could be prefaced with something like 'ofc_'. Otherwise, I would recommend a new domain service which could specify a different base MD node or extending the backing store so it stores name-value-MD node. From sacadmin Thu Dec 20 06:29:56 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 lBKETtmw019167 for ; Thu, 20 Dec 2007 06:29:56 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBKETppY018163 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 20 Dec 2007 14:29:54 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTC00M2NQXRXV00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 06:29:51 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTC00LXRQXPW020@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 06:29:49 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBKETnGQ064767; Thu, 20 Dec 2007 06:29:49 -0800 (PST) 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 lBKETnLJ010258; Thu, 20 Dec 2007 06:29:49 -0800 (PST) Date: Thu, 20 Dec 2007 06:29:48 -0800 From: David Kahn Subject: Re: One more addition to the "Update MD" (2007/696) In-reply-to: <476A74B8.2080909@Sun.COM> To: Fred.Gotwald@sun.com Cc: Hitendra Zhangada , Firmware ARC Message-id: <476A7C5C.2030305@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <476A2874.8070507@sun.com> <476A74B8.2080909@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 833 Fred Gotwald wrote: > The backing store does not contain a MD node for each name-value pair, > only for the entire domain service. The current code reads the > name-value pairs from the backing store and constructs an MD for > transmission across the domain service. Since there is no place to store > the info about which name-value pairs go in what node, we would have to > embed that logic in the code that builds the MD. My understanding was that these are not variables that have "backing store" like the LDOM variables, so they certainly come from a different place, so unless this is a hack, it should certainly be possible to not just stick all the new stuff in the same MD node where everything is today. If it is a hack, then go figure out a better way to do it. (end to end). Solve the problem properly. -David From sacadmin Thu Dec 20 06:54:50 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBKEsn5F019722 for ; Thu, 20 Dec 2007 06:54:49 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBKEslEI027578 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 20 Dec 2007 14:54:48 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTC00L0VS3B7Y00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 07:54:47 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTC00E0RS3AW050@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 07:54:46 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBKEskds025164 for ; Thu, 20 Dec 2007 06:54:46 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTC00L01S2GAH00@fe-sfbay-09.sun.com> (original mail from Fred.Gotwald@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 06:54:46 -0800 (PST) Received: from [129.153.85.10] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTC009KAS39XY40@fe-sfbay-09.sun.com>; Thu, 20 Dec 2007 06:54:46 -0800 (PST) Date: Thu, 20 Dec 2007 06:54:45 -0800 From: Fred Gotwald Subject: Re: One more addition to the "Update MD" (2007/696) In-reply-to: <476A7C5C.2030305@sun.com> Sender: Fred.Gotwald@sun.com To: David Kahn Cc: Hitendra Zhangada , Firmware ARC Reply-to: Fred.Gotwald@sun.com Message-id: <476A8235.2000601@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <476A2874.8070507@sun.com> <476A74B8.2080909@Sun.COM> <476A7C5C.2030305@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1109 David Kahn wrote: > > > Fred Gotwald wrote: > >> The backing store does not contain a MD node for each name-value pair, >> only for the entire domain service. The current code reads the >> name-value pairs from the backing store and constructs an MD for >> transmission across the domain service. Since there is no place to >> store the info about which name-value pairs go in what node, we would >> have to embed that logic in the code that builds the MD. > > My understanding was that these are not variables that have > "backing store" like the LDOM variables, so they certainly > come from a different place, so unless this is a hack, > it should certainly be possible to not just stick all the > new stuff in the same MD node where everything is today. > > If it is a hack, then go figure out a better way to > do it. (end to end). Solve the problem properly. > > -David These variables are treated as LDOM variables. They are put in the backing store by vbsc, consumed and deleted from the backing store by Openboot using the existing LDOM variable infrastructure. Is that the objection? From sacadmin Thu Dec 20 13:11:22 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 lBKLBLE8002029 for ; Thu, 20 Dec 2007 13:11:21 -0800 (PST) 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 lBKLBJeW057433 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 20 Dec 2007 14:11:21 -0700 (MST) 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 <0JTD008079IWG100@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 13:11:20 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTD002BA9IVIQ20@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 13:11:19 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBKLBJpJ010729 for ; Thu, 20 Dec 2007 13:11:19 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTD00B019BVPE00@fe-sfbay-09.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 13:11:19 -0800 (PST) Received: from [129.153.85.10] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTD00N0C9IU3VF0@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 13:11:19 -0800 (PST) Date: Thu, 20 Dec 2007 13:11:18 -0800 From: Hitendra Zhangada Subject: Re: One more addition to the "Update MD" (2007/696) In-reply-to: <476A7C5C.2030305@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <476ADA76.2030903@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <476A2874.8070507@sun.com> <476A74B8.2080909@Sun.COM> <476A7C5C.2030305@sun.com> User-Agent: Thunderbird 2.0.0.10pre (X11/20071202) Status: RO Content-Length: 3481 David Kahn wrote: > > > Fred Gotwald wrote: > >> The backing store does not contain a MD node for each name-value pair, >> only for the entire domain service. The current code reads the >> name-value pairs from the backing store and constructs an MD for >> transmission across the domain service. Since there is no place to >> store the info about which name-value pairs go in what node, we would >> have to embed that logic in the code that builds the MD. > > My understanding was that these are not variables that have > "backing store" like the LDOM variables, so they certainly > come from a different place, so unless this is a hack, > it should certainly be possible to not just stick all the > new stuff in the same MD node where everything is today. > > If it is a hack, then go figure out a better way to > do it. (end to end). Solve the problem properly. > > -David I had meeting with the project team (Fred and Jamal). I discussed the suggestions proposed on this thread. Here is what project team is proposing and their reasoning. They would like both properties in the "variable" node of the "update MD". The specification did not mention the "variable" node. We can add that to description. Here are the reasoning for it. Note this that this is not a hack but a design choice we are making. 1. _reset-nvram property relates to LDOM variables. It is an instruction to OpenBoot that all variables should be forced to its default settings. This is very much similar to _delete property which tells OpenBoot to set a specific variable to its default value. The difference is ALL vs one variable. If preferred we can change _reset-nvram to _delete-all to make clear this difference. I personally like this since it makes clear what this property is all about. 2. _boot-script property is not a variable but the way we would like to handle it is identical to how we deal with each LDOM variable. Basically, once the property is consumed, it needs to be deleted so that it does not show up upon the subsequent reset/reboot. The current mechanism of ldom-variable-delete allows this to happen very easily. Most of the code is leveraged on both OpenBoot and vBSC side. Moving _boot-script to some other node will mean special treatment for this one property and will result into lot more code changes on both OpenBoot and vBSC. This is least desired option for the project team. More code means more maintenance as well. Code re-use is preferred. 3. As far as I can tell, there are no "boolean" tags in MD. We can change the "boolean" to a VAL with 0 in it. This can be done is we don't want to treat it as a string. I am fine with what project team is proposing. I have also gotten OK from at least one other FWARC member as far as keeping _boot-script in the variables node is concerned. Project team do hope that this is acceptable to FWARC. I am extending the review of this case to Friday after the break (till January 4th). I will send out updated specification later today unless there is still a push back for what project team is proposing. Thanks for review and comments on this case. -- 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 Thu Dec 20 14:55:12 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 lBKMtBLt004758 for ; Thu, 20 Dec 2007 14:55:12 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBKMtAbt017010 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 20 Dec 2007 15:55:11 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTD00603EBZVR00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 14:55:11 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTD001H0EBY7780@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 14:55:10 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBKMtA2J026421; Thu, 20 Dec 2007 14:55:10 -0800 (PST) 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 lBKMt9NM019101; Thu, 20 Dec 2007 14:55:10 -0800 (PST) Date: Thu, 20 Dec 2007 14:55:06 -0800 From: David Kahn Subject: Re: One more addition to the "Update MD" (2007/696) In-reply-to: <476A8235.2000601@Sun.COM> To: Fred.Gotwald@sun.com Cc: Hitendra Zhangada , Firmware ARC Message-id: <476AF2CA.4040209@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <476A2874.8070507@sun.com> <476A74B8.2080909@Sun.COM> <476A7C5C.2030305@sun.com> <476A8235.2000601@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 1280 Sorry, I wasn't available for your meeting. I guess it doesn't matter how you do this. Any method is fine by me. -David Fred Gotwald wrote: > David Kahn wrote: >> >> >> Fred Gotwald wrote: >> >>> The backing store does not contain a MD node for each name-value >>> pair, only for the entire domain service. The current code reads the >>> name-value pairs from the backing store and constructs an MD for >>> transmission across the domain service. Since there is no place to >>> store the info about which name-value pairs go in what node, we would >>> have to embed that logic in the code that builds the MD. >> >> My understanding was that these are not variables that have >> "backing store" like the LDOM variables, so they certainly >> come from a different place, so unless this is a hack, >> it should certainly be possible to not just stick all the >> new stuff in the same MD node where everything is today. >> >> If it is a hack, then go figure out a better way to >> do it. (end to end). Solve the problem properly. >> >> -David > > These variables are treated as LDOM variables. They are put in the > backing store by vbsc, consumed and deleted from the backing store by > Openboot using the existing LDOM variable infrastructure. Is that the > objection? From sacadmin Thu Dec 20 15:08:46 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 lBKN8jjc005091 for ; Thu, 20 Dec 2007 15:08:46 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBKN8J2S015536 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Fri, 21 Dec 2007 07:08:45 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTD0036PEYG9100@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 15:08:40 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTD0022KEYEIKA0@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 15:08:39 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBKN8cSo003199; Thu, 20 Dec 2007 15:08:38 -0800 (PST) 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 lBKN8cC7019448; Thu, 20 Dec 2007 15:08:38 -0800 (PST) Date: Thu, 20 Dec 2007 15:08:37 -0800 From: David Kahn Subject: Re: One more addition to the "Update MD" (2007/696) To: Hitendra Zhangada Cc: Firmware ARC Message-id: <476AF5F5.4090200@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 876 Hitendra Zhangada wrote: > 3. As far as I can tell, there are no "boolean" tags > in MD. We can change the "boolean" to a VAL with > 0 in it. This can be done is we don't want to > treat it as a string. It should probably be PROP_VAL, with the value ignored. I assume that the presence of the property means that it's true, and nvram should be reset? Or do you need a value there? Either way is ok with me. > I am extending the review of this case to Friday after > the break (till January 4th). I will send out updated > specification later today unless there is still a push > back for what project team is proposing. I don't think you need to extend it. Just figure what the p-team wants to do about the prop-type, update the materials, give one more day for review and then let it time out. (unless other fwarc members ask for more time.) -David From sacadmin Thu Dec 20 16:06:34 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 lBL06XqH006080 for ; Thu, 20 Dec 2007 16:06:33 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBL06NJJ007795 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Fri, 21 Dec 2007 08:06:32 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTD00A03HMT2V00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 16:06:29 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTD00171HMT7CD0@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 16:06:29 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBL06T9c019118 for ; Thu, 20 Dec 2007 16:06:29 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTD00901HJN4T00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 16:06:29 -0800 (PST) Received: from [129.153.85.10] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTD0037UHMS7R80@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 16:06:28 -0800 (PST) Date: Thu, 20 Dec 2007 16:06:28 -0800 From: Hitendra Zhangada Subject: Re: One more addition to the "Update MD" (2007/696) In-reply-to: <476AF5F5.4090200@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <476B0384.9060404@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_KnYTXV5mQZ8PyfjK9QHhlA)" X-PMX-Version: 5.2.0.264296 References: <476AF5F5.4090200@sun.com> User-Agent: Thunderbird 2.0.0.10pre (X11/20071202) Status: RO Content-Length: 5904 This is a multi-part message in MIME format. --Boundary_(ID_KnYTXV5mQZ8PyfjK9QHhlA) Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT David Kahn wrote: > > > Hitendra Zhangada wrote: > > > >> 3. As far as I can tell, there are no "boolean" tags >> in MD. We can change the "boolean" to a VAL with >> 0 in it. This can be done is we don't want to >> treat it as a string. > > It should probably be PROP_VAL, with the value ignored. > I assume that the presence of the property means that > it's true, and nvram should be reset? Or do you need > a value there? Either way is ok with me. Talked to Fred and he is fine with PROP_VAL. Changed it. Presence of property means it is true and so no need a value. > >> I am extending the review of this case to Friday after >> the break (till January 4th). I will send out updated >> specification later today unless there is still a push >> back for what project team is proposing. > > I don't think you need to extend it. Just figure what > the p-team wants to do about the prop-type, update the > materials, give one more day for review and then let > it time out. (unless other fwarc members ask for more > time.) Attached is updated specification. It contains following changes since yesterday's version. 1. Changed _reset-nvram to _delete-all 2. Clarified that these properties are under "variables" node of the "Updated MD". 3. _delete-all is of type PROP_VAL. Updated spec. attached and also copied to the materials directory, http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2007/696/materials/Update_MD_Changes.txt I am extending timer to tomorrow, Friday, December 21, 2007. Thanks. -- 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_KnYTXV5mQZ8PyfjK9QHhlA) Content-type: text/plain; name=Update_MD_Changes.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=Update_MD_Changes.txt Date : 12/20/2007 Version : 1.2 Title : "_boot-script" and "_delete-all" properties in variables node under "Update MD" Modifications to the "mini MD" described in FWARC/2007/294. #1 The name "mini MD" as described by FWARC/2007/294 is modified for clarity to "Update MD". The "Update MD" is defined as follows. Update MD - updates to MD passed to OpenBoot by vBSC upon request (part of domain service) The term "mini MD" is also used for some other purpose and causes confusion. The new name is more appropriate to describe the intended purpose. This name change do not change any interfaces. The name of the MD itself are not part of any other interfaces either. #2 New properties called "_boot-script" is added to the "variables" node of the "Update MD". The contents of "_boot-script" if non-NULL are interpreted after device probe phase and prior to decision to automatically boot is made. Thus, if this string property is present then it will be interpreted by OpenBoot prior to interpreting the contents of either "boot-command" or "reboot-command" variables or reboot parameter buffer. Name Tag Required? Description --------------------------------------------------------------------- _boot-script PROP_STR No A string property, if present, is interpreted by OpenBoot. The string consists of one or more OpenBoot words which are interpreted by OpenBoot. See FWARC/2002/228 for details on concept of boot script #3 New properties called "_delete-all" is added to the "variables" node of the "Update MD". This property is of type PROP_VAL but property value have no meaning for OpenBoot. The presence of this property tells OpenBoot to reset variables to its factory default settings. OpenBoot should check for the presence of this variable before accessing any of the variables. If this property exists then set all of the variables to its default state. Name Tag Required? Description --------------------------------------------------------------------- _delete-all PROP_VAL No If present, OpenBoot resets values of all variables to its default values. Interface Table : Imported Interfaces : Interface Classification Comments ==================================================================== sun4v Machine Sun Private MD nodes definitions as Description nodes defined by FWARC/2005/115 Domain Services Sun Private Defined by FWARC/2006/055 Specification (Includes description of Variables DS) mini-MD Sun Private Defined by FWARC/2007/294 Exported Interfaces: Interface Classification Comments ==================================================================== "_boot-script" Sun Private Property in Update MD as described above "_delete-all" Sun Private Property in Update MD as described above --Boundary_(ID_KnYTXV5mQZ8PyfjK9QHhlA)-- From sacadmin Thu Dec 20 17:58:11 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 lBL1wAq9008664 for ; Thu, 20 Dec 2007 17:58:11 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBL1w5F9015268 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Fri, 21 Dec 2007 09:58:09 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTD00209MSWAO00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 18:58:08 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTD00LHUMSVDI10@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 18:58:07 -0700 (MST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBL1w7OU013556; Thu, 20 Dec 2007 17:58:07 -0800 (PST) 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 lBL1w6wA023386; Thu, 20 Dec 2007 17:58:06 -0800 (PST) Date: Thu, 20 Dec 2007 17:58:05 -0800 From: David Kahn Subject: Re: One more addition to the "Update MD" (2007/696) To: Hitendra Zhangada Cc: Firmware ARC Message-id: <476B1DAD.3080204@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 49 Does _delete_all nullify _boot-script? -David From sacadmin Thu Dec 20 18:07:43 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 lBL27hXs008769 for ; Thu, 20 Dec 2007 18:07:43 -0800 (PST) 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 lBL27fsB059706 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 20 Dec 2007 19:07:42 -0700 (MST) 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 <0JTD0070PN8UU000@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 18:07:42 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTD00GW5N8T7KD0@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 18:07:41 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBL27fcN028648 for ; Thu, 20 Dec 2007 18:07:41 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTD00901N3RKK00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 18:07:41 -0800 (PST) Received: from [129.153.85.10] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTD00AWON8S4UA0@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 20 Dec 2007 18:07:41 -0800 (PST) Date: Thu, 20 Dec 2007 18:07:40 -0800 From: Hitendra Zhangada Subject: Re: One more addition to the "Update MD" (2007/696) In-reply-to: <476B1DAD.3080204@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <476B1FEC.6050008@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <476B1DAD.3080204@sun.com> User-Agent: Thunderbird 2.0.0.10pre (X11/20071202) Status: RO Content-Length: 370 David Kahn wrote: > > Does _delete_all nullify _boot-script? > No. _boot-script is not a variable and hence _delete-all does not nullify _boot-script. -- 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 Fri Dec 21 16:38:15 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBM0cEMS000057 for ; Fri, 21 Dec 2007 16:38:15 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBM0c7RF026996 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Sat, 22 Dec 2007 00:38:13 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTF00E0JDRLXV00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 21 Dec 2007 16:38:09 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTF009NTDRILU60@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 21 Dec 2007 16:38:06 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBM0c66A023542 for ; Fri, 21 Dec 2007 16:38:06 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTF00M01DLU9V00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 21 Dec 2007 16:38:06 -0800 (PST) Received: from [129.150.37.162] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTF00LA5DRH3Z10@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 21 Dec 2007 16:38:06 -0800 (PST) Date: Fri, 21 Dec 2007 16:39:50 -0800 From: Hitendra Zhangada Subject: Re: One more addition to the "Update MD" (2007/696) In-reply-to: <476B0384.9060404@Sun.COM> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Message-id: <476C5CD6.9090700@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_I/CR2Fcl0MG1/LDzQxNeBA)" X-PMX-Version: 5.2.0.264296 References: <476AF5F5.4090200@sun.com> <476B0384.9060404@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 2895 This is a multi-part message in MIME format. --Boundary_(ID_I/CR2Fcl0MG1/LDzQxNeBA) Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT Hitendra Zhangada wrote: > Attached is updated specification. It contains > following changes since yesterday's version. > > 1. Changed _reset-nvram to _delete-all > 2. Clarified that these properties are under "variables" > node of the "Updated MD". > 3. _delete-all is of type PROP_VAL. > > Updated spec. attached and also copied to the materials > directory, > > http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2007/696/materials/Update_MD_Changes.txt > > > > I am extending timer to tomorrow, Friday, December 21, 2007. This case has timed out and is approved for minor/micro release for any firmware changes and minor/micro/patch release for any OS changes. Thanks. Happy Holidays to you all! -- 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_I/CR2Fcl0MG1/LDzQxNeBA) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 8BIT Hitendra Zhangada wrote:

Attached is updated specification. It contains
following changes since yesterday's version.

1. Changed _reset-nvram to _delete-all
2. Clarified that these properties are under "variables"
node of the "Updated MD".
3. _delete-all is of type PROP_VAL.

Updated spec. attached and also copied to the materials
directory,

http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2007/696/materials/Update_MD_Changes.txt

I am extending timer to tomorrow, Friday, December 21, 2007.

This case has timed out and is approved for minor/micro release
for any firmware changes and minor/micro/patch release for any
OS changes.

Thanks.

Happy Holidays to you all!

-- 
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_I/CR2Fcl0MG1/LDzQxNeBA)--