You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(11) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(32) |
Feb
(11) |
Mar
(25) |
Apr
(10) |
May
(15) |
Jun
(14) |
Jul
(12) |
Aug
(5) |
Sep
(14) |
Oct
(7) |
Nov
(8) |
Dec
(5) |
2006 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: <Mah...@em...> - 2009-09-16 07:31:43
|
Hello, Following are my comments on the delta document. saHpiResourceIdGet() Test cases need to be retained, to verify the backward comapatibility of the daemon. saHpiResourceFailedRemove() Some more cases shall be addressed: 1. "resource removed" event generation for a non FRU resource 2. "All the nested FRUs shall be removed from the RPT" saHpiResourceFailedRemove() is repeated, and can be deleted. saHpiFumiActivate() Additional functionality toward the support of explicit banks support be tested? Regards Mahesh |
From: Yu, L. L <lin...@in...> - 2007-03-07 18:11:22
|
Hi, Sriram, It seems configuration isn=A1=AFt set correctly before make, please look = at the saftest/HPI-B.01.01/README, which can guide you to configure and = run the test suite. =20 Thanks - Ling =20 ________________________________ From: V S N R Chamarty Sriram-Q17150 [mailto:sri...@mo...]=20 Sent: 2007=C4=EA3=D4=C26=C8=D5 20:51 To: Fu, Elva; Yu, Ling L Subject: SAF HPI tests-reg =20 Hi Elva and Yu, =20 I am requesting your help once again. I am following the instructions in = the pdf file attached to run and install the saf hpi = tests"saftest_HPI-B_01_01_1_0_0.tar.gz" After "make", I am seeing that all the build gor failed and log = directory also contains empty files. I don't have any information. Kindly help me in this regard how to proceed. =20 Thanks Sriram src/sensor/saHpiSensorThresholdsGet/10: build: FAILED src/sensor/saHpiSensorThresholdsGet/1: build: FAILED src/sensor/saHpiSensorThresholdsGet/2: build: FAILED src/sensor/saHpiSensorThresholdsGet/3: build: FAILED src/sensor/saHpiSensorThresholdsGet/4: build: FAILED src/sensor/saHpiSensorThresholdsGet/5: build: FAILED src/sensor/saHpiSensorThresholdsGet/6: build: FAILED src/sensor/saHpiSensorThresholdsGet/7: build: FAILED src/sensor/saHpiSensorThresholdsGet/8: build: FAILED src/sensor/saHpiSensorThresholdsGet/9: build: FAILED src/sensor/saHpiSensorThresholdsSet/10: build: FAILED src/sensor/saHpiSensorThresholdsSet/1: build: FAILED src/sensor/saHpiSensorThresholdsSet/11: build: FAILED src/sensor/saHpiSensorThresholdsSet/12: build: FAILED src/sensor/saHpiSensorThresholdsSet/13: build: FAILED src/sensor/saHpiSensorThresholdsSet/14: build: FAILED src/sensor/saHpiSensorThresholdsSet/2: build: FAILED src/sensor/saHpiSensorThresholdsSet/3: build: FAILED src/sensor/saHpiSensorThresholdsSet/4: build: FAILED src/sensor/saHpiSensorThresholdsSet/5: build: FAILED src/sensor/saHpiSensorThresholdsSet/6: build: FAILED src/sensor/saHpiSensorThresholdsSet/7: build: FAILED src/sensor/saHpiSensorThresholdsSet/8: build: FAILED src/sensor/saHpiSensorThresholdsSet/9: build: FAILED src/sensor/saHpiSensorTypeGet/1: build: FAILED src/sensor/saHpiSensorTypeGet/2: build: FAILED src/sensor/saHpiSensorTypeGet/3: build: FAILED src/sensor/saHpiSensorTypeGet/6: build: FAILED src/sensor/saHpiSensorTypeGet/7: build: FAILED src/sensor/saHpiSensorTypeGet/8: build: FAILED src/sensor/saHpiSensorTypeGet/9: build: FAILED src/session/saHpiDiscover/manual/2: build: FAILED src/session/saHpiDiscover/1: build: FAILED src/session/saHpiDiscover/3: build: FAILED src/session/saHpiSessionClose/1: build: FAILED src/session/saHpiSessionClose/2: build: FAILED src/session/saHpiSessionClose/3: build: FAILED src/session/saHpiSessionOpen/manual/5: build: FAILED src/session/saHpiSessionOpen/1: build: FAILED src/session/saHpiSessionOpen/2: build: FAILED src/session/saHpiSessionOpen/3: build: FAILED src/session/saHpiSessionOpen/4: build: FAILED src/version/saHpiVersionGet/1: build: FAILED src/watchdogtimer/saHpiWatchdogTimerGet/1: build: FAILED src/watchdogtimer/saHpiWatchdogTimerGet/2: build: FAILED src/watchdogtimer/saHpiWatchdogTimerGet/3: build: FAILED src/watchdogtimer/saHpiWatchdogTimerGet/4: build: FAILED src/watchdogtimer/saHpiWatchdogTimerGet/5: build: FAILED src/watchdogtimer/saHpiWatchdogTimerGet/6: build: FAILED src/watchdogtimer/saHpiWatchdogTimerReset/1: build: FAILED src/watchdogtimer/saHpiWatchdogTimerReset/2: build: FAILED src/watchdogtimer/saHpiWatchdogTimerReset/3: build: FAILED src/watchdogtimer/saHpiWatchdogTimerReset/4: build: FAILED src/watchdogtimer/saHpiWatchdogTimerReset/5: build: FAILED src/watchdogtimer/saHpiWatchdogTimerSet/10: build: FAILED src/watchdogtimer/saHpiWatchdogTimerSet/1: build: FAILED src/watchdogtimer/saHpiWatchdogTimerSet/2: build: FAILED src/watchdogtimer/saHpiWatchdogTimerSet/3: build: FAILED src/watchdogtimer/saHpiWatchdogTimerSet/4: build: FAILED src/watchdogtimer/saHpiWatchdogTimerSet/5: build: FAILED src/watchdogtimer/saHpiWatchdogTimerSet/6: build: FAILED src/watchdogtimer/saHpiWatchdogTimerSet/7: build: FAILED src/watchdogtimer/saHpiWatchdogTimerSet/8: build: FAILED src/watchdogtimer/saHpiWatchdogTimerSet/9: build: FAILED make[1]: Leaving directory `/root/saflab/saftest/HPI-B.01.01' root@CP3020:~/saflab/saftest <mailto:root@CP3020:~/saflab/saftest> # ls AUTHORS COPYING ChangeLog HPI-B.01.01 Makefile README doc include = log report.sh run_tests.sh t0 t0.c utilities root@CP3020:~/saflab/saftest <mailto:root@CP3020:~/saflab/saftest> # cd = log/ error_log-HPI-B.01.01 run_log-HPI-B.01.01 root@CP3020:~/saflab/saftest <mailto:root@CP3020:~/saflab/saftest> # cd = log/ |
From: Yu, L. L <lin...@in...> - 2006-09-30 02:41:18
|
SAF Test HPI test suite was partly reviewed by SAF HPI WG and became the = formal "Release of HPI Test Suite (1st phase)" which currently is = waiting the vote for the approval on SA Forum. Welcome to participate in the voting! Thanks - Ling -----Original Message----- From: wor...@sa... [mailto:wor...@sa...] = Sent: 2006=C4=EA9=D4=C226=C8=D5 7:07 To: Yu, Ling L Subject: Groups - saforum - New ballot "Release of HPI Test Suite (1st = phase) Approval" Technical Workgroup member, A new ballot has been presented to Technical Workgroup. To vote on this ballot, go here: http://www.saforum.org/apps/org/workgroup/twg/ballot.php?id=3D180 Please DO NOT REPLY to this email; instead, vote using the above link. The text of this ballot is as follows: --- "Release of HPI Test Suite (1st phase) Approval" The HPI WG submits the HPI Test Suite Phase 1 for approval by the SA = Forum Technical Work Group. Please review and cast your vote to approve, = one vote per company. Upon approval by the TWG, this document will be submitted to the board = for final release approval.=20 This document is available for download at: = http://www.saforum.org/apps/org/workgroup/twg/twg-hardwareplatform/downlo= ad.php/2758/saftest.tar.gz. - Yes - No - Abstain - Other Referenced Items Date Name Type ---- ---- ---- 2006-09-25 = www.saforum.org/apps/org/workgroup/twg/twg-hardwareplatform/download.php/= 2758/saftest.tar.gzReference Document --- The ballot closes Monday, 16 October 2006 @ 17:00 PT. Please vote = before then by visiting: http://www.saforum.org/apps/org/workgroup/twg/ballot.php?id=3D180 Thank you, SA Forum Administration |
From: Yu, L. L <lin...@in...> - 2006-04-29 07:05:16
|
saftest_HPI-B.01.01_1.0.8 is released, please download it from: http://prdownloads.sourceforge.net/saftest/saftest_HPI-B_01_01_1_0_8.tar .gz?download This is bug fix release after HPI-B.01.01_1.0.7. In this release: - Great work from UNH team, most of the bugs for HPI B.01.01 tests are fixed and verified. ToDos: - Continue to do bug fixes=20 ********* Basic Information ********************* The README in the release package describes how to use the framework, how to contribute more tests to the framework in a brief. For more details, please refer to Framework_Specification.htm document under doc directory in the release package. The goal of this project is to create conformance test suite for SAF spec, including AIS A.01.01, AIS B.01.01, HPI A.01.01 and HPI B.01.01 spec.=20 Any more comments, please discuss in the following mailing list: saf...@li... (For the whole project) saf...@li... (For HPI part) saf...@li... (For AIS part) The webpage of this project can be found here: <http://saftest.sourceforge.net/> http://saftest.sourceforge.net/=20 Thanks - Ling |
From: Yu, L. L <lin...@in...> - 2006-03-01 01:52:59
|
saftest_HPI-B.01.01_1.0.7 is released, please download it from: =20 http://prdownloads.sourceforge.net/saftest/saftest_HPI-B_01_01_1_0_7.tar .gz?download=20 =20 This is bug fix release after HPI-B.01.01_1.0.6. In this release: - Great work from UNH team and Li Qun, most of the bugs for HPI B.01.01 tests are fixed and verified. =20 ToDos: - Continue to do bug fixes=20 =20 ********* Basic Information ********************* The README in the release package describes how to use the framework, how to contribute more tests to the framework in a brief. For more details, please refer to Framework_Specification.htm document under doc directory in the release package. =20 The goal of this project is to create conformance test suite for SAF spec, including AIS A.01.01, AIS B.01.01, HPI A.01.01 and HPI B.01.01 spec.=20 =20 Any more comments, please discuss in the following mailing list: saf...@li... (For the whole project) saf...@li... (For HPI part) saf...@li... (For AIS part) =20 The webpage of this project can be found here: <http://saftest.sourceforge.net/ <http://saftest.sourceforge.net/> > http://saftest.sourceforge.net/ <http://saftest.sourceforge.net/>=20 =20 =20 =20 Thanks - Ling =20 |
From: Xiong, C. <cry...@in...> - 2006-02-21 08:43:38
|
Starting from March, Yu Ling (lin...@in...) will take full maintainership for SAF Test project, including both HPI and AIS tests. AIS folks should already know Yu Ling pretty well. For HPI folks, Yu Ling has been leading AIS tests development and maintaining SAF Test framework for a long time. It should be natural to extend her responsibilities in HPI part and the whole project.=20 Thanks, Crystal Xiong |
From: Xiong, C. <cry...@in...> - 2006-01-13 19:15:09
|
saftest_HPI-B_01_01_1.0.6 is released, please download it from: =20 http://prdownloads.sourceforge.net/saftest/saftest_HPI-B_01_01_1_0_6.tar .gz?download =20 =20 This is bug fix release after HPI-B.01.01_1.0.5. In this release: - Great work from UNH team and Li Qun, most of the bugs for HPI B.01.01 tests are fixed and verified. There are only 18 open bugs left in bugDB for this release, most of them are lack of clear context and need more discussion. =20 ToDos: - Continue to do bug fixes=20 =20 ********* Basic Information ********************* The README in the release package describes how to use the framework, how to contribute more tests to the framework in a brief. For more details, please refer to Framework_Specification.htm document under doc directory in the release package. =20 The goal of this project is to create conformance test suite for SAF spec, including AIS A.01.01, AIS B.01.01, HPI A.01.01 and HPI B.01.01 spec.=20 =20 Any more comments, please discuss in the following mailing list: saf...@li... (For the whole project) saf...@li... (For HPI part) saf...@li... (For AIS part) =20 The webpage of this project can be found here: <http://saftest.sourceforge.net/ <http://saftest.sourceforge.net/> > http://saftest.sourceforge.net/ <http://saftest.sourceforge.net/>=20 =20 Thanks, Crystal =20 =20 =20 |
From: Xiong, C. <cry...@in...> - 2005-12-07 03:16:57
|
Sorry for the confusion. You could get the idea from the title. :) "Code freeze for HPI B.01.01 tests". Thanks, Crystal >-----Original Message----- >From: Shureih, Tariq >Sent: 2005年12月7日 4:23 >To: Xiong, Crystal; Xiong, Crystal; saf...@li... >Subject: RE: [Saftest-hpi-devel] one day code freeze for HPI B.01.01 tests > >Are you talking about the HPI test suite or the HPI implementation? :) > >---------------------- >Tariq > > >>-----Original Message----- >>From: saf...@li... [mailto:saftest-hpi- >>dev...@li...] On Behalf Of Xiong, Crystal >>Sent: Monday, December 05, 2005 6:01 PM >>To: Xiong, Crystal; saf...@li... >>Subject: RE: [Saftest-hpi-devel] one day code freeze for HPI B.01.01 tests >> >>Please DO NOT change code during code freeze. >> >>Thanks, >>Crystal >> >> >> >>>-----Original Message----- >>>From: saf...@li... [mailto:saftest-hpi- >>>dev...@li...] On Behalf Of Xiong, Crystal >>>Sent: 2005年12月5日 9:11 >>>To: saf...@li... >>>Subject: [Saftest-hpi-devel] one day code freeze for HPI B.01.01 tests >>> >>>Hi, >>> >>>I will create a new release of HPI B.01.01 0.5.0 in 12/7. >>> >>>In order to avoid the conflict code changes during the release, I will >>>set one day code freeze from 12/5 12:00AM to 12/6 12:00AM PDT Timezone. >>>Please don't check in HPI code during this time. >>> >>>Sorry for the late notice. >>> >>>Thanks, >>>Crystal >>> >>> >>> >>> >>>------------------------------------------------------- >>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log >>>files >>>for problems? Stop! Download the new AJAX search engine that makes >>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>>http://ads.osdn.com/?ad_idv37&alloc_id865&op=ick >>>_______________________________________________ >>>Saftest-hpi-devel mailing list >>>Saf...@li... >>>https://lists.sourceforge.net/lists/listinfo/saftest-hpi-devel >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log >>files >>for problems? Stop! Download the new AJAX search engine that makes >>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >>_______________________________________________ >>Saftest-hpi-devel mailing list >>Saf...@li... >>https://lists.sourceforge.net/lists/listinfo/saftest-hpi-devel |
From: Shureih, T. <tar...@in...> - 2005-12-06 20:37:11
|
Are you talking about the HPI test suite or the HPI implementation? :) ---------------------- Tariq >-----Original Message----- >From: saf...@li... [mailto:saftest-hpi- >dev...@li...] On Behalf Of Xiong, Crystal >Sent: Monday, December 05, 2005 6:01 PM >To: Xiong, Crystal; saf...@li... >Subject: RE: [Saftest-hpi-devel] one day code freeze for HPI B.01.01 tests > >Please DO NOT change code during code freeze. > >Thanks, >Crystal > > > >>-----Original Message----- >>From: saf...@li... [mailto:saftest-hpi- >>dev...@li...] On Behalf Of Xiong, Crystal >>Sent: 2005年12月5日 9:11 >>To: saf...@li... >>Subject: [Saftest-hpi-devel] one day code freeze for HPI B.01.01 tests >> >>Hi, >> >>I will create a new release of HPI B.01.01 0.5.0 in 12/7. >> >>In order to avoid the conflict code changes during the release, I will >>set one day code freeze from 12/5 12:00AM to 12/6 12:00AM PDT Timezone. >>Please don't check in HPI code during this time. >> >>Sorry for the late notice. >> >>Thanks, >>Crystal >> >> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log >>files >>for problems? Stop! Download the new AJAX search engine that makes >>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>http://ads.osdn.com/?ad_idv37&alloc_id865&op=ick >>_______________________________________________ >>Saftest-hpi-devel mailing list >>Saf...@li... >>https://lists.sourceforge.net/lists/listinfo/saftest-hpi-devel > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log >files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >Saftest-hpi-devel mailing list >Saf...@li... >https://lists.sourceforge.net/lists/listinfo/saftest-hpi-devel |
From: Xiong, C. <cry...@in...> - 2005-12-06 08:34:10
|
saftest_HPI-B_01_01_1.0.5 is released, please download it from: http://prdownloads.sourceforge.net/saftest/saftest_HPI-B_01_01_1_0_5.tar .gz?download =20 =20 This is bug fix release after HPI-B.01.01_1.0.4. In this release: - Continuously Bug fixes for HPI test WG reviewed sessions. Thanks UNH team and Li Qun. - Bug fixes for Inventory, Annunciator. Thanks Donald Barre, Li Qun, Zhao ZeZhang. ToDos: - Continue to do bug fixes=20 ********* Basic Information ********************* The README in the release package describes how to use the framework, how to contribute more tests to the framework in a brief. For more details, please refer to Framework_Specification.htm document under doc directory in the release package. =20 The goal of this project is to create conformance test suite for SAF spec, including AIS A.01.01, AIS B.01.01, HPI A.01.01 and HPI B.01.01 spec.=20 =20 Any more comments, please discuss in the following mailing list: saf...@li... (For the whole project) saf...@li... (For HPI part) saf...@li... (For AIS part) =20 The webpage of this project can be found here: <http://saftest.sourceforge.net/> http://saftest.sourceforge.net/ =20 Thanks, Crystal =20 |
From: Xiong, C. <cry...@in...> - 2005-12-06 02:01:25
|
Please DO NOT change code during code freeze. Thanks, Crystal >-----Original Message----- >From: saf...@li... [mailto:saftest-hpi- >dev...@li...] On Behalf Of Xiong, Crystal >Sent: 2005年12月5日 9:11 >To: saf...@li... >Subject: [Saftest-hpi-devel] one day code freeze for HPI B.01.01 tests > >Hi, > >I will create a new release of HPI B.01.01 0.5.0 in 12/7. > >In order to avoid the conflict code changes during the release, I will >set one day code freeze from 12/5 12:00AM to 12/6 12:00AM PDT Timezone. >Please don't check in HPI code during this time. > >Sorry for the late notice. > >Thanks, >Crystal > > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log >files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_idv37&alloc_id865&op=ick >_______________________________________________ >Saftest-hpi-devel mailing list >Saf...@li... >https://lists.sourceforge.net/lists/listinfo/saftest-hpi-devel |
From: Xiong, C. <cry...@in...> - 2005-12-05 01:10:41
|
Hi, I will create a new release of HPI B.01.01 0.5.0 in 12/7.=20 In order to avoid the conflict code changes during the release, I will set one day code freeze from 12/5 12:00AM to 12/6 12:00AM PDT Timezone. Please don't check in HPI code during this time. Sorry for the late notice. Thanks, Crystal=20 |
From: David M. <dav...@au...> - 2005-11-29 17:08:53
|
NEVER MIND! - it was me that was confused - this is, indeed, concerning saHpiControlGet(). David McKinley=20 -----Original Message----- From: David McKinley [mailto:dav...@au...]=20 Sent: Tuesday, November 29, 2005 11:04 AM To: 'David McKinley'; 'Wang, Jing J'; saf...@li...; hp...@sa... Subject: RE: [Saftest-hpi-devel] FW: [Openhpi-devel] SaHpiControlGet: = spec issue Just to make sure there is not a confusion here - this issue has to do = with saHpiControlSet(), not saHpiControlGet(). I assume that the original = email had a typo. David McKinley=20 -----Original Message----- From: saf...@li... [mailto:saf...@li...] On Behalf Of = David McKinley Sent: Tuesday, November 29, 2005 10:12 AM To: 'Wang, Jing J'; saf...@li...; hp...@sa... Subject: RE: [Saftest-hpi-devel] FW: [Openhpi-devel] SaHpiControlGet: = spec issue You are correct that the specification does not require CtrlState->Type = to be set. The next version of the HPI specification will make this = clearer - that is it goes out of its way to explain that CtrlState->Type does = *not* need to be set. So, I'd say that test suite should set CtrlState->Type to an invalid = value, to make sure that this does not matter to the implementation. David McKinley=20 -----Original Message----- From: saf...@li... [mailto:saf...@li...] On Behalf Of = Wang, Jing J Sent: Tuesday, November 29, 2005 4:17 AM To: saf...@li... Subject: [Saftest-hpi-devel] FW: [Openhpi-devel] SaHpiControlGet: spec = issue -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of = Revyakin, Vadim A Sent: 2005?11?29? 18:09 To: ope...@li... Subject: [Openhpi-devel] SaHpiControlGet: spec issue Spec says: "For text controls, the line number to read is passed in via CtrlState->StateUnion.Text.Line" (page 94, description of CtrlState argument). But spec doesn't require CtrlState->Type must be set properly. What should we check in SaHpiControlGet() implementation for CtrlState argument? Your opinion? ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ Openhpi-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openhpi-devel ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ Saftest-hpi-devel mailing list Saf...@li... https://lists.sourceforge.net/lists/listinfo/saftest-hpi-devel ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ Saftest-hpi-devel mailing list Saf...@li... https://lists.sourceforge.net/lists/listinfo/saftest-hpi-devel |
From: David M. <dav...@au...> - 2005-11-29 17:04:06
|
Just to make sure there is not a confusion here - this issue has to do = with saHpiControlSet(), not saHpiControlGet(). I assume that the original = email had a typo. David McKinley=20 -----Original Message----- From: saf...@li... [mailto:saf...@li...] On Behalf Of = David McKinley Sent: Tuesday, November 29, 2005 10:12 AM To: 'Wang, Jing J'; saf...@li...; hp...@sa... Subject: RE: [Saftest-hpi-devel] FW: [Openhpi-devel] SaHpiControlGet: = spec issue You are correct that the specification does not require CtrlState->Type = to be set. The next version of the HPI specification will make this = clearer - that is it goes out of its way to explain that CtrlState->Type does = *not* need to be set. So, I'd say that test suite should set CtrlState->Type to an invalid = value, to make sure that this does not matter to the implementation. David McKinley=20 -----Original Message----- From: saf...@li... [mailto:saf...@li...] On Behalf Of = Wang, Jing J Sent: Tuesday, November 29, 2005 4:17 AM To: saf...@li... Subject: [Saftest-hpi-devel] FW: [Openhpi-devel] SaHpiControlGet: spec = issue -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of = Revyakin, Vadim A Sent: 2005?11?29? 18:09 To: ope...@li... Subject: [Openhpi-devel] SaHpiControlGet: spec issue Spec says: "For text controls, the line number to read is passed in via CtrlState->StateUnion.Text.Line" (page 94, description of CtrlState argument). But spec doesn't require CtrlState->Type must be set properly. What should we check in SaHpiControlGet() implementation for CtrlState argument? Your opinion? ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ Openhpi-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openhpi-devel ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ Saftest-hpi-devel mailing list Saf...@li... https://lists.sourceforge.net/lists/listinfo/saftest-hpi-devel ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ Saftest-hpi-devel mailing list Saf...@li... https://lists.sourceforge.net/lists/listinfo/saftest-hpi-devel |
From: David M. <dav...@au...> - 2005-11-29 16:12:26
|
You are correct that the specification does not require CtrlState->Type = to be set. The next version of the HPI specification will make this = clearer - that is it goes out of its way to explain that CtrlState->Type = does *not* need to be set. So, I'd say that test suite should set CtrlState->Type to an invalid = value, to make sure that this does not matter to the implementation. David McKinley=20 -----Original Message----- From: saf...@li... = [mailto:saf...@li...] On Behalf Of = Wang, Jing J Sent: Tuesday, November 29, 2005 4:17 AM To: saf...@li... Subject: [Saftest-hpi-devel] FW: [Openhpi-devel] SaHpiControlGet: spec = issue -----Original Message----- From: ope...@li... = [mailto:ope...@li...] On Behalf Of = Revyakin, Vadim A Sent: 2005=E5=B9=B411=E6=9C=8829=E6=97=A5 18:09 To: ope...@li... Subject: [Openhpi-devel] SaHpiControlGet: spec issue Spec says: "For text controls, the line number to read is passed in via CtrlState->StateUnion.Text.Line" (page 94, description of CtrlState argument). But spec doesn't require CtrlState->Type must be set properly. What should we check in SaHpiControlGet() implementation for CtrlState = argument? Your opinion? ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files for problems? Stop! Download the new AJAX search engine that = makes searching your log files as easy as surfing the web. DOWNLOAD = SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ Openhpi-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openhpi-devel ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files for problems? Stop! Download the new AJAX search engine that = makes searching your log files as easy as surfing the web. DOWNLOAD = SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ Saftest-hpi-devel mailing list Saf...@li... https://lists.sourceforge.net/lists/listinfo/saftest-hpi-devel |
From: Wang, J. J <jin...@in...> - 2005-11-29 10:17:31
|
-----Original Message----- From: ope...@li... = [mailto:ope...@li...] On Behalf Of = Revyakin, Vadim A Sent: 2005=C4=EA11=D4=C229=C8=D5 18:09 To: ope...@li... Subject: [Openhpi-devel] SaHpiControlGet: spec issue Spec says: "For text controls, the line number to read is passed in via CtrlState->StateUnion.Text.Line" (page 94, description of CtrlState argument). But spec doesn't require CtrlState->Type must be set properly. What should we check in SaHpiControlGet() implementation for CtrlState argument? Your opinion? ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick _______________________________________________ Openhpi-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openhpi-devel |
From: <Ste...@ra...> - 2005-11-10 19:23:49
|
Q29ycmVjdCwgbm8gIlNsZWVwIGFmdGVyIFNlc3Npb25PcGVuIiBhbmQgIkRpc2NvdmVyIGFmdGVy IFNlc3Npb25PcGVuIg0Kc2hvdWxkIG5vdCBiZSB0aGUgZGVmYXVsdC4NCg0KLS1zdGV2ZW0NCg0K IldhbmcsIEppbmcgSiIgPGppbmcuai53YW5nQGludGVsLmNvbT4gd3JvdGUgb24gMTEvMTAvMjAw NSAwMTo0NjoxNyBBTToNCg0KPiBEYXZpZCwgUmVuaWVybSwNCj4gICAgICAgICAgQWZ0ZXIgcmVh ZGluZyB0aGUgbG9uZyBtYWlsIHlvdSB3ZXJlIGRpc2N1c3NpbmcsIG1heSBJDQo+IGFzc3VtZSwg eW91IGhhdmUgcmVhY2hlZCBhZ3JlZW1lbnQgdGhhdCChsFNsZWVwIGFmdGVyIFNlc3Npb25PcGVu obENCj4gc2hvdWxkIGJlIHJlbW92ZWQgaW4gT3BlbkhQSSB0byBtYWtlIGl0IGJlIGNvbXBsaWFu dCB3aXRoIEhQSSBzcGVjLUI/DQo+DQo+DQo+IFdhbmdKaW5nDQo+DQo+DQo+IEZyb206IHNhZnRl c3QtZGV2ZWwtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0IFttYWlsdG86c2FmdGVzdC0NCj4g ZGV2ZWwtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0XSBPbiBCZWhhbGYgT2YgUmVuaWVyIE1v cmFsZXMNCj4gU2VudDogMjAwNcTqMTHUwjHI1SAzOjQ4DQo+IFRvOiBEYXZpZCBNY0tpbmxleQ0K PiBDYzogaHBpdGVzdEBzYWZvcnVtLm9yZzsgc2FmdGVzdC1kZXZlbEBsaXN0cy5zb3VyY2Vmb3Jn ZS5uZXQ7DQo+IHNhZnRlc3QtaHBpLWRldmVsQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KPiBTdWJq ZWN0OiBSRTogW1NhZnRlc3QtZGV2ZWxdIFJlOlNBRlRlc3QgbGF0ZW5jeSBpc3N1ZQ0KPg0KPg0K PiBEYXZpZCwgdGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLg0KPg0KPiBXZSB3aWxsIGhhdmUgdG8g bGl2ZSB3aXRoIGJlaW5nIGNvbXBsaWFudCB3aXRoIHRoaXMgc3BlY2lmaWMNCj4gYmVoYXZpb3Ig aW4gZGFlbW9uIG1vZGUgb25seSwgdGhyb3VnaCB0aGUgc2FmIHRlc3RzLCB3aGVyZSB0aGUNCj4g ZGFlbW9uIGNhbiBiZSBzdGFydGVkIHdheSBpbiBhZHZhbmNlIHRvIGFueSB1c2VycyBhdHRlbXRp bmcgdG8gZ2V0DQo+IHNlc3Npb25zIG9wZW5lZC4NCj4NCj4gVGhlIHByb2JsZW0gd2UgaGF2ZSB3 aXRoIGdhdGhlcmluZyBhbGwgZXhpc3RpbmcgcmVzb3VyY2VzIGJlZm9yZQ0KPiAidGhlIGltcGxl bWVudGF0aW9uIHN0YXJ0cyIgaXMgdGhhdCBpcG1pIGJhc2VkIGhhcmR3YXJlIGNhbiB0YWtlIHVw DQo+IHRvIDEgbWludXRlIGFuZCBhIGhhbGYgdG8gInN0YXJ0IiBhbmQgc25tcCBiYXNlZCBwbHVn aW5zIGNvdWxkIHRha2UNCj4gdXAgdG8gdGhlIHNhbWUgYW1vdW50IG9mIHRpbWUuDQo+IFRoaXMg ZGVsYXkgYXQgc3RhcnQtdXAgY291bGQgYmUgYSBwcm9ibGVtIGluIHNvbWUgc2l0dWF0aW9ucywN Cj4gZXNwZWNpYWxseSBpZiB5b3UgbmVlZC93YW50IHRvIHNlbmQgY29tbWFuZHMgdG8gYSBzcGVj aWZpYyByZXNvdXJjZQ0KPiBzb29uZXIgdGhhbiB0aGF0Lg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBS ZW5pZXIgTW9yYWxlcw0KPiBJQk0gTGludXggVGVjaG5vbG9neSBDZW50ZXINCj4gaHR0cDovL29w ZW5ocGkuc2YubmV0DQo+ICg4NDUpIDQzNS0yMDAzIChUTCAyOTUpDQo+DQo+IHNhZnRlc3QtZGV2 ZWwtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0IHdyb3RlIG9uIDEwLzI2LzIwMDUgMTI6MTk6 MDMNCkFNOg0KPg0KPiA+IFJlbmllciwNCj4gPg0KPiA+IFNvcnJ5IGZvciB0aGUgZGVsYXkgaW4g cmVzcG9uZGluZyBvbiB0aGlzIHRocmVhZCAtIEkgaGFkIHNldmVyYWwNCj4gPiB3ZWVrcyBvZiB0 aWdodCBkZWFkbGluZXMgYW5kIGNvdWxkbid0IGdpdmUgdGhlIHRpbWUgcmVxdWlyZWQgdG8NCj4g PiBjb21wb3NlIGEgdXNlZnVsIGNvbW1lbnQuICBUaGVuIEkgc3RhcnRlZCBpbiBvbiBhIHRob3Jv dWdoIGFuYWx5c2lzDQo+ID4gb2YgdGhlIHNwZWMgYW5kIGV4cGxhbmF0aW9uIG9mIHdoYXQgSSBi ZWxpZXZlIGl0IHNheXMgLSBjbGVhcmx5IGFuZA0KPiA+IHVuYW1iaWd1b3VzbHkgLSBvbiB0aGlz IGlzc3VlLiAgQnV0IHRoYXQgZ290IHdheSB0b28gbG9uZywgc28gSQ0KPiA+IGRlY2lkZWQgdG8g c3VtbWFyaXplLiAgSWYgeW91IHdhbnQgdGhlIGdvcnkgZGV0YWlscywgbGV0IG1lIGtub3csDQo+ ID4gYW5kIEknbGwgc2VuZCB5b3UgbG90cyBvZiBzcGVjIHJlZmVyZW5jZXMgYW5kIHRyeSB0byBl eHBsYWluIHdoeSBJDQo+ID4gdGhpbmsgdGhleSBjYW4gb25seSBiZSBpbnRlcnByZXRlZCB0byBz YXk6DQo+ID4NCj4gPiAxKSBUaGVyZSBhcmUgb25seSB0d28gY29uZGl0aW9ucyB3aGVyZSBpdCBp cyBsZWdhbCB0byBhZGQgYSByZXNvdXJjZQ0KPiA+IHRvIGFuIFJQVCBhZnRlciBhIHVzZXIgaGFz IGhhZCB0aGUgb3Bwb3J0dW5pdHkgdG8gcmVhZCBpdCBpbiBhbg0KPiBvcGVuIHNlc3Npb246DQo+ ID4gICAgICBhKSBXaGVuIGEgRlJVIGlzIGhvdCBzd2FwcGVkIGludG8gdGhlIHN5c3RlbSAoZnVs bCBvcg0KPiA+IHNpbXBsaWZpZWQgaG90IHN3YXApLCBvcg0KPiA+ICAgICAgYikgV2hlbiBhIHJl c291cmNlIHRoYXQgd2FzIG5vdCBmdW5jdGlvbmFsIHdoZW4gdGhlIEhQSQ0KPiA+IGltcGxlbWVu dGF0aW9uIHN0YXJ0ZWQgbGF0ZXIgYmVjb21lcyBmdW5jdGlvbmFsLg0KPiA+DQo+ID4gMikgQm90 aCBvZiB0aG9zZSBvY2N1cnJlbmNlcyBtdXN0IGJlIGFjY29tcGFuaWVkIGJ5IHRoZSBnZW5lcmF0 aW9uDQo+ID4gb2YgZXZlbnRzIHRvIGFsbCB1c2VycyB3aXRoIHNlc3Npb25zIG9wZW4gb24gdGhl IGRvbWFpbi4NCj4gPg0KPiA+IDMpIEEgcmVzb3VyY2UgYmVpbmcgIm5vdCBmdW5jdGlvbmFsIiBp cyBhIGZhdWx0IGNvbmRpdGlvbjsgaXQgbWVhbnMNCj4gPiBzb21ldGhpbmcgaXMgYnJva2VuLiAg VGh1cywgYSB1c2VyIGlzIGp1c3RpZmllZCBpbiBpbnRlcnByZXRpbmcgYQ0KPiA+ICJSZXNvdXJj ZSBBZGRlZCIgZXZlbnQsIGFzIGFuIGV4Y2VwdGlvbmFsIHRoaW5nIC0gdGhlIHJlY292ZXJ5IGZy b20NCj4gPiBhIGZhdWx0IGNvbmRpdGlvbiAtIG5vdCBqdXN0IGEgbm9ybWFsICdib29ra2VlcGlu ZycgZW50cnkgbWFkZSBieQ0KPiA+IHRoZSBIUEkgaW1wbGVtZW50YXRpb24uDQo+ID4NCj4gPiBO b3csIHdpdGggYWxsIHRoYXQgYmVpbmcgc2FpZCwgSSB0aGluayB5b3UgYXJlIGNvcnJlY3QgaW4g bm90aW5nDQo+ID4gdGhhdCB0aGUgc3BlY2lmaWNhdGlvbiBnaXZlcyBhIGZhaXIgYW1vdW50IG9m IGZsZXhpYmlsaXR5IG9uIGhvdw0KPiA+IHN0YXJ0dXAgb2YgdGhlIEhQSSBpbXBsZW1lbnRhdGlv biBpcyBwZXJmb3JtZWQuICBUaGlzIHdhcyBkb25lDQo+ID4gaW50ZW50aW9uYWxseSBzbyB0aGF0 IHZhcmlvdXMgaW1wbGVtZW50YXRpb25zIGFuZCBvcGVyYXRpbmcNCj4gPiBlbnZpcm9ubWVudHMg Y291bGQgYmUgYWNjb21tb2RhdGVkLiAgVGhlIEEuMDEuMDEgc3BlY2lmaWNhdGlvbg0KPiA+IGlu Y2x1ZGVkIHNhSHBpSW5pdGlhbGl6ZSgpIGFuZCBzYUhwaUZpbmFsaXplKCkgZnVuY3Rpb25zLiAg VGhlc2UNCj4gPiB3ZXJlIHJlbW92ZWQgaW4gdGhlIEIuMDEuMDEgc3BlY2lmaWNhdGlvbiBpbiBs YXJnZSBwYXJ0IGJlY2F1c2Ugd2UNCj4gPiBjb3VsZCBub3QgZmluZCBjb25zaXN0ZW50IHJ1bGVz IGZvciB0aGUgdXNlIG9mIHRob3NlIGZ1bmN0aW9ucyB0aGF0DQo+ID4gYXBwbGllZCBpbiBhbGwg dGhlIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbiBzY2VuYXJpb3MgdGhlDQo+ID4gc3BlY2lmaWNh dGlvbiBuZWVkZWQgdG8gc3VwcG9ydC4gIFNvLCBob3cgdGhlIEhQSSBpbXBsZW1lbnRhdGlvbiBp cw0KPiA+IHN0YXJ0ZWQgYW5kIHN0b3BwZWQgaXMgbGVmdCBhcyBhbiAiaW1wbGVtZW50YXRpb24t c3BlY2lmaWMiIGl0ZW0uDQo+ID4NCj4gPiBCdXQsIEkgZG9uJ3QgdGhpbmsgdGhhdCBpdCBpcyBy ZWFzb25hYmxlIHRvIGNvbmNsdWRlIHRoYXQgdGhpcw0KPiBmbGV4aWJpbGl0eSBpbg0KPiA+IGhv dyBhbiBpbXBsZW1lbnRhdGlvbiBpcyBzdGFydGVkIG1lYW5zIHRoYXQgaXQgaXMgdW5kZWZpbmVk IHdoZXRoZXINCj4gPiBvciBub3QgYW4gaW1wbGVtZW50YXRpb24gdGhhdCBhIHVzZXIgY2FuIGFj Y2VzcyBoYXMgc3RhcnRlZCB5ZXQuDQo+ID4gVGhlIHdob2xlIEhQSSBzcGVjaWZpY2F0aW9uIGlz IGRlZmluZWQgYXMgYSBzZXQgb2YgQVBJIGNhbGxzLCBhbmQNCj4gPiB0aGUgYmVoYXZpb3Igb2Yg YW4gSFBJIGltcGxlbWVudGF0aW9uIGlzIGV4aGliaXRlZCBvbmx5IHRocm91Z2gNCj4gPiByZXR1 cm5pbmcgcmV0dXJuIGNvZGVzIGFuZCBvdXRwdXQgcGFyYW1ldGVycyBpbiByZXNwb25zZSB0byB0 aGUNCj4gPiB2YXJpb3VzIEhQSSBmdW5jdGlvbnMgYmVpbmcgY2FsbGVkIHdpdGggY2VydGFpbiBp bnB1dCBwYXJhbWV0ZXJzLg0KPiA+IElmIGEgdXNlciBjYW4gY2FsbCBhbiBIUEkgZnVuY3Rpb24g YW5kIGdldCBhIHJldHVybiBiYWNrLCB0aGVuIHRoZQ0KPiA+IEhQSSBpbXBsZW1lbnRhdGlvbiBp cyBydW5uaW5nLCBieSBkZWZpbml0aW9uLiAgSWYgaXQgaXMgcnVubmluZywgaXQNCj4gPiBtdXN0 IGhhdmUgYmVlbiBzdGFydGVkLCBzb21laG93Lg0KPiA+DQo+ID4gUHV0dGluZyB0aGlzIHRvZ2V0 aGVyLCBJIHRoaW5rIHRoZXJlIGlzIG9ubHkgb25lIHdheSB5b3UgY2FuIHJldHVybg0KPiA+IGFu IGVtcHR5IFJQVCB0byBhIHVzZXIgd2hpbGUgdGhlcmUgYXJlIG5vbi1GUlUgcmVzb3VyY2VzIGlu IHRoZQ0KPiA+IHN5c3RlbSwgb3IgRlJVIHJlc291cmNlcyB0aGF0IHdlcmUgaW5zZXJ0ZWQgYmVm b3JlIHRoZSBIUEkNCj4gPiBpbXBsZW1lbnRhdGlvbiB3YXMgc3RhcnRlZC4gIFlvdSB3b3VsZCBo YXZlIHRvIGRlY2xhcmUgdGhhdCBldmVyeQ0KPiA+IG9uZSBvZiB0aGVzZSByZXNvdXJjZXMgaXMg aW4gYSBmYWlsZWQgc3RhdGUuICBUaGVuLCB3aGVuIGVhY2gNCj4gPiByZXNvdXJjZSBpcyBhZGRl ZCB0byB0aGUgUlBUIChpcnJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgYSB1c2VyDQo+ID4g Y2FsbHMgc2FIcGlEaXNjb3ZlcigpICkgdGhlIGFwcHJvcHJpYXRlIGhvdCBzd2FwIG9yICJyZXNv dXJjZSBhZGRlZCINCj4gPiBldmVudCBtdXN0IGJlIGlzc3VlZCB0byBlYWNoIHVzZXIgdGhhdCBp cyBzdWJzY3JpYmVkIHRvIHJlY2VpdmUNCj4gPiBldmVudHMgLSB0aGF0IGV2ZW50IGNvbW11bmlj YXRpbmcgdGhlIHJlY292ZXJ5IG9mIHRoZSByZXNvdXJjZSBmcm9tDQo+ID4gYSBmYXVsdCBjb25k aXRpb24uICBXaGlsZSBJIHRoaW5rIHlvdSBjb3VsZCBhcmd1ZSB0aGF0IGFuDQo+ID4gaW1wbGVt ZW50YXRpb24gdGhhdCBiZWhhdmVkIHRoaXMgd2F5IGlzIHRlY2huaWNhbGx5IGNvbXBsaWFudCB3 aXRoDQo+ID4gdGhlIHNwZWNpZmljYXRpb24sIEkgY2FuJ3QgYmVsaWV2ZSB0aGF0IHlvdSB3b3Vs ZCB3YW50IHRvIGFkdmVydGlzZQ0KPiA+IHN1Y2ggYmVoYXZpb3IuDQo+ID4NCj4gPiBJdCBzZWVt cyB0byBtZSB0aGF0IGEgbW9yZSBwcmFjdGljYWwgLSBhbmQgcGFsYXRhYmxlIC0gc29sdXRpb24g aXMNCj4gPiB0byBkZWZpbmUgYW4gaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgc3RhcnR1cCBwcm9j ZXNzIHRoYXQgaGFzIHRvIHJ1bg0KPiA+IGJlZm9yZSB5b3UgY2xhaW0gdGhhdCB0aGUgaW1wbGVt ZW50YXRpb24gaXMgY29tcGxpYW50LiAgVGhpcyBzdGFydHVwDQo+ID4gcHJvY2VzcyB3b3VsZCBv cGVuIGEgc2Vzc2lvbiBhbmQgY2F1c2UgdGhlIFJQVCB0byBiZSBwb3B1bGF0ZWQuDQo+ID4gVGhl biwgcmVhbCB1c2VycyBjYW4gcnVuLCBhbmQgc2VlIGEgZnVuY3Rpb25pbmcgaW1wbGVtZW50YXRp b24gd2l0aA0KPiA+IHdvcmtpbmcgcmVzb3VyY2VzIHJlZmxlY3RlZCBpbiB0aGUgUlBULiAgSSdt IG5vdCB0aGF0IGZhbWlsaWFyIHdpdGgNCj4gPiBPcGVuSFBJIC0gc28gbWF5YmUgdGhpcyB3b3Jr cyBvciBtYXliZSBpdCBkb2Vzbid0Lg0KPiA+DQo+ID4gRGF2aWQgTWNLaW5sZXkNCj4gPiBBdWdt ZW50aXggQ29ycG9yYXRpb24NCj4gPg0KPiA+DQo+ID4gIkRhdmlkIE1jS2lubGV5IiA8ZGF2aWQu bWNraW5sZXlAYXVnbWVudGl4LmNvbT4gd3JvdGUgb24gMDkvMjgvMjAwNQ0KPiA+IDA2OjIzOjEx IFBNOg0KPiA+DQo+ID4gPiBSZW5pZXIsDQo+ID4gPg0KPiA+ID4gSSdtIHN0aWxsIHBsYW5uaW5n IGEgbW9yZSBjb21wbGV0ZSwgdGhvdWdodGZ1bCByZXNwb25zZSwgYnV0IHRoZXJlDQo+ID4gPiBp cyBvbmUgcGFydCBvZiB5b3VyIGVtYWlsIHRoYXQgc2VlbXMgd29ydGggYSBxdWljayBjb21tZW50 IC0NCj4gPiA+DQo+ID4gPiBZb3Ugc2F5LCByZWZlcnJpbmcgdG8gc2VjdGlvbiAzLjUgaW4gdGhl IHNwZWNpZmljYXRpb246DQo+ID4gPg0KPiA+ID4gSXQgYWxzbyBzYXlzIHRoYXQgdGhvc2UgZGlz Y292ZXJ5IHN0ZXBzIHlvdSByZWZlciB0byBpcyBob3cgYQ0KPiA+ID4gKnR5cGljYWwqIGRpc2Nv dmVyeSBwcm9jZXNzIHdpbGwgaGFwcGVuLiBDYW4gZGlzY292ZXJ5IGhhcHBlbiBpbg0KPiA+ID4g b3RoZXIgd2F5cyB0aGVuPw0KPiA+ID4gWWVzLCBkaXNjb3ZlcnkgY2FuIGhhcHBlbiBvdGhlciB3 YXlzLiAgSXQgY2FuIGhhcHBlbiBhbnkgd2F5IHRoYXQgYQ0KPiA+ID4gdXNlciBwcm9ncmFtIGNo b29zZXMsIHNvIGxvbmcgYXMgd2hhdGV2ZXIgdGhlIHVzZXIgY2hvb3NlcyB0byBkbyBpcw0KPiA+ ID4gc3VwcG9ydGVkIGJ5IHRoZSBpbXBsZW1lbnRhdGlvbi4gIEFuZCwgYSBjb21wbGlhbnQgaW1w bGVtZW50YXRpb24NCj4gPiA+IG11c3Qgc3VwcG9ydCB3aGF0ZXZlciBpdCBpcyB0aGF0IHRoZSBz cGVjaWZpY2F0aW9uIHNheXMgaXQgbXVzdA0Kc3VwcG9ydC4NCj4gPiA+DQo+ID4gPiBXZWxsLCB3 aGF0ZXZlciB0aGUgc3BlY2lmaWNhdGlvbiBtYXkgb3IgbWF5IG5vdCBzYXkgZWxzZXdoZXJlLCBp bg0KPiA+ID4gc2VjdGlvbiAzLjUgaXQgc2VlbXMgcHJldHR5IGNsZWFybHkgdG8gYmUgc2F5aW5n LCAiSGVyZSBpcyBvbmUgd2F5IGENCj4gPiA+IHVzZXIgY2FuIGRvIGRpc2NvdmVyeSIgLSBpbiBm YWN0IGl0IGdvZXMgZnVydGhlciB0byBzYXkgdGhhdCB0aGlzDQo+ID4gPiB3YXkgdG8gZG8gZGlz Y292ZXJ5IGlzICJ0eXBpY2FsIi4gIFNvLCBjYW4gYW4gaW1wbGVtZW50YXRpb24gdGhhdA0KPiA+ ID4gZG9lcyBub3Qgc3VwcG9ydCB1c2VycyBkb2luZyBkaXNjb3ZlcnkgdGhlIHdheSB0aGUgc3Bl Y2lmaWNhdGlvbg0KPiA+ID4gaWRlbnRpZmllcyBhcyAidHlwaWNhbCIgcmVhc29uYWJseSBiZSBj b25zaWRlcmVkIGNvbXBsaWFudD8gIFN1cmVseSwNCj4gPiA+IGF0IHRoZSB2ZXJ5IGxlYXN0LCB0 aGUgaW1wbGVtZW50YXRpb24gbmVlZHMgdG8gc3VwcG9ydCB0aGUgdXNhZ2UNCj4gPiA+IHRoYXQg dGhlIHNwZWNpZmljYXRpb24gaXRzZWxmIHNwZWxscyBvdXQsIGRvZXNuJ3QgaXQ/DQo+ID4NCj4g PiBUaGF0IHNlY3Rpb24gb2YgdGhlIHNwZWMgc2F5cyBtb3JlIHRoYXQganVzdCAiSGV5LCB0aGlz IGlzIGEgdXN1YWwNCj4gPiB3YXkgb2YgZG9pbmcgZGlzY292ZXI6IHN0ZXAgMSwgc3RlcCAyLCBz dGVwIDMsIHN0ZXAgNCwuLi4iLg0KPiA+IEl0IGFsc28gc2F5cyB0aGF0IlRocm91Z2hvdXQgdGhl IGRpc2NvdmVyeSBwcm9jZXNzLCBhbiBIUEkgVXNlcg0KPiA+IHNob3VsZCBtYWtlIHN1cmUgdGhh dCBubyByZXNvdXJjZXMgb3IgZG9tYWluIHJlZmVyZW5jZXMgd2VyZSBhZGRlZA0KPiA+IG9yIHJl bW92ZWQuIFRoaXMgY2FuIGJlIGFjY29tcGxpc2hlZCBieSB1c2luZyBSUFQgYW5kIERSVCB1cGRh dGUNCj4gPiBjb3VudGVycyBhbmQgZXZlbnRzLiINCj4gPg0KPiA+IFNvIG15IHF1ZXN0aW9uIGlz LCBpZiBhbiBIUEkgVXNlciBzaG91bGQgY2hlY2sgY291bnRlcnMgYW5kIGV2ZW50cw0KPiA+IHRo cm91Z2hvdXQgZGlzY292ZXJ5LCBidXQgaXQgaXMgbm90IG1lbnRpb25lZCBpbiB0aGUgc3RlcHMg b3V0bGluZWQsDQo+ID4gZG9lcyB0aGF0IG1lYW4gdGhhdCBhIHVzZXIgZG9lc24ndCBoYXZlIHRv IGNoZWNrIGNvdW50ZXJzIGFuZCBldmVudHMNCj4gPiBiYXNlZCBvbiB0aGUgdHlwaWNhbCBkaXNj b3ZlcnkgcHJvY2Vzcz8gb3IgZG9lcyBpdCBtZWFuIHRoYXQNCj4gPiBjaGVja2luZyBjb3VudGVy cyBhbmQgZXZlbnRzIGlzIGltcGxpZWQgaW4gYW55IGRpc2NvdmVyeSBzdGVwcyBkb25lPw0KPiA+ DQo+ID4NCj4gPiA+DQo+ID4gPiBTb21lIG9mIHlvdXIgb3RoZXIgYXJndW1lbnRzIGFyZSBhIGJp dCBtb3JlIGludGVyZXN0aW5nLCBhbmQgSSdtDQo+ID4gPiB0aGlua2luZyBhYm91dCB0aGVtIC4g LiAuIC4NCj4gPiA+IERhdmlkDQo+ID4gPg0KPiA+ID4NCj4gPiA+IEZyb206IHNhZnRlc3QtZGV2 ZWwtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0IFttYWlsdG86c2FmdGVzdC0NCj4gPiA+IGRl dmVsLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldF0gT24gQmVoYWxmIE9mIFJlbmllciBNb3Jh bGVzDQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAyOCwgMjAwNSA0OjE2IFBNDQo+ ID4gPiBUbzogQ2FybCBNY0FkYW1zDQo+ID4gPiBDYzogc2FmdGVzdC1kZXZlbEBsaXN0cy5zb3Vy Y2Vmb3JnZS5uZXQ7IHNhZnRlc3QtaHBpLWRldmVsQGxpc3RzLg0KPiA+ID4gc291cmNlZm9yZ2Uu bmV0DQo+ID4gPiBTdWJqZWN0OiBbU2FmdGVzdC1kZXZlbF0gUmU6U0FGVGVzdCBsYXRlbmN5IGlz c3VlDQo+ID4NCj4gPiA+DQo+ID4gPiBDYXJsIE1jQWRhbXMvQXVzdGluL0lCTSB3cm90ZSBvbiAw OS8yOC8yMDA1IDAzOjI4OjAyIFBNOg0KPiA+ID4NCj4gPiA+ID4gUmVuaWVyLA0KPiA+ID4gPg0K PiA+ID4gPiBUaGUgc3BlY2lmaWNhdGlvbiBnaXZlcyBtYW55IGluZGljYXRpb25zIHRoYXQgdGhl biBub24tRlJVDQpyZXNvdXJjZXMNCj4gPiA+ID4gYXJlIHByZXNlbnQgaW1tZWRpYXRlbHkuDQo+ ID4gPg0KPiA+ID4gWWVzLCBhbmQgaXQgYWxzbyBhbGxvd3MgZm9yIE5vbi1GUlUgcmVzb3VyY2Vz IHRvIGJlIGFkZGVkIGF0IGEgbGF0ZXINCj4gPiA+IHRpbWUgaWYgdGhleSBiZWNvbWUgZnVuY3Rp b25hbCBhZnRlciB0aGUgaW1wbGVtZW50YXRpb24gaGFzDQo+ID4gPiAic3RhcnRlZCIuIEJ1dCB3 aGF0IGRvZXMgInN0YXJ0ZWQiIG1lYW5zPyBJLCBhcyBhbiBIUEkgdXNlciwgd291bGQNCj4gPiA+ IGV4cGVjdCB0aGUgZGVzY3JpcHRpb24gb2Ygc2FIcGlTZXNzaW9uT3BlbigpIHRvIHNheSBpZiAi c3RhcnRlZCINCj4gPiA+IG1lYW5zIGFmdGVyIHNhSHBpU2Vzc2lvbk9wZW4gcmV0dXJucy4gVGhl IHNwZWMgaXMgbm90IGNsZWFyIG9uIHRoaXMNCj4gPiA+IChtYXliZSBpdCBtZWFucyBhZnRlciB0 aGUgZmlyc3Qgc2VsZiBkaXNjb3ZlcnkgaGFzIGhhcHBlbmVkLCB3aGljaA0KPiA+ID4gY291bGQg YmUgaW5kZXBlbmRlbnQgb2Ygb3BlbmluZyBhIHNlc3Npb24pIGFuZCB0aGF0IGlzIHBhcnQgb2Yg dGhlDQo+ID4gPiBpc3N1ZSwgd2hpY2ggaG9wZWZ1bGx5IHdpbGwgYmUgbWFkZSBjbGVhcmVyIGlu IGEgZnV0dXJlIHJldmlzaW9uDQo+ID4gb2YgdGhlIHNwZWMuDQo+ID4gPg0KPiA+ID4gPg0KPiA+ ID4gPiBJbiByZWZlcmVuY2Ugb2YgdGhlIGVudGlyZSBzZWN0aW9uICczLjUgRGlzY292ZXJ5JyAg b24gcGFnZXMgMjQgLQ0KPiA+ID4gPiAyNS4gIFdpdGhvdXQgZXZlbiBzdWdnZXN0aW5nIHRoYXQg dGhlIHVzZXIgdG8gb3ZlcmNvbWUgYW55IGxhdGVuY3ksDQoNCj4gPiA+ID4gdGhlIHNlY3Rpb24g d2Fsa3MgdGhlIHVzZXIgZnJvbSBvcGVuaW5nIGEgc2Vzc2lvbiB0byB3YWxraW5nIGVudGl0eQ0K DQo+ID4gPiA+IHBhdGhzLiAgSW4gdGhlIGxhc3QgcGFyYWdyYXBoIG9mIHRoZSBzZWN0aW9uIGl0 IHNheXMgdGhhdCB0aGUgImFuDQo+ID4gPiA+IEhQSSBVc2VyIG1heSBidWlsZCBhIHBoeXNpY2Fs IG1vZGVsIG9mIHRoZSBzeXN0ZW0gdXNpbmcgdGhlIEVudGl0eQ0KPiA+ID4gPiBQYXRocyBjb250 YWluZWQgaW4gZWFjaCBSUFQgZW50cnkgb3IgUkRSLiAgVGhpcyB3b3VsZCBhbGxvdyBhbiBIUEkN Cj4gPiA+ID4gVXNlciB0byBkZXRlcm1pbmUgdGhlIHRydWUgc2V0IG9mIGVudHJpZXMgdGhhdCBl eGlzdCBpbiB0aGUgc3lzdGVtIg0KDQo+ID4gPg0KPiA+ID4gSXQgYWxzbyBzYXlzIHRoYXQgdGhv c2UgZGlzY292ZXJ5IHN0ZXBzIHlvdSByZWZlciB0byBpcyBob3cgYQ0KPiA+ID4gKnR5cGljYWwq IGRpc2NvdmVyeSBwcm9jZXNzIHdpbGwgaGFwcGVuLiBDYW4gZGlzY292ZXJ5IGhhcHBlbiBpbg0K PiA+ID4gb3RoZXIgd2F5cyB0aGVuPw0KPiA+ID4gUGFnZSAyNCBhbHNvIHNheXMsIHRocm91Z2hv dXQgdGhlIGRpc2NvdmVyeSBwcm9jZXNzLCBhbiBIUEkgdXNlcg0KPiA+ID4gc2hvdWxkIG1ha2Ug c3VyZSB0aGF0IG5vIHJlc291cmNlcyBvciBkb21haW4gcmVmZXJlbmNlcyB3ZXJlIGFkZGVkDQo+ ID4gPiBvciByZW1vdmVkLiBUaGF0IHRoYXQgY2FuIGJlIGFjY29tcGxpc2hlZCBieSB1c2luZyB0 aGUgUlBUL0RSVA0KPiA+ID4gdXBkYXRlIGNvdW50ZXJzIGFuZCBldmVudHMuDQo+ID4gPiBBIHVz ZXIgbXVzdCBhbHdheXMgZG8gdGhpcyBhbmQgaXQgaXMgbm90IGJlaW5nIGRvbmUgaW4gdGhlDQo+ ID4gPiBjb25mb3JtYW5jZSB0ZXN0cyB3aGVuIGxvb2tpbmcgZm9yIHJlc291cmNlIHdpdGggc3Bl Y2lmaWMNCmNhcGFiaWxpdGllcy4NCj4gPiA+IFRoZSAsICJ0aHJvdWdob3V0IHRoZSBkaXNjb3Zl cnkgcHJvY2VzcyIgcGhyYXNlIGlzIGludGVyZXN0aW5nIGFzIGl0DQo+ID4gPiBnaXZlcyBtZSB0 aGUgaWRlYSB0aGF0IHRoZSBkaXNjb3ZlcnkgcHJvY2VzcyBhIHVzZXIgcGVyZm9ybXMgaW4gSFBJ DQo+ID4gPiBpcyBvbi1nb2luZy4gU28gYSB1c2VyIHdpbGwgY29udGludWFsbHkgcmVmcmVzaCBo aXMvaGVyIHZpZXcgb2YgdGhlDQo+ID4gPiBIUEkgd29ybGQgYnkgaW5zcGVjdGluZyBSUFQsRFJU LCBjb3VudGVycywgZXZlbnRzLCBldGMuIG92ZXIgYW5kDQo+ID4gb3ZlciBhZ2Fpbi4NCj4gPiA+ DQo+ID4gPiA+DQo+ID4gPiA+IEV2ZW4gaW4gdGhlIHBhcmFncmFwaCBvbiBwYWdlIDI1IHdoaWNo IHlvdSBxdW90ZWQgZnJvbSAocGFyYWdyYXBoIDQNCg0KPiA+ID4gPiBwYWdlIDI1KSwgdGhlIGZp cnN0IHNlbnRlbmNlIHN0YXRlcyAiSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIGFuDQoNCj4g PiA+ID4gSFBJIGltcGxlbWVudGF0aW9uIHRvIGVuc3VyZSB0aGF0IGEgc2luZ2xlLCBjb25zaXN0 ZW50IHZpZXcgb2YgdGhlDQo+ID4gPiA+IHN5c3RlbSBhbmQgaXRzIGRvbWFpbnMgYW5kIHJlc291 cmNlcyBpcyBwcmVzZW50ZWQgdG8gYWxsIEhQSQ0KVXNlcnMuIg0KPiA+ID4gPiBGcm9tIHJlYWRp bmcgdGhpcywgaXQgbWVhbnMgZXZlbiB0aGUgZmlyc3QgdXNlci4gIFRoZSBzZWNvbmQNCj4gPiA+ ID4gc2VudGVuY2UgbWVudGlvbnMgY2hhbmdlcyBiZWNvbWluZyBhdmFpbGFibGUgaW4gYSB0aW1l bHkgbWFubmVyLg0KPiA+ID4gPiBUaGlzIHdvcmQgJ2NoYW5nZXMnIGltcGxpZXMgc29tZSBzb3J0 IG9mIHN0YXRlIGJlZm9yZSBoYW5kLg0KPiA+ID4NCj4gPiA+IFllcywgYW5kIHRoaXMgaXMgYmVp bmcgZG9uZS4gVGhlIG9wZW4gcXVlc3Rpb24gdGhhdCByZW1haW5zIGlzDQo+ID4gPiB3aGV0aGVy IHRoZSBmaXJzdCBpdGVyYXRpb24gb2Ygc2VsZi1kaXNjb3ZlcnkgKm11c3QqIGhhcHBlbiBiZWZv cmUNCj4gPiA+IHRoZSBmaXJzdCBzZXNzaW9uIGlzIG9wZW5lZC4gSXQgaXMgbm90IGNsZWFyIGZy b20gdGhlIHNwZWMgb3IgZnJvbQ0KPiA+ID4gc2FIcGlTZXNzaW9uT3BlbidzIGRlc2NyaXB0aW9u Lg0KPiA+ID4gSG93ZXZlciwgYW55IGNoYW5nZXMgYXJlIGltbWVkaWF0ZWRseSBhdmFpbGFibGUg dG8gYWxsIHNlc3Npb25zDQo+ID4gY29uc2lzdGVudGx5Lg0KPiA+ID4NCj4gPiA+ID4NCj4gPiA+ ID4gSXQgaXMgYXNzdW1lZCB0aGF0IGlmIGFueSByZXNvdXJjZXMgYXJlIGFkZGVkIGFmdGVyIHRo ZSBpbml0aWFsDQo+ID4gPiA+IHNlc3Npb24gb3BlbiwgdGhlbiB0aGV5IGFyZSBGUlUncy4gSWYg dGhleSBhcmUgYWxsIEZSVSdzIHRoZW4gdGhleQ0KPiA+ID4gPiB3b3VsZCBoYXZlIHRvIGJlIHJl cG9ydGVkIGFzIGEgaG90IHN3YXAgZXZlbnQgKHBhcmFncmFwaCA1LCBwYWdlDQo+ID4gPiA+IDI3 KS4gIElmIHRoZXkgYXJlbid0IEZSVSdzLCB0aGVuIHRoZXJlIHNob3VsZCBiZSBhdCBsZWFzdCBh DQo+ID4gPiA+ICdSZXNvdXJjZSBBZGRlZCcgZXZlbnQgcmVjb3JkZWQgIGZvciBlYWNoIHJlc291 cmNlcy4gIChsYXN0DQo+ID4gPiA+IHBhcmFncmFwaCwgcGFnZSAyNikNCj4gPiA+DQo+ID4gPiBZ b3UgY2FuJ3QgYXNzdW1lIHRoYXQgTm9uLUZSVSByZXNvdXJjZSBhcmUgbm90IGFkZGVkIGFmdGVy IGluaXRpYWwNCj4gPiA+IHNlc3Npb24gb3BlbiwgYW5kIGF0IHRoZSBzYW1lIHRpbWUsIGFsbG93 IGZvciB0aGVtIHRvIGJlIGFkZGVkIGFmdGVyDQo+ID4gPiBzZXNzaW9uIG9wZW4uIEl0IGlzIGVp dGhlciBvbmUgb3IgdGhlIG90aGVyLiBBbHNvLCBzYXlpbmcgImFmdGVyDQo+ID4gPiBpbml0aWFs IHNlc3Npb24gb3BlbiIgaXMgbm90IHRoZSB2b2NhYnVsYXJ5IHdoYXQgd2FzIHVzZWQgaW4gdGhl DQo+ID4gPiBzcGVjLiBJIHdpc2ggaXQgd2FzLiBJdCBpcyBhY3R1YWxseSBub3QgdGhhdCBzcGVj aWZpYy4NCj4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEp1c3QgdGhlIG1lcmUgbWVudGlvbiBvZiB0 aGVzZSBldmVudHMgc3VnZ2VzdCBhbiBwZXJjZWl2ZWQNCj4gPiA+ID4gaW5pdGlhbGl6ZWQgc3Rh YmlsaXR5IHRvIHRoZSBSUFQgdGFibGUgYXQgdGhlIGZpcnN0IHVzZSBvZiB0aGUNCmRvbWFpbi4N Cj4gPiA+DQo+ID4gPiBXZSBuZWVkIG1vcmUgdGhhbiBpbXBsaWVkIHN1Z2dlc3Rpb25zIG9uIHRo aXMgaXNzdWUuIFdlIG5lZWQNCj4gPiA+IHNwZWNpZmljcyBmcm9tIHRoZSBzcGVjLg0KPiA+ID4N Cj4gPiA+ID4NCj4gPiA+ID4gWW91IGFyZSBpbXBseWluZyB0aGF0IHRoZXJlIGV4aXN0IGVub3Vn aCBldmlkZW5jZSBpbiB0aGUNCj4gPiA+ID4gc3BlY2lmaWNhdGlvbiB0byBjcmVhdGUgYSBsb29w IGhvbGUgd2hpY2ggdGhlIGNvbmZvcm1hbmNlIHRlc3QNCnN1aXRlDQo+ID4gPiA+IHNob3VsZCBo b25vci4NCj4gPiA+DQo+ID4gPiBUaGUgY29uZm9ybWFuY2UgdGVzdHMgc2hvdWxkIGhvbm9yIHRo ZSBzcGVjLCBidXQgc2hvdWxkIG5vdCBtYWtlDQo+ID4gPiBhc3N1bXB0aW9ucyBvbiBncmF5IGFy ZWFzIGxpa2UgdGhpcy4NCj4gPiA+DQo+ID4gPiA+IFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlcmUg aXMgdG9vIG11Y2ggZXZpZGVuY2UgdG8gdGhlDQo+ID4gPiA+IGltbWVkaWF0ZSBleGlzdGVuY2Ug b2YgYSBwb3B1bGF0ZWQgUlBUIHRhYmxlIHdoaWNoIHJlcHJlc2VudHMgdGhlDQo+ID4gPiA+IG1h bmFnZWQgc3lzdGVtLiAgVGhlIHVzdWFsIGFwcGxpY2F0aW9uIHdyaXRlciwgdXNpbmcgdGhpcw0K PiA+ID4gPiBzcGVjaWZpY2F0aW9uIHRvIGNvZGUgZnJvbSwgd2lsbCBiZXlvbmQgYSBzaGFkb3cg b2YgZG91YnQsIGV4cGVjdA0KPiA+ID4gPiB0aGF0IHRoZSBzeXN0ZW0gcmVwcmVzZW50YXRpb24g aW4gdGhlIFJQVCB0YWJsZSB3b3VsZCBiZQ0KaW1tZWRpYXRlbHkNCj4gPiA+ID4gcHJlc2VudCBh dCBmaXJzdCB1c2UuDQo+ID4gPg0KPiA+ID4gSSBkaXNhZ3JlZSBoZXJlLiBNeSBncm91cCBub3Qg b25seSB3b3JrcyBvbiB0aGUgb3BlbiBpbXBsZW1lbnRhdGlvbg0KPiA+ID4gb2YgdGhlIHNwZWMs IHdlIGFyZSBhbHNvIHVzZXJzIG9mIGl0Lg0KPiA+ID4gVGhlIGZhY3QgdGhhdCB0aGVyZSBoYXMg YmVlbiBzbyBtdWNoIGRpc2N1c3Npb24gYWJvdXQgdGhpcyBpc3N1ZSBhbmQNCj4gPiA+IHRoYXQg aXQgZG9lc24ndCBzZWVtIHRvIGRpZSBvZmYsIHByb3ZlcyB0byBtZSB0aGF0IHRoYXQgdGhlcmUg aXMNCj4gPiA+ICpub3QqIGVub3VnaCBldmlkZW5jZSBpbiB0aGUgc3BlYyB0byBzYXkgdGhhdCBh IHVzZXIgc2hvdWxkIGV4cGVjdCBhDQo+ID4gPiBmdWxsIGRpc2NvdmVyeSB0byBoYXZlIGNvbXBs ZXRlZCBiZWZvcmUgYSBzZXNzaW9uIGlzIG9wZW5lZC4NCj4gPiA+IFRoZXNlIGFyZSBhc3NlcnRh dGlvbnMgdGhhdCB0aGUgY29uZm9ybWFuY2UgdGVzdHMgbWFrZSB0aGF0IGFyZSBub3QNCj4gPiA+ IGZ1bGx5IHN1cHBvcnRlZCBieSB0aGUgc3BlYyB0aGV5IHRlc3QgY29uZm9ybWFuY2UgdG8uDQo+ ID4gPg0KPiA+ID4gPiBJZiB0aGV5IGhhZCB0byB1c2Ugc2FIcGlEaXNjb3ZlcigpIG9yIHdhaXQN Cj4gPiA+ID4gY3ljbGVzLCB0aGV5IHdvdWxkIGNvbnNpZGVyIHRoZSBpbXBsZW1lbnRhdGlvbiBi cm9rZW4uDQo+ID4gPg0KPiA+ID4gVGhlIGltcGxlbWVudGF0aW9uIGlzIGJyb2tlbiBpZiBpdCBk b2Vzbid0IG1lZXQgdGhlIHNwZWMuIE5vdA0KPiA+ID4gbmVjZXNzYXJpbHkgaWYgdGhlIHVzZXIg ZXhwZWN0cyBzb21ldGhpbmcgdGhhdCBpdCBkb2Vzbid0IGdldC4NCj4gPiA+DQo+ID4gPiA+IEl0 IHdvdWxkIGJlDQo+ID4gPiA+IHJlYXNvbmFibGUgdG8gdGhlIEhQSSBVc2VyIHRvIGV4cGVjdCBz b21lIGR5bmFtaWMgZGF0YSBvciBjaGFuZ2VzDQp0bw0KPiA+ID4gPiByZXF1aXJlIGxhdGVuY3kg dG8gc2hvdyB1cC4gIFRoaXMgZGF0YSBpcyBub3JtYWwgc3lzdGVtIG1hbmFnZW1lbnQNCj4gPiA+ ID4gY2hhbmdlcyB0byB0aGUgZGF0YSwgbm90IHRoYXQgdGhlaXIgSFBJIGltcGxlbWVudGF0aW9u LCB0aGF0IHRoZXkNCj4gPiA+ID4gZGVjaWRlZCB0byBlbXBsb3ksIGhhZCBqdXN0IGZvdW5kIGFu b3RoZXIgbm9uLUZSVSByZXNvdXJjZSB0bw0KbWFuYWdlLg0KPiA+ID4NCj4gPiA+IFRoZSBzcGVj IGlzIGNsZWFyIG9uIG1ha2luZyBkeW5hbWljIGNoYW5nZXMgYXZhaWxhYmxlIHRvIHRoZSB1c2Vy Lg0KPiA+ID4gQWdhaW4sIGl0IGlzIG5vdCBjbGVhciBvbiB3aGVuIGFuIGF1dG9tYXRpYyBkaXNj b3ZlcnkgcHJvY2Vzcw0KPiA+IHNob3VsZGNvbXBsZXRlLg0KPiA+ID4gVGhlc2UgcXVlc3Rpb24g b2YgbWluZSBoYXZlIGxpdHRsZSB0byBkbyB3aXRoIHNwZWNpZmljDQo+ID4gPiBpbXBsZW1lbnRh dGlvbnMuIFRoZXNlIGFyZSBvcGVuIHF1ZXN0aW9ucyBvbiB0aGUgSFBJIHNwZWNpZmljYXRpb24N Cj4gPiA+IGl0c2VsZiBhbmQgaG93IHRoZSBmYWN0IHRoYXQgdGhleSBhcmUgbm90IGNsZWFybHkg YW5zd2VyZWQgYWZmZWN0cw0KPiA+ID4gaG93IHlvdSBjYW4gdGVzdCBmb3IgY29uZm9ybWFuY2Ug dG8gdGhhdCBzcGVjIG9uIHRob3NlIGFyZWFzLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+DQo+ID4g PiA+IENhcmw= |
From: Wang, J. J <jin...@in...> - 2005-11-10 07:46:28
|
David, Renierm, After reading the long mail you were discussing, may I assume, = you have reached agreement that =A1=B0Sleep after SessionOpen=A1=B1 = should be removed in OpenHPI to make it be compliant with HPI spec-B?=20 =20 =20 WangJing =20 ________________________________ From: saf...@li... = [mailto:saf...@li...] On Behalf Of Renier = Morales Sent: 2005=C4=EA11=D4=C21=C8=D5 3:48 To: David McKinley Cc: hp...@sa...; saf...@li...; = saf...@li... Subject: RE: [Saftest-devel] Re:SAFTest latency issue =20 David, thanks for your response.=20 We will have to live with being compliant with this specific behavior in = daemon mode only, through the saf tests, where the daemon can be started = way in advance to any users attemting to get sessions opened.=20 The problem we have with gathering all existing resources before "the = implementation starts" is that ipmi based hardware can take up to 1 = minute and a half to "start" and snmp based plugins could take up to the = same amount of time.=20 This delay at start-up could be a problem in some situations, especially = if you need/want to send commands to a specific resource sooner than = that.=20 Regards, Renier Morales IBM Linux Technology Center http://openhpi.sf.net (845) 435-2003 (TL 295)=20 saf...@li... wrote on 10/26/2005 12:19:03 = AM: > Renier,=20 > =20 > Sorry for the delay in responding on this thread - I had several=20 > weeks of tight deadlines and couldn't give the time required to=20 > compose a useful comment. Then I started in on a thorough analysis=20 > of the spec and explanation of what I believe it says - clearly and=20 > unambiguously - on this issue. But that got way too long, so I=20 > decided to summarize. If you want the gory details, let me know,=20 > and I'll send you lots of spec references and try to explain why I=20 > think they can only be interpreted to say:=20 > =20 > 1) There are only two conditions where it is legal to add a resource > to an RPT after a user has had the opportunity to read it in an open = session:=20 > a) When a FRU is hot swapped into the system (full or=20 > simplified hot swap), or=20 > b) When a resource that was not functional when the HPI=20 > implementation started later becomes functional.=20 > =20 > 2) Both of those occurrences must be accompanied by the generation=20 > of events to all users with sessions open on the domain.=20 > =20 > 3) A resource being "not functional" is a fault condition; it means=20 > something is broken. Thus, a user is justified in interpreting a=20 > "Resource Added" event, as an exceptional thing - the recovery from=20 > a fault condition - not just a normal 'bookkeeping' entry made by=20 > the HPI implementation.=20 > =20 > Now, with all that being said, I think you are correct in noting=20 > that the specification gives a fair amount of flexibility on how=20 > startup of the HPI implementation is performed. This was done=20 > intentionally so that various implementations and operating=20 > environments could be accommodated. The A.01.01 specification=20 > included saHpiInitialize() and saHpiFinalize() functions. These=20 > were removed in the B.01.01 specification in large part because we=20 > could not find consistent rules for the use of those functions that=20 > applied in all the different implementation scenarios the=20 > specification needed to support. So, how the HPI implementation is=20 > started and stopped is left as an "implementation-specific" item.=20 > =20 > But, I don't think that it is reasonable to conclude that this = flexibility in=20 > how an implementation is started means that it is undefined whether=20 > or not an implementation that a user can access has started yet. =20 > The whole HPI specification is defined as a set of API calls, and=20 > the behavior of an HPI implementation is exhibited only through=20 > returning return codes and output parameters in response to the=20 > various HPI functions being called with certain input parameters. =20 > If a user can call an HPI function and get a return back, then the=20 > HPI implementation is running, by definition. If it is running, it=20 > must have been started, somehow.=20 > =20 > Putting this together, I think there is only one way you can return=20 > an empty RPT to a user while there are non-FRU resources in the=20 > system, or FRU resources that were inserted before the HPI=20 > implementation was started. You would have to declare that every=20 > one of these resources is in a failed state. Then, when each=20 > resource is added to the RPT (irregardless of whether or not a user=20 > calls saHpiDiscover() ) the appropriate hot swap or "resource added" > event must be issued to each user that is subscribed to receive=20 > events - that event communicating the recovery of the resource from=20 > a fault condition. While I think you could argue that an=20 > implementation that behaved this way is technically compliant with=20 > the specification, I can't believe that you would want to advertise=20 > such behavior.=20 > =20 > It seems to me that a more practical - and palatable - solution is=20 > to define an implementation-specific startup process that has to run > before you claim that the implementation is compliant. This startup > process would open a session and cause the RPT to be populated. =20 > Then, real users can run, and see a functioning implementation with=20 > working resources reflected in the RPT. I'm not that familiar with=20 > OpenHPI - so maybe this works or maybe it doesn't.=20 > =20 > David McKinley=20 > Augmentix Corporation=20 > =20 > =20 > "David McKinley" <dav...@au...> wrote on 09/28/2005=20 > 06:23:11 PM: >=20 > > Renier,=20 > > =20 > > I'm still planning a more complete, thoughtful response, but there=20 > > is one part of your email that seems worth a quick comment -=20 > > =20 > > You say, referring to section 3.5 in the specification:=20 > > =20 > > It also says that those discovery steps you refer to is how a=20 > > *typical* discovery process will happen. Can discovery happen in=20 > > other ways then?=20 > > Yes, discovery can happen other ways. It can happen any way that a=20 > > user program chooses, so long as whatever the user chooses to do is=20 > > supported by the implementation. And, a compliant implementation=20 > > must support whatever it is that the specification says it must = support.=20 > > =20 > > Well, whatever the specification may or may not say elsewhere, in=20 > > section 3.5 it seems pretty clearly to be saying, "Here is one way a > > user can do discovery" - in fact it goes further to say that this=20 > > way to do discovery is "typical". So, can an implementation that=20 > > does not support users doing discovery the way the specification=20 > > identifies as "typical" reasonably be considered compliant? Surely, > > at the very least, the implementation needs to support the usage=20 > > that the specification itself spells out, doesn't it?=20 >=20 > That section of the spec says more that just "Hey, this is a usual=20 > way of doing discover: step 1, step 2, step 3, step 4,...".=20 > It also says that"Throughout the discovery process, an HPI User=20 > should make sure that no resources or domain references were added=20 > or removed. This can be accomplished by using RPT and DRT update=20 > counters and events."=20 >=20 > So my question is, if an HPI User should check counters and events=20 > throughout discovery, but it is not mentioned in the steps outlined, > does that mean that a user doesn't have to check counters and events > based on the typical discovery process? or does it mean that=20 > checking counters and events is implied in any discovery steps done?=20 >=20 >=20 > > =20 > > Some of your other arguments are a bit more interesting, and I'm=20 > > thinking about them . . . .=20 > > David=20 > > =20 > >=20 > > From: saf...@li... [mailto:saftest- > > dev...@li...] On Behalf Of Renier Morales > > Sent: Wednesday, September 28, 2005 4:16 PM > > To: Carl McAdams > > Cc: saf...@li...; saftest-hpi-devel@lists. > > sourceforge.net > > Subject: [Saftest-devel] Re:SAFTest latency issue >=20 > >=20 > > Carl McAdams/Austin/IBM wrote on 09/28/2005 03:28:02 PM: > >=20 > > > Renier,=20 > > >=20 > > > The specification gives many indications that then non-FRU = resources > > > are present immediately.=20 > >=20 > > Yes, and it also allows for Non-FRU resources to be added at a later > > time if they become functional after the implementation has=20 > > "started". But what does "started" means? I, as an HPI user, would=20 > > expect the description of saHpiSessionOpen() to say if "started"=20 > > means after saHpiSessionOpen returns. The spec is not clear on this=20 > > (maybe it means after the first self discovery has happened, which=20 > > could be independent of opening a session) and that is part of the=20 > > issue, which hopefully will be made clearer in a future revision=20 > of the spec. > >=20 > > >=20 > > > In reference of the entire section '3.5 Discovery' on pages 24 -=20 > > > 25. Without even suggesting that the user to overcome any = latency,=20 > > > the section walks the user from opening a session to walking = entity=20 > > > paths. In the last paragraph of the section it says that the "an=20 > > > HPI User may build a physical model of the system using the Entity = > > > Paths contained in each RPT entry or RDR. This would allow an HPI = > > > User to determine the true set of entries that exist in the = system"=20 > >=20 > > It also says that those discovery steps you refer to is how a=20 > > *typical* discovery process will happen. Can discovery happen in=20 > > other ways then?=20 > > Page 24 also says, throughout the discovery process, an HPI user=20 > > should make sure that no resources or domain references were added=20 > > or removed. That that can be accomplished by using the RPT/DRT=20 > > update counters and events.=20 > > A user must always do this and it is not being done in the=20 > > conformance tests when looking for resource with specific = capabilities.=20 > > The , "throughout the discovery process" phrase is interesting as it > > gives me the idea that the discovery process a user performs in HPI=20 > > is on-going. So a user will continually refresh his/her view of the=20 > > HPI world by inspecting RPT,DRT, counters, events, etc. over and=20 > over again.=20 > >=20 > > >=20 > > > Even in the paragraph on page 25 which you quoted from (paragraph = 4=20 > > > page 25), the first sentence states "It is the responsibility of = an=20 > > > HPI implementation to ensure that a single, consistent view of the = > > > system and its domains and resources is presented to all HPI = Users." > > > From reading this, it means even the first user. The second=20 > > > sentence mentions changes becoming available in a timely manner. =20 > > > This word 'changes' implies some sort of state before hand. =20 > >=20 > > Yes, and this is being done. The open question that remains is=20 > > whether the first iteration of self-discovery *must* happen before=20 > > the first session is opened. It is not clear from the spec or from=20 > > saHpiSessionOpen's description.=20 > > However, any changes are immediatedly available to all sessions=20 > consistently. > >=20 > > >=20 > > > It is assumed that if any resources are added after the initial=20 > > > session open, then they are FRU's. If they are all FRU's then they = > > > would have to be reported as a hot swap event (paragraph 5, page=20 > > > 27). If they aren't FRU's, then there should be at least a=20 > > > 'Resource Added' event recorded for each resources. (last=20 > > > paragraph, page 26)=20 > >=20 > > You can't assume that Non-FRU resource are not added after initial=20 > > session open, and at the same time, allow for them to be added after > > session open. It is either one or the other. Also, saying "after=20 > > initial session open" is not the vocabulary what was used in the=20 > > spec. I wish it was. It is actually not that specific.=20 > >=20 > > >=20 > > > Just the mere mention of these events suggest an perceived=20 > > > initialized stability to the RPT table at the first use of the = domain.=20 > >=20 > > We need more than implied suggestions on this issue. We need=20 > > specifics from the spec.=20 > >=20 > > >=20 > > > You are implying that there exist enough evidence in the=20 > > > specification to create a loop hole which the conformance test = suite > > > should honor.=20 > >=20 > > The conformance tests should honor the spec, but should not make=20 > > assumptions on gray areas like this.=20 > >=20 > > > The problem is that there is too much evidence to the > > > immediate existence of a populated RPT table which represents the=20 > > > managed system. The usual application writer, using this=20 > > > specification to code from, will beyond a shadow of doubt, expect=20 > > > that the system representation in the RPT table would be = immediately > > > present at first use.=20 > >=20 > > I disagree here. My group not only works on the open implementation=20 > > of the spec, we are also users of it.=20 > > The fact that there has been so much discussion about this issue and > > that it doesn't seem to die off, proves to me that that there is=20 > > *not* enough evidence in the spec to say that a user should expect a > > full discovery to have completed before a session is opened.=20 > > These are assertations that the conformance tests make that are not=20 > > fully supported by the spec they test conformance to.=20 > >=20 > > > If they had to use saHpiDiscover() or wait=20 > > > cycles, they would consider the implementation broken.=20 > >=20 > > The implementation is broken if it doesn't meet the spec. Not=20 > > necessarily if the user expects something that it doesn't get.=20 > >=20 > > > It would be=20 > > > reasonable to the HPI User to expect some dynamic data or changes = to > > > require latency to show up. This data is normal system management = > > > changes to the data, not that their HPI implementation, that they=20 > > > decided to employ, had just found another non-FRU resource to = manage.=20 > >=20 > > The spec is clear on making dynamic changes available to the user.=20 > > Again, it is not clear on when an automatic discovery process=20 > shouldcomplete. > > These question of mine have little to do with specific=20 > > implementations. These are open questions on the HPI specification=20 > > itself and how the fact that they are not clearly answered affects=20 > > how you can test for conformance to that spec on those areas.=20 > >=20 > > =20 > > >=20 > > > Carl=20 |
From: Xiong, C. <cry...@in...> - 2005-11-02 10:28:39
|
saftest_HPI-B_01_01_1.0.4 is released, please download it from: http://prdownloads.sourceforge.net/saftest/saftest_HPI-B_01_01_1_0_4.tar .gz?download =20 =20 This is bug fix release after HPI-B.01.01_1.0.3. In this release: - Continuously Bug fixes for HPI test WG reviewed sessions. Thanks UNH team and Li Qun. - Bug fixes for Control, Watchdogtimer, Annunciator. Thanks Donald Barre. ToDos: - Continue to do bug fixes=20 ********* Basic Information ********************* The README in the release package describes how to use the framework, how to contribute more tests to the framework in a brief. For more details, please refer to Framework_Specification.htm document under doc directory in the release package. =20 The goal of this project is to create conformance test suite for SAF spec, including AIS A.01.01, AIS B.01.01, HPI A.01.01 and HPI B.01.01 spec.=20 =20 Any more comments, please discuss in the following mailing list: saf...@li... (For the whole project) saf...@li... (For HPI part) saf...@li... (For AIS part) =20 The webpage of this project can be found here: <http://saftest.sourceforge.net/> http://saftest.sourceforge.net/ =20 Thanks, Crystal =20 =20 |
From: Xiong, C. <cry...@in...> - 2005-11-01 02:42:44
|
Hi List,=20 I would like to introduce Wang Jing as sub maintainer to HPI tests, and Yu Ling as sub maintainer to AIS tests starting from Nov.=20 Wang Jing and Yu Ling have working on HPI and AIS tests development separately for quite a long time and did great job on maintaining those hug amount of tests; they are very familiar with the tests details, bugs, issues, future development plans, etc. So this is pretty natural for them to take the sub maintainership for these two parts respectively.=20 Thanks, Crystal |
From: Renier M. <re...@us...> - 2005-10-31 19:48:36
|
David, thanks for your response. We will have to live with being compliant with this specific behavior in daemon mode only, through the saf tests, where the daemon can be started way in advance to any users attemting to get sessions opened. The problem we have with gathering all existing resources before "the implementation starts" is that ipmi based hardware can take up to 1 minute and a half to "start" and snmp based plugins could take up to the same amount of time. This delay at start-up could be a problem in some situations, especially if you need/want to send commands to a specific resource sooner than that. Regards, Renier Morales IBM Linux Technology Center http://openhpi.sf.net (845) 435-2003 (TL 295) saf...@li... wrote on 10/26/2005 12:19:03 AM: > Renier, > > Sorry for the delay in responding on this thread - I had several > weeks of tight deadlines and couldn't give the time required to > compose a useful comment. Then I started in on a thorough analysis > of the spec and explanation of what I believe it says - clearly and > unambiguously - on this issue. But that got way too long, so I > decided to summarize. If you want the gory details, let me know, > and I'll send you lots of spec references and try to explain why I > think they can only be interpreted to say: > > 1) There are only two conditions where it is legal to add a resource > to an RPT after a user has had the opportunity to read it in an open session: > a) When a FRU is hot swapped into the system (full or > simplified hot swap), or > b) When a resource that was not functional when the HPI > implementation started later becomes functional. > > 2) Both of those occurrences must be accompanied by the generation > of events to all users with sessions open on the domain. > > 3) A resource being "not functional" is a fault condition; it means > something is broken. Thus, a user is justified in interpreting a > "Resource Added" event, as an exceptional thing - the recovery from > a fault condition - not just a normal 'bookkeeping' entry made by > the HPI implementation. > > Now, with all that being said, I think you are correct in noting > that the specification gives a fair amount of flexibility on how > startup of the HPI implementation is performed. This was done > intentionally so that various implementations and operating > environments could be accommodated. The A.01.01 specification > included saHpiInitialize() and saHpiFinalize() functions. These > were removed in the B.01.01 specification in large part because we > could not find consistent rules for the use of those functions that > applied in all the different implementation scenarios the > specification needed to support. So, how the HPI implementation is > started and stopped is left as an "implementation-specific" item. > > But, I don't think that it is reasonable to conclude that this flexibility in > how an implementation is started means that it is undefined whether > or not an implementation that a user can access has started yet. > The whole HPI specification is defined as a set of API calls, and > the behavior of an HPI implementation is exhibited only through > returning return codes and output parameters in response to the > various HPI functions being called with certain input parameters. > If a user can call an HPI function and get a return back, then the > HPI implementation is running, by definition. If it is running, it > must have been started, somehow. > > Putting this together, I think there is only one way you can return > an empty RPT to a user while there are non-FRU resources in the > system, or FRU resources that were inserted before the HPI > implementation was started. You would have to declare that every > one of these resources is in a failed state. Then, when each > resource is added to the RPT (irregardless of whether or not a user > calls saHpiDiscover() ) the appropriate hot swap or "resource added" > event must be issued to each user that is subscribed to receive > events - that event communicating the recovery of the resource from > a fault condition. While I think you could argue that an > implementation that behaved this way is technically compliant with > the specification, I can't believe that you would want to advertise > such behavior. > > It seems to me that a more practical - and palatable - solution is > to define an implementation-specific startup process that has to run > before you claim that the implementation is compliant. This startup > process would open a session and cause the RPT to be populated. > Then, real users can run, and see a functioning implementation with > working resources reflected in the RPT. I'm not that familiar with > OpenHPI - so maybe this works or maybe it doesn't. > > David McKinley > Augmentix Corporation > > > "David McKinley" <dav...@au...> wrote on 09/28/2005 > 06:23:11 PM: > > > Renier, > > > > I'm still planning a more complete, thoughtful response, but there > > is one part of your email that seems worth a quick comment - > > > > You say, referring to section 3.5 in the specification: > > > > It also says that those discovery steps you refer to is how a > > *typical* discovery process will happen. Can discovery happen in > > other ways then? > > Yes, discovery can happen other ways. It can happen any way that a > > user program chooses, so long as whatever the user chooses to do is > > supported by the implementation. And, a compliant implementation > > must support whatever it is that the specification says it must support. > > > > Well, whatever the specification may or may not say elsewhere, in > > section 3.5 it seems pretty clearly to be saying, "Here is one way a > > user can do discovery" - in fact it goes further to say that this > > way to do discovery is "typical". So, can an implementation that > > does not support users doing discovery the way the specification > > identifies as "typical" reasonably be considered compliant? Surely, > > at the very least, the implementation needs to support the usage > > that the specification itself spells out, doesn't it? > > That section of the spec says more that just "Hey, this is a usual > way of doing discover: step 1, step 2, step 3, step 4,...". > It also says that"Throughout the discovery process, an HPI User > should make sure that no resources or domain references were added > or removed. This can be accomplished by using RPT and DRT update > counters and events." > > So my question is, if an HPI User should check counters and events > throughout discovery, but it is not mentioned in the steps outlined, > does that mean that a user doesn't have to check counters and events > based on the typical discovery process? or does it mean that > checking counters and events is implied in any discovery steps done? > > > > > > Some of your other arguments are a bit more interesting, and I'm > > thinking about them . . . . > > David > > > > > > From: saf...@li... [mailto:saftest- > > dev...@li...] On Behalf Of Renier Morales > > Sent: Wednesday, September 28, 2005 4:16 PM > > To: Carl McAdams > > Cc: saf...@li...; saftest-hpi-devel@lists. > > sourceforge.net > > Subject: [Saftest-devel] Re:SAFTest latency issue > > > > > Carl McAdams/Austin/IBM wrote on 09/28/2005 03:28:02 PM: > > > > > Renier, > > > > > > The specification gives many indications that then non-FRU resources > > > are present immediately. > > > > Yes, and it also allows for Non-FRU resources to be added at a later > > time if they become functional after the implementation has > > "started". But what does "started" means? I, as an HPI user, would > > expect the description of saHpiSessionOpen() to say if "started" > > means after saHpiSessionOpen returns. The spec is not clear on this > > (maybe it means after the first self discovery has happened, which > > could be independent of opening a session) and that is part of the > > issue, which hopefully will be made clearer in a future revision > of the spec. > > > > > > > > In reference of the entire section '3.5 Discovery' on pages 24 - > > > 25. Without even suggesting that the user to overcome any latency, > > > the section walks the user from opening a session to walking entity > > > paths. In the last paragraph of the section it says that the "an > > > HPI User may build a physical model of the system using the Entity > > > Paths contained in each RPT entry or RDR. This would allow an HPI > > > User to determine the true set of entries that exist in the system" > > > > It also says that those discovery steps you refer to is how a > > *typical* discovery process will happen. Can discovery happen in > > other ways then? > > Page 24 also says, throughout the discovery process, an HPI user > > should make sure that no resources or domain references were added > > or removed. That that can be accomplished by using the RPT/DRT > > update counters and events. > > A user must always do this and it is not being done in the > > conformance tests when looking for resource with specific capabilities. > > The , "throughout the discovery process" phrase is interesting as it > > gives me the idea that the discovery process a user performs in HPI > > is on-going. So a user will continually refresh his/her view of the > > HPI world by inspecting RPT,DRT, counters, events, etc. over and > over again. > > > > > > > > Even in the paragraph on page 25 which you quoted from (paragraph 4 > > > page 25), the first sentence states "It is the responsibility of an > > > HPI implementation to ensure that a single, consistent view of the > > > system and its domains and resources is presented to all HPI Users." > > > From reading this, it means even the first user. The second > > > sentence mentions changes becoming available in a timely manner. > > > This word 'changes' implies some sort of state before hand. > > > > Yes, and this is being done. The open question that remains is > > whether the first iteration of self-discovery *must* happen before > > the first session is opened. It is not clear from the spec or from > > saHpiSessionOpen's description. > > However, any changes are immediatedly available to all sessions > consistently. > > > > > > > > It is assumed that if any resources are added after the initial > > > session open, then they are FRU's. If they are all FRU's then they > > > would have to be reported as a hot swap event (paragraph 5, page > > > 27). If they aren't FRU's, then there should be at least a > > > 'Resource Added' event recorded for each resources. (last > > > paragraph, page 26) > > > > You can't assume that Non-FRU resource are not added after initial > > session open, and at the same time, allow for them to be added after > > session open. It is either one or the other. Also, saying "after > > initial session open" is not the vocabulary what was used in the > > spec. I wish it was. It is actually not that specific. > > > > > > > > Just the mere mention of these events suggest an perceived > > > initialized stability to the RPT table at the first use of the domain. > > > > We need more than implied suggestions on this issue. We need > > specifics from the spec. > > > > > > > > You are implying that there exist enough evidence in the > > > specification to create a loop hole which the conformance test suite > > > should honor. > > > > The conformance tests should honor the spec, but should not make > > assumptions on gray areas like this. > > > > > The problem is that there is too much evidence to the > > > immediate existence of a populated RPT table which represents the > > > managed system. The usual application writer, using this > > > specification to code from, will beyond a shadow of doubt, expect > > > that the system representation in the RPT table would be immediately > > > present at first use. > > > > I disagree here. My group not only works on the open implementation > > of the spec, we are also users of it. > > The fact that there has been so much discussion about this issue and > > that it doesn't seem to die off, proves to me that that there is > > *not* enough evidence in the spec to say that a user should expect a > > full discovery to have completed before a session is opened. > > These are assertations that the conformance tests make that are not > > fully supported by the spec they test conformance to. > > > > > If they had to use saHpiDiscover() or wait > > > cycles, they would consider the implementation broken. > > > > The implementation is broken if it doesn't meet the spec. Not > > necessarily if the user expects something that it doesn't get. > > > > > It would be > > > reasonable to the HPI User to expect some dynamic data or changes to > > > require latency to show up. This data is normal system management > > > changes to the data, not that their HPI implementation, that they > > > decided to employ, had just found another non-FRU resource to manage. > > > > The spec is clear on making dynamic changes available to the user. > > Again, it is not clear on when an automatic discovery process > shouldcomplete. > > These question of mine have little to do with specific > > implementations. These are open questions on the HPI specification > > itself and how the fact that they are not clearly answered affects > > how you can test for conformance to that spec on those areas. > > > > > > > > > > Carl |
From: Renier M. <re...@us...> - 2005-10-18 19:48:03
|
"David McKinley" <dav...@au...> wrote on 09/28/2005 06:23:11 PM: > Renier, > > I'm still planning a more complete, thoughtful response, but there > is one part of your email that seems worth a quick comment - > > You say, referring to section 3.5 in the specification: > > It also says that those discovery steps you refer to is how a > *typical* discovery process will happen. Can discovery happen in > other ways then? > Yes, discovery can happen other ways. It can happen any way that a > user program chooses, so long as whatever the user chooses to do is > supported by the implementation. And, a compliant implementation > must support whatever it is that the specification says it must support. > > Well, whatever the specification may or may not say elsewhere, in > section 3.5 it seems pretty clearly to be saying, "Here is one way a > user can do discovery" - in fact it goes further to say that this > way to do discovery is "typical". So, can an implementation that > does not support users doing discovery the way the specification > identifies as "typical" reasonably be considered compliant? Surely, > at the very least, the implementation needs to support the usage > that the specification itself spells out, doesn't it? That section of the spec says more that just "Hey, this is a usual way of doing discover: step 1, step 2, step 3, step 4,...". It also says that"Throughout the discovery process, an HPI User should make sure that no resources or domain references were added or removed. This can be accomplished by using RPT and DRT update counters and events." So my question is, if an HPI User should check counters and events throughout discovery, but it is not mentioned in the steps outlined, does that mean that a user doesn't have to check counters and events based on the typical discovery process? or does it mean that checking counters and events is implied in any discovery steps done? > > Some of your other arguments are a bit more interesting, and I'm > thinking about them . . . . > David > > Renier |
From: Renier M. <re...@us...> - 2005-10-18 19:27:46
|
"David McKinley" <dav...@au...> wrote on 09/28/2005 06:23:11 PM: > Renier, > > I'm still planning a more complete, thoughtful response, but there > is one part of your email that seems worth a quick comment - > > You say, referring to section 3.5 in the specification: > > It also says that those discovery steps you refer to is how a > *typical* discovery process will happen. Can discovery happen in > other ways then? > Yes, discovery can happen other ways. It can happen any way that a > user program chooses, so long as whatever the user chooses to do is > supported by the implementation. And, a compliant implementation > must support whatever it is that the specification says it must support. > > Well, whatever the specification may or may not say elsewhere, in > section 3.5 it seems pretty clearly to be saying, "Here is one way a > user can do discovery" - in fact it goes further to say that this > way to do discovery is "typical". So, can an implementation that > does not support users doing discovery the way the specification > identifies as "typical" reasonably be considered compliant? Surely, > at the very least, the implementation needs to support the usage > that the specification itself spells out, doesn't it? That section of the spec says more that just "Hey, this is a usual way of doing discover: step 1, step 2, step 3, step 4,...". It also says that"Throughout the discovery process, an HPI User should make sure that no resources or domain references were added or removed. This can be accomplished by using RPT and DRT update counters and events." So my question is, if an HPI User should check counters and events throughout discovery, but it is not mentioned in the steps outlined, does that mean that a user doesn't have to check counters and events based on the typical discovery process? or does it mean that checking counters and events is implied in any discovery steps done? > > Some of your other arguments are a bit more interesting, and I'm > thinking about them . . . . > David > > > From: saf...@li... [mailto:saftest- > dev...@li...] On Behalf Of Renier Morales > Sent: Wednesday, September 28, 2005 4:16 PM > To: Carl McAdams > Cc: saf...@li...; saftest-hpi-devel@lists. > sourceforge.net > Subject: [Saftest-devel] Re:SAFTest latency issue > > Carl McAdams/Austin/IBM wrote on 09/28/2005 03:28:02 PM: > > > Renier, > > > > The specification gives many indications that then non-FRU resources > > are present immediately. > > Yes, and it also allows for Non-FRU resources to be added at a later > time if they become functional after the implementation has > "started". But what does "started" means? I, as an HPI user, would > expect the description of saHpiSessionOpen() to say if "started" > means after saHpiSessionOpen returns. The spec is not clear on this > (maybe it means after the first self discovery has happened, which > could be independent of opening a session) and that is part of the > issue, which hopefully will be made clearer in a future revision of the spec. > > > > > In reference of the entire section '3.5 Discovery' on pages 24 - > > 25. Without even suggesting that the user to overcome any latency, > > the section walks the user from opening a session to walking entity > > paths. In the last paragraph of the section it says that the "an > > HPI User may build a physical model of the system using the Entity > > Paths contained in each RPT entry or RDR. This would allow an HPI > > User to determine the true set of entries that exist in the system" > > It also says that those discovery steps you refer to is how a > *typical* discovery process will happen. Can discovery happen in > other ways then? > Page 24 also says, throughout the discovery process, an HPI user > should make sure that no resources or domain references were added > or removed. That that can be accomplished by using the RPT/DRT > update counters and events. > A user must always do this and it is not being done in the > conformance tests when looking for resource with specific capabilities. > The , "throughout the discovery process" phrase is interesting as it > gives me the idea that the discovery process a user performs in HPI > is on-going. So a user will continually refresh his/her view of the > HPI world by inspecting RPT,DRT, counters, events, etc. over and over again. > > > > > Even in the paragraph on page 25 which you quoted from (paragraph 4 > > page 25), the first sentence states "It is the responsibility of an > > HPI implementation to ensure that a single, consistent view of the > > system and its domains and resources is presented to all HPI Users." > > From reading this, it means even the first user. The second > > sentence mentions changes becoming available in a timely manner. > > This word 'changes' implies some sort of state before hand. > > Yes, and this is being done. The open question that remains is > whether the first iteration of self-discovery *must* happen before > the first session is opened. It is not clear from the spec or from > saHpiSessionOpen's description. > However, any changes are immediatedly available to all sessions consistently. > > > > > It is assumed that if any resources are added after the initial > > session open, then they are FRU's. If they are all FRU's then they > > would have to be reported as a hot swap event (paragraph 5, page > > 27). If they aren't FRU's, then there should be at least a > > 'Resource Added' event recorded for each resources. (last > > paragraph, page 26) > > You can't assume that Non-FRU resource are not added after initial > session open, and at the same time, allow for them to be added after > session open. It is either one or the other. Also, saying "after > initial session open" is not the vocabulary what was used in the > spec. I wish it was. It is actually not that specific. > > > > > Just the mere mention of these events suggest an perceived > > initialized stability to the RPT table at the first use of the domain. > > We need more than implied suggestions on this issue. We need > specifics from the spec. > > > > > You are implying that there exist enough evidence in the > > specification to create a loop hole which the conformance test suite > > should honor. > > The conformance tests should honor the spec, but should not make > assumptions on gray areas like this. > > > The problem is that there is too much evidence to the > > immediate existence of a populated RPT table which represents the > > managed system. The usual application writer, using this > > specification to code from, will beyond a shadow of doubt, expect > > that the system representation in the RPT table would be immediately > > present at first use. > > I disagree here. My group not only works on the open implementation > of the spec, we are also users of it. > The fact that there has been so much discussion about this issue and > that it doesn't seem to die off, proves to me that that there is > *not* enough evidence in the spec to say that a user should expect a > full discovery to have completed before a session is opened. > These are assertations that the conformance tests make that are not > fully supported by the spec they test conformance to. > > > If they had to use saHpiDiscover() or wait > > cycles, they would consider the implementation broken. > > The implementation is broken if it doesn't meet the spec. Not > necessarily if the user expects something that it doesn't get. > > > It would be > > reasonable to the HPI User to expect some dynamic data or changes to > > require latency to show up. This data is normal system management > > changes to the data, not that their HPI implementation, that they > > decided to employ, had just found another non-FRU resource to manage. > > The spec is clear on making dynamic changes available to the user. > Again, it is not clear on when an automatic discovery process shouldcomplete. > These question of mine have little to do with specific > implementations. These are open questions on the HPI specification > itself and how the fact that they are not clearly answered affects > how you can test for conformance to that spec on those areas. > > > > > > Carl > > > > Carl McAdams > > Software Engineer > > IBM BladeCenter Software > > 11400 BURNET ROAD, AUSTIN, TX 78758, USA > > (512)823-3319 > > ca...@us... > > > > Renier Morales/Poughkeepsie/IBM@IBMUS > > Sent by: saf...@li... > > > > 09/28/2005 01:18 PM > > > > Please respond to > > Renier Morales > > > > To > > > > saf...@li..., saf...@li... > > > > cc > > > > Subject > > > > [Saftest-hpi-devel] RE: [Saftest-devel] SAFTest latency issue > > > > > > Actually, I have to correct myself. OpenHPI does support running as > > a daemon. Still, should it matter to the conformance tests? Should > > they assume a daemon or not from an implemenation? and should they > > go straight from sessionOpen to inspection of the RPT assuming the > > resource must be there by the time they check? > > > > Regards, > > > > Renier Morales > > > > saf...@li... wrote on 28/09/2005 02:12:04 PM: > > > > > > > > Ste...@ra... wrote on 28/09/2005 01:51:43 PM: > > > > > > > If I understand, only the initial SessionOpen is missing resources. > > > > Subsequent SessionOpens will be populated by the first, it just > > take time. > > > > > > Right. > > > > > > > > > > > It still seems to me that this initial OpenHPI SessionOpen to a > > > > domain needs to complete an internal Discover before returning. > > > > > > The spec is not clear on whether SessionOpen needs to do this within > > > itself. That would be like calling saHpiDiscover() within > > > saHpiSessionOpen(). Doin this is not necessary as saHpiDiscover() > > > already exists publicly for the user if he needs a current view now > > > and wants to block for it. > > > I think the user should decide this, otherwise, he can check for > > > events and work with them as they come. This would be much faster > > > for the user if he is interested in a resource that will become > > > available in HPI half-way through a complete discovery process. > > > > > > > > > > > If the first and second session do not overlap (session A closes > > > > before session B starts), does the discovery need to be repeated? > > > > > > No, doesn't have to be repeated within the same HPI user app's process. > > > > > > > Will data (e.g. Resource Tags) set in the first session "survive" to > > > > the second? If this is the case, then only the first hpitest should > > > > have a problem. Won't subsequent tests benefit from the first > > open session? > > > > > > You are assuming that the HPI implementation works as a daemon. It > > > is not true in OpenHPI's case. Whether it works as a daemon or not > > > shouldn't be an issue for the saf conformance tests. > > > If the tests are engineered to assume this about an implementation, > > > then I think that is a mistake. It is not something that is > > > specified in the spec. > > > > > > > > > > > --stevem > > > > > > > > saf...@li... wrote on 09/28/2005 > 11:58:22 AM: > > > > > > > > > > > > > > Hi David, > > > > > > > > > > Yes, this is entirely a start-up issue. Events are in fact sent to > > > > > all users (sessions). The RPT is in fact the same for all sessions > > > > > of a domain. Of course, events about a resource are only sent to > > > > > domains (the sessions connected to them) that have the resource > > > intheir RPT. > > > > > > > > > > In a situation in which a session is opened and a user wants to know > > > > > exactly when the Domain is current and up-to-date, it makes sense > > > > > for them to use saHpiDiscover as this blocks until everything is up- > > > > > to-date and returns. Otherwise a user will logically be checking > > > > > update counts and blocking on events to get updates from the system > > > > > as they come. > > > > > > > > > > None of these two discovery behaviours are done by the conformance > > > > > tests. This is even though the second behaviour (checking for events > > > > > and update counts) is implied in the typical discovery process > > > > > describe in the HPI Model part of the spec. > > > > > So when a tests goes from opening a session right to inspecting the > > > > > RPT for a particular resource, and then reporting NOTSUPPORT when it > > > > > doesn't find it (when the resource would have come up some short > > > > > time later as the Domains update themselves), you are left with a > > > > > not so usefult result. > > > > > > > > > > Seems to me that if you need a domain updated at a certain time, you > > > > > should call discover, otherwise you should check update > > > > > counts/timestamps and events. > > > > > > > > > > Regards, > > > > > > > > > > Renier Morales > > > > > > > > > > "David McKinley" <dav...@au...> wrote on 27/09/2005 > > > > > 08:21:03 PM: > > > > > > > > > > > Reiner, > > > > > > > > > > > > I've been trying to respond to your questions - but there is one > > > > > > thing I'm confused about. In your implementation, is there latency > > > > > > for each user when they open a session before "their" copy of the > > > > > > RPT is populated, or is this just an issue with the first user that > > > > > > opens a session? If this is an issue with each user, there seems to > > > > > > be some pretty straight-forward language in the spec that would > > > > > > address it - (e.g., first sentence in section 3.6.1, page 25: It is > > > > > > the responsibility of an HPI implementation to ensure thata single, > > > > > > consistent view of the system and its domains and resources is > > > > > > presented to all HPI Users.) There is also a whole discussion to > > > > > > have about how when the RPT is updated events must be generated, and > > > > > > events must be sent to all users - implying that you cannot have > > > > > > updates that only appear to some users. > > > > > > > > > > > > If, on the other hand, this is just a "start-up" issue when the > > > > > > first user calls saHpiSessionOpen(), then the discussion might be a > > > > > > bit different. . . . . > > > > > > > > > > > > David McKinley > > > > > > Augmentix Corporation > > > > > > > > > > > > > > > > > > From: saf...@li... [mailto:saftest- > > > > > > dev...@li...] On Behalf Of Renier Morales > > > > > > Sent: Tuesday, September 27, 2005 5:17 PM > > > > > > To: saf...@li...; saftest-hpi-devel@lists. > > > > > > sourceforge.net > > > > > > Subject: [Saftest-devel] SAFTest latency issue > > > > > > > > > > > > > > > > > We are struggling with a possible latency issue either in the > > > > > > SAFTest HPI suite or OpenHPI. > > > > > > > > > > > > It has been established that "The RPT is automatically built and > > > > > > maintained by the HPI implementation" (HPI B Spec, page 16, > > > > > > paragraph 7) and that "The HPI implementation is required to > > > > > > discover the resources and entities under management control" and > > > > > > "This table [RPT] should represent up-to-date information on the > > > > > > resources currently present in the domain with which it is > > > > > > associated" (HPI B Spec, page 39, paragraph 1). So it is expected > > > > > > that the implementation will keep the RPT up-to-date without the > > > > > > user having to explicitly call saHpiDiscover(). Some latency in this > > > > > > process is allowed, though: "In the face of multiple concurrent > > > > > > changes, the HPI implementation should attempt to make updates > > > > > > visible system-wide in a timely manner; however, no specific timing > > > > > > is specified" (page 25, paragraph 4). > > > > > > > > > > > > Our implementation complies with this by starting a thread at > > > > > > initialization that inspects each hardware plugin for changes and > > > > > > events continually. > > > > > > > > > > > > What has not been established, for us from looking at the > > > > > > specification, is that present resources should have their > > > > > > corresponding RPT entries in the RPT right after saHpiSessionOpen() > > > > > > and that it is not acceptable if the RPT entries show up in the next > > > > > > few seconds after saHpiSessionOpen() by the self-updating behavior > > > > > of the RPT. > > > > > > The conformance tests seem to make this assertion by opening a > > > > > > session and reading the RPT right away without checking for updates > > > > > > or events. This fails if there are no resources in the RPT right > > > > > > after saHpiSessionOpen(). > > > > > > > > > > > > What we have found in the current specification (HPI B) that is > > > > > > close to this issue is the following: > > > > > > - "Resources entries will be dynamically added to or removed from > > > > > > the RPT as Field Replaceable Units (FRUs) are physically added to or > > > > > > removed from a platform" (page 16, paragraph 7). > > > > > > - "The discovery process will typically proceed in a number of steps > > > > > > [steps include opening session and reading the RPT]...Throughout the > > > > > > discovery process, an HPI User should make sure that no resources or > > > > > > domain references were added or removed. This can be accomplished by > > > > > > using RPT and DRT update counters and events." (page 24, > > paragraph 9). > > > > > > - "If a resource is not functional at the time an HPI implementation > > > > > > is started, the resource may not be detected, and thus notpopulated > > > > > > in the RPTs of domains that should contain the resource. It is not > > > > > > the function of the HPI implementation to insure that all resources > > > > > > that ought to be present actually are present, so this failure to > > > > > > detect a non-functional resource is acceptable. However, if the > > > > > > resource later becomes functional, it should then be added to the > > > > > > RPTs of domains that should contain the resource. If this occurs, a > > > > > > Resource Added event is generated indicating the ResourceId of the > > > > > > resource added to the RPT" (page 26, paragraph 6). > > > > > > > > > > > > So FRUs can be dynamically added/removed, but resources can also be > > > > > > added dynamically if they were not detected when the HPI > > > > > > implementation started. The problem is that "at the time an HPI > > > > > > implementation is started" is not clearly defined. Does that mean > > > > > > when saHpiSessionOpen() returns? or In the vicinity of the first > > > > > > minute/seconds the implementation is initialized? So its hard to > > > > > > know when exactly it is acceptable for RPT entries of existing > > > > > > functional resources to be in the RPT. > > > > > > The discovery process on page 24 says how discovery will *typically* > > > > > > proceed (going straight from opening a session to reading the RPT) > > > > > > but it doesn't rule out other variations, and it also advices the > > > > > > user to make sure that no resources where added or removed in the > > > > > > process of discovery by using the RPT update counter and events. > > > > > > > > > > > > So, if the RPT is supposed to have resources right after > > > > > > saHpiSessionOpen(), we'll need help in finding that specific text in > > > > > > the specification so that we can go implement it in OpenHPI. If not, > > > > > > then there is a latency problem in the conformance tests in which > > > > > > the tests hit the RPT and exit before it has had time to build > > > > > > itself up, and no event or RPT counter inspection is done > bythe test. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Renier Morales |
From: Renier M. <re...@us...> - 2005-10-18 17:58:57
|
saf...@li... wrote on 09/28/2005 05:34:58 PM: > Renier Morales <re...@us...> wrote on 09/28/2005 01:12:04 PM: > > > > Ste...@ra... wrote on 28/09/2005 01:51:43 PM: > > > > > If I understand, only the initial SessionOpen is missing resources. > > > Subsequent SessionOpens will be populated by the first, it just > take time. > > > > Right. > > > > > > > > It still seems to me that this initial OpenHPI SessionOpen to a > > > domain needs to complete an internal Discover before returning. > > > > The spec is not clear on whether SessionOpen needs to do this within > > itself. That would be like calling saHpiDiscover() within > > saHpiSessionOpen(). Doin this is not necessary as saHpiDiscover() > > already exists publicly for the user if he needs a current view now > > and wants to block for it. > > I think the user should decide this, otherwise, he can check for > > events and work with them as they come. This would be much faster > > for the user if he is interested in a resource that will become > > available in HPI half-way through a complete discovery process. > > > > > > > > If the first and second session do not overlap (session A closes > > > before session B starts), does the discovery need to be repeated? > > > > No, doesn't have to be repeated within the same HPI user app's process. > > Are you saying that different HPI user app processes could have > different resource lists and user data (Domain tags, resource tags, > alarms, etc.)? It will be the same data if they are looking at the same things. When using OpenHPI in standard mode (non-daemon), users of OpenHPI will be whatever the application makes them, whether threads with their own session id to make calls, or just the main process using different session ids. In the spec a user is, at best, defined thorough a session. A distinction is not clearly made to say that a user of a session is in or has to be in a separate process space. However, if this where the case, which is not clearly spelled out in the spec, applications can run OpenHPI in daemon mode. In this mode, the daemon will contain all the domains and their related information. Applications connecting to this daemon are in a separate process space from the daemon using one or more session ids each. In this case, the results of discovery all shared by multiple processes. > Section 3.6.1 states, "It is the responsibility of an HPI > implementation to ensure that a single, consistent view of the > system and its domains and resources is presented to all HPI Users." > Multiple applications accessing the same domain must see the same thing. > > As an HPI user I expect to multiple applications to see the same HPI > world. I expect commands applied to a domain to be persistent until > the domain restarts. Can a domain be defined as contained in an HPI > user app's process? When that process quits all "local" data goes in > the bit bucket? If each HPI user app process is considered to be a > different domain they would not have to have the same view. But this > would seem to contradict 3.6.2 which states, "If multiple HPI > implementations exist in a system, then they should only be used to > manage non-overlapping entities." > > > > > > Will data (e.g. Resource Tags) set in the first session "survive" to > > > the second? If this is the case, then only the first hpitest should > > > have a problem. Won't subsequent tests benefit from the first > open session? > > > > You are assuming that the HPI implementation works as a daemon. It > > is not true in OpenHPI's case. Whether it works as a daemon or not > > shouldn't be an issue for the saf conformance tests. > > If the tests are engineered to assume this about an implementation, > > then I think that is a mistake. It is not something that is > > specified in the spec. > > I don't think I am making an assumption that the implementation > works (or should work) as a daemon. I don't care how it is > implemented if it conforms to the specification. Getting a common > understanding of the specification, that IS a challenge. > > --stevem > ------------------------------------------------------- This SF.Net > email is sponsored by: Power Architecture Resource Center: Free > content, downloads, discussions, and more. http://solutions. > newsforge.com/ibmarch.tmpl > _______________________________________________ Saftest-devel > mailing list Saf...@li... https://lists. > sourceforge.net/lists/listinfo/saftest-devel |
From: Xiong, C. <cry...@in...> - 2005-10-09 04:31:50
|
U29ycnksIHNvbWV0aGluZyB3cm9uZyB3aXRoIG15IG1haWxib3gsIGFuIG9sZCBlbWFpbCBpcyBz ZW50IG91dC4gDQoNClBsZWFzZSBub3RpY2UgdGhpcyBpcyBhIGJ1ZyBmaXggcmVsZWFzZSBhZnRl ciBIUEktQi4wMS4wMV8xLjAuMi4NCiBJbiB0aGlzIHJlbGVhc2U6DQogLSBDb250aW51b3VzbHkg QnVnIGZpeGVzIGZvciBIUEkgdGVzdCBXRyByZXZpZXdlZCBzZXNzaW9ucy4NCiAgIFRoYW5rcyBV TkggdGVhbSBhbmQgTGkgUXVuLg0KIC0gQnVnIGZpeGVzIGZvciB3YXRjaGRvZ3RpbWVyIGFuZCBj b250cm9sIHRlc3RzLiANCiAgIFRoYW5rcyBMaSBRdW4gYW5kIFdhbmcgSmluZy4NCg0KUGxlYXNl IGRvd25sb2FkIHRoZSByZWxlYXNlIGZyb20gDQpodHRwOi8vcHJkb3dubG9hZHMuc291cmNlZm9y Z2UubmV0L3NhZnRlc3Qvc2FmdGVzdF9IUEktQl8wMV8wMV8xXzBfMy50YXIuZ3o/ZG93bmxvYWQg ICAgDQogICAgIA0KDQpUaGFua3MsDQpDcnlzdGFsIA0KwqANCsKgDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBYaW9uZywgQ3J5c3RhbCANClNlbnQ6IDIw MDXlubQxMOaciDnml6UgMTI6MjINClRvOiBzYWZ0ZXN0LWRldmVsQGxpc3RzLnNvdXJjZWZvcmdl Lm5ldDsgc2FmdGVzdC1ocGktZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpTdWJqZWN0OiBb QU5OT1VOQ0VdIHNhZnRlc3RfSFBJLUJfMDFfMDFfMS4wLjMgaXMgcmVsZWFzZWQhDQoNCnNhZnRl c3RfSFBJLUJfMDFfMDFfMS4wLjMgaXMgcmVsZWFzZWQsIHBsZWFzZSBkb3dubG9hZCBpdCBmcm9t Og0KaHR0cDovL3ByZG93bmxvYWRzLnNvdXJjZWZvcmdlLm5ldC9zYWZ0ZXN0L3NhZnRlc3RfSFBJ LUJfMDFfMDFfMV8wXzIudGFyDQouZ3o/ZG93bmxvYWQgIA0KDQpUaGlzIGlzIHVyZ2VudCBidWcg Zml4IHJlbGVhc2UgZm9yIEhQSS1CLjAxLjAxXzEuMC4xLg0KLS0gU29tZSBmdW5jdGlvbnMgaGF2 ZSBiZWVuIHJlcGxhY2VkIGluY29ycmVjdGx5IGluIDEuMC4xIHJlbGVhc2UuIFRoaXMNCnJlbGVh c2UgZml4ZWQgdGhpcyBwcm9ibGVtLg0KDQpUb0RvczoNCiAgLSBDb250aW51ZSB0byBkbyBidWcg Zml4ZXMNCg0KKioqKioqKioqIEJhc2ljIEluZm9ybWF0aW9uICoqKioqKioqKioqKioqKioqKioq Kg0KVGhlIFJFQURNRSBpbiB0aGUgcmVsZWFzZSBwYWNrYWdlIGRlc2NyaWJlcyBob3cgdG8gdXNl IHRoZSBmcmFtZXdvcmssDQpob3cgdG8gY29udHJpYnV0ZSBtb3JlIHRlc3RzIHRvIHRoZSBmcmFt ZXdvcmsgaW4gYSBicmllZi4gRm9yIG1vcmUNCmRldGFpbHMsIHBsZWFzZSByZWZlciB0byBGcmFt ZXdvcmtfU3BlY2lmaWNhdGlvbi5odG0gZG9jdW1lbnQgdW5kZXIgZG9jDQpkaXJlY3RvcnkgaW4g dGhlIHJlbGVhc2UgcGFja2FnZS4NCg0KVGhlIGdvYWwgb2YgdGhpcyBwcm9qZWN0IGlzIHRvIGNy ZWF0ZSBjb25mb3JtYW5jZSB0ZXN0IHN1aXRlIGZvciBTQUYNCnNwZWMsIGluY2x1ZGluZyBBSVMg QS4wMS4wMSwgQUlTIEIuMDEuMDEsIEhQSSBBLjAxLjAxIGFuZCBIUEkgQi4wMS4wMQ0Kc3BlYy4g DQoNCkFueSBtb3JlIGNvbW1lbnRzLCBwbGVhc2UgZGlzY3VzcyBpbiB0aGUgZm9sbG93aW5nIG1h aWxpbmcgbGlzdDoNCnNhZnRlc3QtZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0IChGb3IgdGhl IHdob2xlIHByb2plY3QpDQpzYWZ0ZXN0LWhwaS1kZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQg KEZvciBIUEkgcGFydCkNCnNhZnRlc3QtYWlzLWRldmVsQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCAo Rm9yIEFJUyBwYXJ0KQ0KDQpUaGUgd2VicGFnZSBvZiB0aGlzIHByb2plY3QgY2FuIGJlIGZvdW5k IGhlcmU6DQpodHRwOi8vc2FmdGVzdC5zb3VyY2Vmb3JnZS5uZXQvDQoNClRoYW5rcywNCkNyeXN0 YWwNCg0KDQoNCg== |