From Wed Jun 29 09:29:40 2005 Date: Wed, 29 Jun 2005 09:29:40 -0700 (PDT) From: Postmaster Subject: Message from mail server Content-Length: 94 Mime-Version: 1.0 Status: RO X-IMAP: 1120062580 23 Delete. This is a system message. --END+PSEUDO-- From sacadmin Mon Jun 13 22:38:24 2005 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5E5cOs0022168 for ; Mon, 13 Jun 2005 22:38:24 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.175.66]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j5E5btPu022327 for ; Mon, 13 Jun 2005 22:37:55 -0700 (PDT) Received: from billybob.sfbay.sun.com (billybob [129.146.224.123]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5E5cNs0022165 for ; Mon, 13 Jun 2005 22:38:23 -0700 (PDT) Received: from billybob (billybob [129.146.224.123]) by billybob.sfbay.sun.com (8.13.4+Sun/8.13.4) with SMTP id j5E5c7BF147705; Mon, 13 Jun 2005 22:38:07 -0700 (PDT) Message-Id: <200506140538.j5E5c7BF147705@billybob.sfbay.sun.com> Date: Mon, 13 Jun 2005 22:38:07 -0700 (PDT) From: Shudong Zhou Reply-To: Shudong Zhou Subject: PSARC 2005/372 Ontario Platform Channel Protocol To: psarc@sac.eng.sun.com Cc: Venugopala.Mula@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MEogDx7cWE5Ltn8AI6Bk1Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_13 SunOS 5.11 i86pc i386 Content-Length: 12832 Status: RO X-Status: $$$$ X-UID: 0000000001 I'm sponsoring the following fasttrack for Venugopala Mula. The requested release binding is patch. A contract for SunMC to use libpcp will be provided soon. The timer is set to expire on 6/20/2005. Shudong /* * Copyright 2005 Sun Microsystems, Inc. All rights reserved. * Use is subject to license terms. */ #pragma ident "@(#)ontario_pcp_spec.txt 1.4 05/06/10 SMI" /***************************************************** * * Platform Channel Protocol (PCP) Specification * ******************************************************/ 1. Introduction. This document explains in detail about the platform channel protocol (PCP) used by Host and ALOM tasks to communicate over platform channels on Ontario/Erie platforms. Note: The PCP protocol is based on FMA ETM protocol format which is used for communication between FMA and ALOM over FMA channel. Refer following documents for information about FMA channel protocol. * Ontario FMA Phase 1 ETM-to-ETM Protocol Interface Spec. * Ontario FMA Phase 1 ETM-to-Transport API Interface Spec. 2. Platform Channel Protocol Format To initiate messages on platform channels, the sender first sends the platform channel message header to the receiver. The message header is sent in network byte order. The message header always starts with a magic number, which will be same for all types messages on platform channels, to avoid message framing errors. /* * magic number for Platform Channel Protocol (PCP) * ~(rot13("PCP_") = 0xAFBCAFA0 * rot13 is a simple Caesar-cypher encryption that replaces each English * letter with the one 13 places forward or back along the alphabet. */ #define PLAT_CHNL_PROT_MAGIC_NUM (0xAFBCAFA0) The magic number is followed by protocol version. The protocol version field can be used for compatabiity of future protocol format changes. #define PLAT_CHNL_PROT_VER_1 1 Based on the message type ('msg_type') the message data is interpreted differently. The 'msg_type' and 'sub_type' fields are provided by user applications. /* * Platform Channel Request Message Header. */ typedef struct pcp_req_msg_hdr { uint32_t magic_num; /* magic number */ uint8_t proto_ver; /* version info for */ /* backward compatibility */ uint8_t msg_type; /* provided by user apps */ uint8_t sub_type; /* provided by user apps */ uint8_t rsvd_pad; /* padding bits */ uint32_t xid; /* transaction id */ uint32_t timeout; /* timeout in seconds */ uint32_t msg_len; /* length of request or response data */ uint16_t msg_cksum; /* 16-bit checksum of req msg data */ uint16_t hdr_cksum; /* 16-bit checksum of req hdr */ } pcp_req_msg_hdr_t; /* * Platform Channel Response Message Header. */ typedef struct pcp_resp_msg_hdr { uint32_t magic_num; /* magic number */ uint8_t proto_ver; /* version info for */ /* backward compatibility */ uint8_t msg_type; /* passed to user apps */ uint8_t sub_type; /* passed to user apps */ uint8_t rsvd_pad; /* for padding */ uint32_t xid; /* transaction id */ uint32_t timeout; /* timeout in seconds */ uint32_t msg_len; /* length of request or response data */ uint32_t status; /* response status */ uint16_t msg_cksum; /* 16-bit checksum of resp msg data */ uint16_t hdr_cksum; /* 16-bit checksum of resp hdr */ } pcp_resp_msg_hdr_t; The transaction id (xid) field is used to match the request and response messages. The timeout value indicates to the receiver the time in seconds the sender expects the response. Similar to FMA ETM protocol, (-1) indicates no response is wanted; (0) indicates a willingness to wait forever. #define PCP_TO_NO_RESPONSE (-1) #define PCP_TO_WAIT_FOREVER (0) The message length (msg_len) field tells the length of message data. The header and message checksum values (msg_cksum & hdr_cksum) are used for data integrity of message header and data. The receiver after receiving the message header waits until it gets 'msg_len' bytes before interpreting the message data. The status field in the message header is used in the response message to communicate following generic errors to the message sender. #define PCP_OK (0) /* message received okay */ #define PCP_ERROR (1) /* generic error */ #define PCP_HDR_CKSUM_ERROR (2) /* header checksum error */ #define PCP_MSG_CKSUM_ERROR (3) /* message checksum error */ #define PCP_XPORT_ERROR (4) /* message in complete error */ After sending the message header, the sender sends the message data. The sender waits for the response message, if it is expecting for a response. The message data, supplied by the user applications is assumed tobe already in some known byte order (network byte or XDR or ???). 3. Platform Channel Protocol Library interfaces. 3.1. Interface Table --------------------------------------------------------------- Name Stability comments --------------------------------------------------------------- struct pcp_msg_t contracted project private - function pcp_init() contracted project private - function pcp_send_recv contracted project private - function pcp_close contracted project private - --------------------------------------------------------------- 3.2. Interfaces Description. The host (solaris) applications provide message in the following format to Platform Channel Host Library for sending to the receiver (i.e Service processor ). struct pcp_msg { uint8_t msg_type; uint8_t sub_type; uint32_t msg_len; void *msg_data; } pcp_msg_t; The host library copies the 'msg_type', 'sub_type' and 'msg_len' fields into the platform channel message header. The format of 'msg_data' is to be defined for every application seperately. Every application will have a different format for 'msg_data' in request message and for 'msg_data' in response message. Platform Channel Host Interface Library provides following interfaces to host applications for communication on platform channels: a). The host applications first call "pcp_init()" with complete channel device path name as an argument to initialize the specific platform channel. The actual device path names for each platform channel to be defined. (TBD). The platform channel device pathnames will be defined in the host library header file. /* * Function: Initialize Platform Channel connection. * * Arguments: * * char *channel_dev_path - Complete device path of platform channel. * * Return: * * 0 - Platform channel initialization success. * (-ve) - Platform channel initialization failure. * * Different return values: * * PCPL_INVALID_ARGS - invalid args. * PCPL_GLVC_ERROR - glvc driver error. * PCPL_ERROR - for other libpcp internal errors. * */ int pcp_init(char *channel_dev_path); b). The host applications shall call "pcp_close()" after the communication on platform channel is done. This is just a cleanup routine. /* * Function: Close Platform Channel connection. * * Arguments: None * * Return: * * 0 - Success * -1 - Failure */ int pcp_close(void); c). The host applications shall call "pcp_send_recv()" for sending and receiving messages on platform channels. The host applications shall supply the pointer to the 'resp_msg'. The host library will create memory for the 'msg_data' buffer in response msg and the host applications are expected to free this msg_data buffer in response msg. The timeout value signifies the time in seconds the host application expects a response message. If the host applications are not interested in response message the timeout value can be set to PCP_TO_NO_RESPONE. /* * Function: Send Request message and Receive response message on platform * channel. * * Arguments: * * pcp_msg_t *req_msg - Pointer to Request message * pcp_msg_t *resp_msg - Pointer to Response message. * uint32_t timeout - timeout value in seconds. * * Return: * ( 0 ) - Success * ( -ve ) - Host library returns any of the generic errors defined above * for pcp_send_recv failures. * * Different return values: * * * PCPL_INVALID_ARGS - invalid args. * PCPL_GLVC_TIMEOUT - glvc call timeout. * PCPL_XPORT_ERROR - transport error in request message * noticed by receiver. * PCPL_MALLOC_FAIL - malloc failure. * PCPL_CKSUM_ERROR - checksum error. */ int pcp_send_recv(pcp_msg_t *req_msg, pcp_msg_t *resp_msg, uint32_t timeout); Note: see "usr/src/lib/libpcp/common/libpcp.h" more libpcp api return codes. 4. 'libpcp' interface usage by user application. libpcp api is available to user applications as a shared library (libpcp.so). The libpcp.so library will reside under "/usr/platform/`uname -i`/lib/" directory on Ontario and Erie platforms. libpcp user applications should follow following sequence of steps to exchange messages with SC on Ontario and Erie platforms. a). Call pcp_init() with appropriate application specific channel device path. Note: Refer platform specific PD (partition descriptor) about different channels. glvc driver creates channels device nodes under /devices/virtual-devices@100/ directory on Ontario platform. b). If pcp_init() fails (i.e return value < 0 ), the libpcp user application can not proceed further in using libpcp api to communicate with SC. At this point, the user application may want log an error and exit in using libpcp api. c). Call pcp_send_recv() with appropriate arguments for sending/receiving messages. d). If pcp_send_recv() fails either repeat step 'c' or goto step 'g'. e). If pcp_send_recv is successful, free the response message data memory. libpcp allocates memory for the response message data. Applications should free the memory using free() call. (i.e "free(resp_msg->msg_data") ) f). To exchange more messages with SC, goto step 'c', or if message exchange with SC is done goto step 'g'. g). Call pcp_close(). h). Message exchange with SC is completed. 5. Platform Channl Communication Block Diagram on Ontario platform. See Figure 1 for current libpcp interface users and complete communication path from libpcp user apps to Service processor. ________ | SunVTS | | ALOM |____ _______ | Task | | | |___ |________| | |SunVTS | | . _________ | |_______| | . | SunMC | | | . | ALOM | | | ________ . | Task |__ | ________ |____| | . |________| | | | | | | . _________ | | | SunMC |______| | . | |__| | |________| | | _______ . _________ ______ | Data |____| |libpcp | | | . | | | | | Socket |____ __________ | |__| Glvc |_.__| Hyper- |__| VBSC |___| Monitor|__ | | |____| | |_______| . | -Visor | |______| |________| | | | Explorer | | | . |_________| | | |__________| __| | . __________ | | | |_______| . | Explorer | | | __________ | . | ALOM |__| | | | | . | Task | | | Picl |__| . |__________| | | Plugin | . | |__________| . _________ | . | Picl | | . | Plugin |_____| . | Task | . |_________| . <-- Libpcp ---><---- Solaris ------->. <-System FW -><------ SC firmware -----> Users. Figure 1 : libpcp user apps <-> Service Processor communication mechanism over platform channels. From sacadmin Tue Jun 14 05:20:35 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5ECKYs0015333 for ; Tue, 14 Jun 2005 05:20:34 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j5ECK4cG017824; Tue, 14 Jun 2005 08:20:04 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j5ECK38P017821; Tue, 14 Jun 2005 08:20:03 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17070.52083.894751.827662@gargle.gargle.HOWL> Date: Tue, 14 Jun 2005 08:20:03 -0400 From: James Carlson To: Shudong Zhou Cc: psarc@sac.eng.sun.com, Venugopala.Mula@Sun.COM Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol In-Reply-To: Shudong Zhou's message of 13 June 2005 22:38:07 References: <200506140538.j5E5c7BF147705@billybob.sfbay.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Content-Length: 2955 Status: RO X-Status: $$$$ X-UID: 0000000002 Shudong Zhou writes: > I'm sponsoring the following fasttrack for Venugopala Mula. > The requested release binding is patch. A contract for SunMC > to use libpcp will be provided soon. What about SunVTS and Explorer? Those aren't part of the same consolidation (let alone project), and will thus need contracts. > Note: The PCP protocol is based on FMA ETM protocol format which is used for > communication between FMA and ALOM over FMA channel. Refer following documents > for information about FMA channel protocol. > > * Ontario FMA Phase 1 ETM-to-ETM Protocol Interface Spec. > * Ontario FMA Phase 1 ETM-to-Transport API Interface Spec. Are these interfaces under review in this case, or have they been reviewed in some other ARC case? Are they even available? (I don't see copies in the case directory. Pointers would be helpful.) > * magic number for Platform Channel Protocol (PCP) > * ~(rot13("PCP_") = 0xAFBCAFA0 > * rot13 is a simple Caesar-cypher encryption that replaces each English > * letter with the one 13 places forward or back along the alphabet. Whew. > The host (solaris) applications provide message in the following format to > Platform Channel Host Library for sending to the receiver (i.e Service > processor ). Big question here: just how many system controller interfaces does Solaris need? It seems that every single Sun product reinvents this particular wheel. Thus, we have these for Enchilada/RMC: "PICL Plugin environmental ioctls" (PSARC 2002/198) "Remote Management Control (RMC)" (PSARC 2002/199) "Environmental sysevents" (PSARC 2002/206) "PICL plugin environmental ioctls [updated]" (PSARC 2002/437) Stiletto: "PICL Class for Service Processors" (PSARC 2002/361) Cherrystone/LW*/LOM: "LOMlite support software and documentation" (PSARC 2000/019) "LOM bus nexus driver" (PSARC 2001/412) RSC: "RSC: Remote System Control" (PSARC 1998/074) "Device Links for RSC" (PSARC 2000/157) Starfire: "Starfire Network Console" (PSARC 1997/329) "Extend Starfire Network Console for Starcat" (PSARC 1999/302) Serengeti/Starcat/others: "Sysevent platform event specifications" (PSARC 2000/189) "Common" (but probably Netra): "PICL Environmental Properties and Classes" (PSARC 2000/248) "PICL environmental classes" (PSARC 2001/418) "PICL classes addendum" (PSARC 2000/214) Makaha: "Makaha System Management Controller(SMC) Driver" (PSARC 2002/045) And even this: "System Alarms and Service Monitoring" (PSARC 2000/121). And those are just the ones I was able to find in a short search over PSARC archives alone; I have no doubt that that there are dozens of others. Why is that? Is there some bigger piece that's missing? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Tue Jun 14 13:49:48 2005 Received: from phys-bur-1 (phys-bur-1.East.Sun.COM [129.148.9.72]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5EKnms0005884 for ; Tue, 14 Jun 2005 13:49:48 -0700 (PDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0II300K01DSBAN@bur-mail1.east.sun.com> (original mail from Venugopala.Mula@Sun.COM) for psarc@sac.eng.sun.com; Tue, 14 Jun 2005 16:49:17 -0400 (EDT) Received: from Sun.COM (pandit.East.Sun.COM [129.148.184.67]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0II300J36DU4WY@bur-mail1.east.sun.com>; Tue, 14 Jun 2005 16:49:17 -0400 (EDT) Date: Tue, 14 Jun 2005 16:48:19 -0400 From: Venu Mula Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol In-reply-to: <17070.52083.894751.827662@gargle.gargle.HOWL> To: James Carlson Cc: Shudong Zhou , psarc@sac.eng.sun.com Reply-to: Venugopala.Mula@Sun.COM Message-id: <42AF4293.3070009@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <200506140538.j5E5c7BF147705@billybob.sfbay.sun.com> <17070.52083.894751.827662@gargle.gargle.HOWL> Content-Length: 4590 Status: RO X-Status: $$$$ X-UID: 0000000003 James Carlson wrote: > What about SunVTS and Explorer? Those aren't part of the same > consolidation (let alone project), and will thus need contracts. Yes, the private contract includes SunVTS, SunMC, Exploreer, & Picl plugin. > Are these interfaces under review in this case, or have they been > reviewed in some other ARC case? Are they even available? (I don't > see copies in the case directory. Pointers would be helpful.) libpcp doesn't really depend on ETM protocol. We just took some ideas from FMA ETM. Please see following docs (draft) for ETM. ETM is whole different stack. Both ETM and libpcp talks to the glvc driver to communicate with SC. http://sunwebcollab.central.sun.com/gm/folder-1.11.785294 > Big question here: just how many system controller interfaces does > Solaris need? The main reason for developing libpcp iterface is that on Ontario platform (sun4v), glvc/hypervisor provides a basic interface for sending/receving bytes to/from virtual channels and it's upto the endpoints of each virtual channel to figure out how to exchange/interpret these bytes properly. And each application can send only 1 MTU size (max 508 bytes) in a single transaction. On ontario we have four different platform specific applications that needs to talk to SC using these virtual channels. So instead of every application to take care of these channel communication format/details, we decided to write a library so that these platform applications can share the interfaces and it would be easy to manage in future if the underlying sc communication protocol changes. Venu So instead of every application > Shudong Zhou writes: > >>I'm sponsoring the following fasttrack for Venugopala Mula. >>The requested release binding is patch. A contract for SunMC >>to use libpcp will be provided soon. > > > What about SunVTS and Explorer? Those aren't part of the same > consolidation (let alone project), and will thus need contracts. > > >>Note: The PCP protocol is based on FMA ETM protocol format which is used for >>communication between FMA and ALOM over FMA channel. Refer following documents >>for information about FMA channel protocol. >> >> * Ontario FMA Phase 1 ETM-to-ETM Protocol Interface Spec. >> * Ontario FMA Phase 1 ETM-to-Transport API Interface Spec. > > > Are these interfaces under review in this case, or have they been > reviewed in some other ARC case? Are they even available? (I don't > see copies in the case directory. Pointers would be helpful.) > > >> * magic number for Platform Channel Protocol (PCP) >> * ~(rot13("PCP_") = 0xAFBCAFA0 >> * rot13 is a simple Caesar-cypher encryption that replaces each English >> * letter with the one 13 places forward or back along the alphabet. > > > Whew. > > >>The host (solaris) applications provide message in the following format to >>Platform Channel Host Library for sending to the receiver (i.e Service >>processor ). > > > Big question here: just how many system controller interfaces does > Solaris need? > > It seems that every single Sun product reinvents this particular > wheel. Thus, we have these for Enchilada/RMC: > > "PICL Plugin environmental ioctls" (PSARC 2002/198) > "Remote Management Control (RMC)" (PSARC 2002/199) > "Environmental sysevents" (PSARC 2002/206) > "PICL plugin environmental ioctls [updated]" (PSARC 2002/437) > > Stiletto: > "PICL Class for Service Processors" (PSARC 2002/361) > > Cherrystone/LW*/LOM: > "LOMlite support software and documentation" (PSARC 2000/019) > "LOM bus nexus driver" (PSARC 2001/412) > > RSC: > "RSC: Remote System Control" (PSARC 1998/074) > "Device Links for RSC" (PSARC 2000/157) > > Starfire: > "Starfire Network Console" (PSARC 1997/329) > "Extend Starfire Network Console for Starcat" (PSARC 1999/302) > > Serengeti/Starcat/others: > "Sysevent platform event specifications" (PSARC 2000/189) > > "Common" (but probably Netra): > "PICL Environmental Properties and Classes" (PSARC 2000/248) > "PICL environmental classes" (PSARC 2001/418) > "PICL classes addendum" (PSARC 2000/214) > > Makaha: > "Makaha System Management Controller(SMC) Driver" (PSARC 2002/045) > > And even this: "System Alarms and Service Monitoring" (PSARC > 2000/121). And those are just the ones I was able to find in a short > search over PSARC archives alone; I have no doubt that that there are > dozens of others. > > Why is that? Is there some bigger piece that's missing? > -- Name : Venugopala Mula E-mail: venugopala.mula@sun.com Phone : 781-442-1050, x2150 From sacadmin Tue Jun 14 16:07:29 2005 Received: from marduk.eng.sun.com (marduk [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5EN7Ts0024151 for ; Tue, 14 Jun 2005 16:07:29 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id j5EN5gY0008519; Tue, 14 Jun 2005 16:05:42 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id j5EN5fiF008518; Tue, 14 Jun 2005 16:05:41 -0700 (PDT) Date: Tue, 14 Jun 2005 16:05:41 -0700 (PDT) From: Gary Winiger Message-Id: <200506142305.j5EN5fiF008518@marduk.eng.sun.com> To: psarc@sac.eng.sun.com, szhou@billybob.sfbay.sun.com Cc: Venugopala.Mula@Sun.COM Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol Content-Length: 570 Status: RO X-Status: $$$$ X-UID: 0000000004 > The message header always starts with a magic number, which will be same for > all types messages on platform channels, to avoid message framing errors. > > /* > * magic number for Platform Channel Protocol (PCP) > * ~(rot13("PCP_") = 0xAFBCAFA0 > * rot13 is a simple Caesar-cypher encryption that replaces each English > * letter with the one 13 places forward or back along the alphabet. > */ > #define PLAT_CHNL_PROT_MAGIC_NUM (0xAFBCAFA0) Why the obfuscation? What does it buy other than making someone wonder? Gary.. From sacadmin Tue Jun 14 17:18:50 2005 Received: from phys-bur-1 (phys-bur-1.East.Sun.COM [129.148.9.72]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5F0Ios0001121 for ; Tue, 14 Jun 2005 17:18:50 -0700 (PDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0II300H01N8F7Y@bur-mail1.east.sun.com> (original mail from venugopala.mula@sun.com) for psarc@sac.eng.sun.com; Tue, 14 Jun 2005 20:18:20 -0400 (EDT) Received: from sun.com (vpn-129-150-64-161.East.Sun.COM [129.150.64.161]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0II30040LNIFVI@bur-mail1.east.sun.com>; Tue, 14 Jun 2005 20:18:20 -0400 (EDT) Date: Tue, 14 Jun 2005 20:28:38 -0400 From: venugopala mula Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol In-reply-to: <200506142305.j5EN5fiF008518@marduk.eng.sun.com> To: Gary Winiger Cc: psarc@sac.eng.sun.com, szhou@billybob.sfbay.sun.com, tom.caron@sun.com Message-id: <42AF7636.7070901@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 References: <200506142305.j5EN5fiF008518@marduk.eng.sun.com> Content-Length: 1223 Status: RO X-Status: $$$$ X-UID: 0000000005 We just wanted to pick some random unique sequence so signify start of message header on platform specific virtual channels. The channel end points basically waits for arrival of proper message header and based on message header it knows how many bytes to read for message data. All the data that is not started with magic sequence is thrown away. On Ontario all virtual channels communiation from Host goes through same MUX and reaches to FPGA mailbox on SC. We wanted to make sure that what ever data that is exchaged on platform virtual channels does not get mixed with other virtual channel's data. Venu Gary Winiger wrote: >>The message header always starts with a magic number, which will be same for >>all types messages on platform channels, to avoid message framing errors. >> >> /* >> * magic number for Platform Channel Protocol (PCP) >> * ~(rot13("PCP_") = 0xAFBCAFA0 >> * rot13 is a simple Caesar-cypher encryption that replaces each English >> * letter with the one 13 places forward or back along the alphabet. >> */ >> #define PLAT_CHNL_PROT_MAGIC_NUM (0xAFBCAFA0) > > > Why the obfuscation? What does it buy other than making someone > wonder? > > Gary.. From sacadmin Wed Jun 15 06:06:51 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5FD6ps0008030 for ; Wed, 15 Jun 2005 06:06:51 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j5FD6Kwh022101; Wed, 15 Jun 2005 09:06:20 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j5FD6KrO022098; Wed, 15 Jun 2005 09:06:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17072.10188.287304.655758@gargle.gargle.HOWL> Date: Wed, 15 Jun 2005 09:06:20 -0400 From: James Carlson To: Venugopala.Mula@Sun.COM Cc: Shudong Zhou , psarc@sac.eng.sun.com Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol In-Reply-To: Venu Mula's message of 14 June 2005 16:48:19 References: <200506140538.j5E5c7BF147705@billybob.sfbay.sun.com> <17070.52083.894751.827662@gargle.gargle.HOWL> <42AF4293.3070009@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Content-Length: 4028 Status: RO X-Status: $$$$ X-UID: 0000000006 Venu Mula writes: > > James Carlson wrote: > > What about SunVTS and Explorer? Those aren't part of the same > > consolidation (let alone project), and will thus need contracts. > > Yes, the private contract includes SunVTS, SunMC, Exploreer, & Picl plugin. OK; thanks. > > Are these interfaces under review in this case, or have they been > > reviewed in some other ARC case? Are they even available? (I don't > > see copies in the case directory. Pointers would be helpful.) > > libpcp doesn't really depend on ETM protocol. We just took some ideas > from FMA ETM. Please see following docs (draft) for ETM. ETM is whole > different stack. Both ETM and libpcp talks to the glvc driver to > communicate with SC. > http://sunwebcollab.central.sun.com/gm/folder-1.11.785294 What ARC case contains a review of this protocol? This sounds to me like a major architectural component of the project, and I can't find any record of an architectural review. At a minimum, these documents seem like normative references for this case, and ought to have been included with the materials. (Since they're hidden behind a site with excessive security measures, I'm hesitent to copy them to the case directory where they belong, but perhaps someone involved with the case will.) How is it managed in terms of independent release schedules for the embedded controller and the rest of the Solaris software? > > Big question here: just how many system controller interfaces does > > Solaris need? > > The main reason for developing libpcp iterface is that on Ontario > platform (sun4v), glvc/hypervisor provides a basic interface for > sending/receving bytes to/from virtual channels and it's upto the > endpoints of each virtual channel to figure out how to > exchange/interpret these bytes properly. And each application can send > only 1 MTU size (max 508 bytes) in a single transaction. I wasn't questioning why you needed your own low-level interface. (Though, certainly, that's another issue that could be explored. Common I/O mechanisms would likely simplify development and maintenance greatly.) I was asking why this low-level library interface is the right way for multiple applications to access the underlying functionality. The implication is that SunVTS, Explorer, and others all need to have one plugin module per platform, and (as described in this case) each platform needs to have one "handler" per possible client. This sounds like an NxM problem -- "N" different platforms each with "M" different dependent applications -- and that to me implies bad architecture. I fear that the project is optimizing for its own delivery, but not for the overall system. > On ontario we have four different platform specific applications that > needs to talk to SC using these virtual channels. So instead of every > application to take care of these channel communication format/details, > we decided to write a library so that these platform applications can > share the interfaces and it would be easy to manage in future if the > underlying sc communication protocol changes. I don't see it. This library seems to be just a transport mechanism. It just passes through application messages: The format of 'msg_data' is to be defined for every application seperately. Every application will have a different format for 'msg_data' in request message and for 'msg_data' in response message. The only independence that seems to be gained is at the lowest level, but the applications are *still* tied 1-to-1 with undocumented application layer interfaces, and changes there must somehow be coordinated. I'll ask during ARC business today that this case be derailed for full review. There's just too much missing here -- too little documentation and too little system architecture. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Jun 15 07:39:23 2005 Received: from phys-bur-1 (phys-bur-1.East.Sun.COM [129.148.9.72]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5FEdMs0011415 for ; Wed, 15 Jun 2005 07:39:23 -0700 (PDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0II400H01R7H2H@bur-mail1.east.sun.com> (original mail from Venugopala.Mula@Sun.COM) for psarc@sac.eng.sun.com; Wed, 15 Jun 2005 10:38:53 -0400 (EDT) Received: from Sun.COM (pandit.East.Sun.COM [129.148.184.67]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0II4001LPRCTPK@bur-mail1.east.sun.com>; Wed, 15 Jun 2005 10:38:53 -0400 (EDT) Date: Wed, 15 Jun 2005 10:37:55 -0400 From: Venu Mula Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol In-reply-to: <17072.10188.287304.655758@gargle.gargle.HOWL> To: James Carlson Cc: Shudong Zhou , psarc@sac.eng.sun.com, Tom Caron Reply-to: Venugopala.Mula@Sun.COM Message-id: <42B03D43.5060204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <200506140538.j5E5c7BF147705@billybob.sfbay.sun.com> <17070.52083.894751.827662@gargle.gargle.HOWL> <42AF4293.3070009@Sun.COM> <17072.10188.287304.655758@gargle.gargle.HOWL> Content-Length: 7094 Status: RO X-Status: $$$$ X-UID: 0000000007 James Carlson wrote: > What ARC case contains a review of this protocol? This sounds to me > like a major architectural component of the project, and I can't find > any record of an architectural review. > > At a minimum, these documents seem like normative references for this > case, and ought to have been included with the materials. (Since > they're hidden behind a site with excessive security measures, I'm > hesitent to copy them to the case directory where they belong, but > perhaps someone involved with the case will.) libpcp don't even depend on ETM. I can delete all reference to ETM from libpcp specification, if you would like. > How is it managed in terms of independent release schedules for the > embedded controller and the rest of the Solaris software? All these modules are specific to Ontario platform so they are tracked as part of Ontario platform RR deliverables. > I don't see it. This library seems to be just a transport mechanism. > It just passes through application messages: > > The format of 'msg_data' is to be defined for every application seperately. > Every application will have a different format for 'msg_data' in request > message and for 'msg_data' in response message. The format of 'msg_data' is specific to application and SC. (which is again platform specific). > > The only independence that seems to be gained is at the lowest level, > but the applications are *still* tied 1-to-1 with undocumented > application layer interfaces, and changes there must somehow be > coordinated. As long as libpcp interfaces are not changed, libpcp user applications won't get affected even if underlying communication changes (in glvc or hypervisor etc.). All changes are tracked as part of platform specific support. > I'll ask during ARC business today that this case be derailed for full > review. There's just too much missing here -- too little > documentation and too little system architecture. To give a brief history on this: sun4v virtual channel architecture (FWARC 2005/173 Hypervisor Service API) is designed such that each virtual channel end points to take care of the message format for that specific channel. We argued with sun4v folks to provided a generic message sending mechanism (not just sending sequence of bytes mechanism) (similar to rscadm<->rmc-comm<>SC interface on previous platforms like Chalupa etc..). But they don't want to make the virtual channel communication specific to a application format. So the only option we have (for platform applications) is use to let each application design it's own protocol and talk to glvc directly to communicate with SC. We felt this is redundant doing same thing for each platform application and more difficult to manage. That's why we came with with thie libpcp for all platform applications to use for communications with SC. libpcp protocol is very simple. All it does is just to transport application specific data to SC in a specific format (that is understood by SC) using glvc's generic read/write interfaces. Venu James Carlson wrote: > Venu Mula writes: > >>James Carlson wrote: >> >>>What about SunVTS and Explorer? Those aren't part of the same >>>consolidation (let alone project), and will thus need contracts. >> >>Yes, the private contract includes SunVTS, SunMC, Exploreer, & Picl plugin. > > > OK; thanks. > > >>>Are these interfaces under review in this case, or have they been >>>reviewed in some other ARC case? Are they even available? (I don't >>>see copies in the case directory. Pointers would be helpful.) >> >>libpcp doesn't really depend on ETM protocol. We just took some ideas >>from FMA ETM. Please see following docs (draft) for ETM. ETM is whole >>different stack. Both ETM and libpcp talks to the glvc driver to >>communicate with SC. >> http://sunwebcollab.central.sun.com/gm/folder-1.11.785294 > > > What ARC case contains a review of this protocol? This sounds to me > like a major architectural component of the project, and I can't find > any record of an architectural review. > > At a minimum, these documents seem like normative references for this > case, and ought to have been included with the materials. (Since > they're hidden behind a site with excessive security measures, I'm > hesitent to copy them to the case directory where they belong, but > perhaps someone involved with the case will.) > > How is it managed in terms of independent release schedules for the > embedded controller and the rest of the Solaris software? > > >>>Big question here: just how many system controller interfaces does >>>Solaris need? >> >>The main reason for developing libpcp iterface is that on Ontario >>platform (sun4v), glvc/hypervisor provides a basic interface for >>sending/receving bytes to/from virtual channels and it's upto the >>endpoints of each virtual channel to figure out how to >>exchange/interpret these bytes properly. And each application can send >>only 1 MTU size (max 508 bytes) in a single transaction. > > > I wasn't questioning why you needed your own low-level interface. > (Though, certainly, that's another issue that could be explored. > Common I/O mechanisms would likely simplify development and > maintenance greatly.) > > I was asking why this low-level library interface is the right way for > multiple applications to access the underlying functionality. The > implication is that SunVTS, Explorer, and others all need to have one > plugin module per platform, and (as described in this case) each > platform needs to have one "handler" per possible client. > > This sounds like an NxM problem -- "N" different platforms each with > "M" different dependent applications -- and that to me implies bad > architecture. I fear that the project is optimizing for its own > delivery, but not for the overall system. > > >>On ontario we have four different platform specific applications that >>needs to talk to SC using these virtual channels. So instead of every >>application to take care of these channel communication format/details, >>we decided to write a library so that these platform applications can >>share the interfaces and it would be easy to manage in future if the >>underlying sc communication protocol changes. > > > I don't see it. This library seems to be just a transport mechanism. > It just passes through application messages: > > The format of 'msg_data' is to be defined for every application seperately. > Every application will have a different format for 'msg_data' in request > message and for 'msg_data' in response message. > > The only independence that seems to be gained is at the lowest level, > but the applications are *still* tied 1-to-1 with undocumented > application layer interfaces, and changes there must somehow be > coordinated. > > I'll ask during ARC business today that this case be derailed for full > review. There's just too much missing here -- too little > documentation and too little system architecture. > -- Name : Venugopala Mula E-mail: venugopala.mula@sun.com Phone : 781-442-1050, x2150 From sacadmin Wed Jun 15 07:40:34 2005 Received: from marduk.eng.sun.com (marduk [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5FEeYs0011984 for ; Wed, 15 Jun 2005 07:40:34 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id j5FEcjSC009089; Wed, 15 Jun 2005 07:38:45 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id j5FEcjRW009088; Wed, 15 Jun 2005 07:38:45 -0700 (PDT) Date: Wed, 15 Jun 2005 07:38:45 -0700 (PDT) From: Gary Winiger Message-Id: <200506151438.j5FEcjRW009088@marduk.eng.sun.com> To: gww@marduk.eng.sun.com, venugopala.mula@sun.com Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol Cc: psarc@sac.eng.sun.com, szhou@billybob.sfbay.sun.com, tom.caron@sun.com X-Sun-Charset: US-ASCII Content-Length: 590 Status: RO X-Status: $$$$ X-UID: 0000000008 > We just wanted to pick some random unique sequence so signify start of "PCP_" isn't random, it's meaningful. Why isn't it unique. This is really just a NIT, but seems very odd. > message header on platform specific virtual channels. > message header it knows how many bytes to read for message data. All the > data that is not started with magic sequence is thrown away. Are there other message headers? Is there the possibility of bit corruption? What is the minimum distance between the magic numbers so they can be corrected (with an ECC) or at least not colide? Gary.. From sacadmin Wed Jun 15 07:53:41 2005 Received: from phys-bur-1 (phys-bur-1.East.Sun.COM [129.148.9.72]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5FErfs0012248 for ; Wed, 15 Jun 2005 07:53:41 -0700 (PDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0II400101RYS8S@bur-mail1.east.sun.com> (original mail from Venugopala.Mula@Sun.COM) for psarc@sac.eng.sun.com; Wed, 15 Jun 2005 10:53:12 -0400 (EDT) Received: from Sun.COM (pandit.East.Sun.COM [129.148.184.67]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0II400LRVS0OE3@bur-mail1.east.sun.com>; Wed, 15 Jun 2005 10:53:12 -0400 (EDT) Date: Wed, 15 Jun 2005 10:52:14 -0400 From: Venu Mula Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol In-reply-to: <200506151438.j5FEcjRW009088@marduk.eng.sun.com> To: Gary Winiger Cc: psarc@sac.eng.sun.com, szhou@billybob.sfbay.sun.com, Tom.Caron@Sun.COM Reply-to: Venugopala.Mula@Sun.COM Message-id: <42B0409E.1020108@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <200506151438.j5FEcjRW009088@marduk.eng.sun.com> Content-Length: 1696 Status: RO X-Status: $$$$ X-UID: 0000000009 Gary Winiger wrote: >>We just wanted to pick some random unique sequence so signify start of > > > "PCP_" isn't random, it's meaningful. Why isn't it unique. > This is really just a NIT, but seems very odd. Yes, it's unique. We wanted to pick a seq that doesn't presence in normal data stream. In addition to the magic sequence, we do check protocol version number and message type field in header to make sure that this is the right header on platform virtual channels. > Are there other message headers? Yes, FMA (ETM) uses it's own message header. So far only FMA and platform applications uses these virtual chanenls in Ontario. >Is there the possibility of bit corruption? Even though hypervisor provides a checksum on the data, we are also doing checksum at channel end-points just to avoid data corruption at end-points (particularly on SC side the data is stored on flash proms). >What is the minimum distance between the magic > numbers so they can be corrected (with an ECC) or at least not > colide? I think we expect Solaris/Hypervisor (or underlying hardware ?) to take care of such details !. Venu > > >>message header on platform specific virtual channels. > > >>message header it knows how many bytes to read for message data. All the >>data that is not started with magic sequence is thrown away. > > > Are there other message headers? Is there the possibility of > bit corruption? What is the minimum distance between the magic > numbers so they can be corrected (with an ECC) or at least not > colide? > Are there other message headers? > > Gary.. -- Name : Venugopala Mula E-mail: venugopala.mula@sun.com Phone : 781-442-1050, x2150 From sacadmin Wed Jun 15 08:02:25 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5FF2Os0014293 for ; Wed, 15 Jun 2005 08:02:25 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j5FF1sLe022552; Wed, 15 Jun 2005 11:01:54 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j5FF1sel022549; Wed, 15 Jun 2005 11:01:54 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17072.17122.610414.105842@gargle.gargle.HOWL> Date: Wed, 15 Jun 2005 11:01:54 -0400 From: James Carlson To: Venugopala.Mula@Sun.COM Cc: Shudong Zhou , psarc@sac.eng.sun.com, Tom Caron Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol In-Reply-To: Venu Mula's message of 15 June 2005 10:37:55 References: <200506140538.j5E5c7BF147705@billybob.sfbay.sun.com> <17070.52083.894751.827662@gargle.gargle.HOWL> <42AF4293.3070009@Sun.COM> <17072.10188.287304.655758@gargle.gargle.HOWL> <42B03D43.5060204@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Content-Length: 3543 Status: RO X-Status: $$$$ X-UID: 0000000010 Venu Mula writes: > James Carlson wrote: > > At a minimum, these documents seem like normative references for this > > case, and ought to have been included with the materials. (Since > > they're hidden behind a site with excessive security measures, I'm > > hesitent to copy them to the case directory where they belong, but > > perhaps someone involved with the case will.) > > libpcp don't even depend on ETM. I can delete all reference to ETM from > libpcp specification, if you would like. I realize that libpcp itself is just a transport mechanism. The point above is that I don't see where ETM has been given any architectural review. This case is either related to that other case (which I can't find) or actually establishes those interfaces. > > How is it managed in terms of independent release schedules for the > > embedded controller and the rest of the Solaris software? > > All these modules are specific to Ontario platform so they are tracked > as part of Ontario platform RR deliverables. I'm afraid that doesn't answer the question. SunVTS, Explorer, SunMC, Solaris, and the embedded controller software are all interlinked: changes to one can imply changes to the others. Each is delivered from a separate consolidation. Thus, coordination in any of those changes is required. This case, at least so far, just establishes the linkage for libpcp itself. I don't see what controls those application protocols. > > The format of 'msg_data' is to be defined for every application > seperately. > > Every application will have a different format for 'msg_data' in > request > > message and for 'msg_data' in response message. > > The format of 'msg_data' is specific to application and SC. (which is > again platform specific). Right. Where is it? > sun4v virtual channel architecture (FWARC 2005/173 Hypervisor Service > API) is designed such that each virtual channel end points to take care > of the message format for that specific channel. We argued with sun4v > folks to provided a generic message sending mechanism (not just sending > sequence of bytes mechanism) (similar to rscadm<->rmc-comm<>SC interface > on previous platforms like Chalupa etc..). But they don't want to make > the virtual channel communication specific to a application format. That seems reasonable. I don't think I was questioning that. > So the only option we have (for platform applications) is use to let > each application design it's own protocol and talk to glvc directly to > communicate with SC. We felt this is redundant doing same thing for each > platform application and more difficult to manage. That's why we came > with with thie libpcp for all platform applications to use for > communications with SC. > > libpcp protocol is very simple. All it does is just to transport > application specific data to SC in a specific format (that is understood > by SC) using glvc's generic read/write interfaces. So where are those application-specific interfaces? Are they in a case to be presented later? The only architectural issue I can see with libpcp itself is why it really needs to exist, and where it might be going. Would it be reasonable for non-Ontario platforms to extend it to support future system controller channels? That'd at least nail down one degree of freedom. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Jun 15 09:26:33 2005 Received: from phys-bur-1 (phys-bur-1.East.Sun.COM [129.148.9.72]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5FGQWs0019034 for ; Wed, 15 Jun 2005 09:26:33 -0700 (PDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0II400J01W9MDX@bur-mail1.east.sun.com> (original mail from Venugopala.Mula@Sun.COM) for psarc@sac.eng.sun.com; Wed, 15 Jun 2005 12:26:03 -0400 (EDT) Received: from Sun.COM (pandit.East.Sun.COM [129.148.184.67]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0II400J58WBEME@bur-mail1.east.sun.com>; Wed, 15 Jun 2005 12:26:03 -0400 (EDT) Date: Wed, 15 Jun 2005 12:25:05 -0400 From: Venu Mula Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol In-reply-to: <17072.17122.610414.105842@gargle.gargle.HOWL> To: James Carlson Cc: Shudong Zhou , psarc@sac.eng.sun.com, Tom Caron Reply-to: Venugopala.Mula@Sun.COM Message-id: <42B05661.4070604@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <200506140538.j5E5c7BF147705@billybob.sfbay.sun.com> <17070.52083.894751.827662@gargle.gargle.HOWL> <42AF4293.3070009@Sun.COM> <17072.10188.287304.655758@gargle.gargle.HOWL> <42B03D43.5060204@Sun.COM> <17072.17122.610414.105842@gargle.gargle.HOWL> Content-Length: 4212 Status: RO X-Status: $$$$ X-UID: 0000000011 James Carlson wrote: > I'm afraid that doesn't answer the question. SunVTS, Explorer, SunMC, > Solaris, and the embedded controller software are all interlinked: > changes to one can imply changes to the others. Each is delivered > from a separate consolidation. Thus, coordination in any of those > changes is required. We are establishing a private contract with all these applications for using libpcp interfaces, as part of this PSARC case. >>The format of 'msg_data' is specific to application and SC. (which is >>again platform specific). > > > Right. Where is it? libpcp no need to know the msg_data format. libpcp treats it as just a buffer for sending on platform channels. Venu > Venu Mula writes: > >>James Carlson wrote: >> >>>At a minimum, these documents seem like normative references for this >>>case, and ought to have been included with the materials. (Since >>>they're hidden behind a site with excessive security measures, I'm >>>hesitent to copy them to the case directory where they belong, but >>>perhaps someone involved with the case will.) >> >>libpcp don't even depend on ETM. I can delete all reference to ETM from >>libpcp specification, if you would like. > > > I realize that libpcp itself is just a transport mechanism. > > The point above is that I don't see where ETM has been given any > architectural review. This case is either related to that other case > (which I can't find) or actually establishes those interfaces. > > >>>How is it managed in terms of independent release schedules for the >>>embedded controller and the rest of the Solaris software? >> >>All these modules are specific to Ontario platform so they are tracked >>as part of Ontario platform RR deliverables. > > > I'm afraid that doesn't answer the question. SunVTS, Explorer, SunMC, > Solaris, and the embedded controller software are all interlinked: > changes to one can imply changes to the others. Each is delivered > from a separate consolidation. Thus, coordination in any of those > changes is required. > > This case, at least so far, just establishes the linkage for libpcp > itself. I don't see what controls those application protocols. > > >>> The format of 'msg_data' is to be defined for every application >> >>seperately. >> >>> Every application will have a different format for 'msg_data' in >> >>request >> >>> message and for 'msg_data' in response message. >> >>The format of 'msg_data' is specific to application and SC. (which is >>again platform specific). > > > Right. Where is it? > > >>sun4v virtual channel architecture (FWARC 2005/173 Hypervisor Service >>API) is designed such that each virtual channel end points to take care >> of the message format for that specific channel. We argued with sun4v >>folks to provided a generic message sending mechanism (not just sending >>sequence of bytes mechanism) (similar to rscadm<->rmc-comm<>SC interface >>on previous platforms like Chalupa etc..). But they don't want to make >>the virtual channel communication specific to a application format. > > > That seems reasonable. I don't think I was questioning that. > > >>So the only option we have (for platform applications) is use to let >>each application design it's own protocol and talk to glvc directly to >>communicate with SC. We felt this is redundant doing same thing for each >>platform application and more difficult to manage. That's why we came >>with with thie libpcp for all platform applications to use for >>communications with SC. >> >>libpcp protocol is very simple. All it does is just to transport >>application specific data to SC in a specific format (that is understood >>by SC) using glvc's generic read/write interfaces. > > > So where are those application-specific interfaces? Are they in a > case to be presented later? > > The only architectural issue I can see with libpcp itself is why it > really needs to exist, and where it might be going. Would it be > reasonable for non-Ontario platforms to extend it to support future > system controller channels? That'd at least nail down one degree of > freedom. > -- Name : Venugopala Mula E-mail: venugopala.mula@sun.com Phone : 781-442-1050, x2150 From sacadmin Wed Jun 15 09:31:28 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5FGVRs0019237 for ; Wed, 15 Jun 2005 09:31:28 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j5FGUvnK023089; Wed, 15 Jun 2005 12:30:57 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j5FGUv3L023086; Wed, 15 Jun 2005 12:30:57 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17072.22465.810690.663313@gargle.gargle.HOWL> Date: Wed, 15 Jun 2005 12:30:57 -0400 From: James Carlson To: Venugopala.Mula@Sun.COM Cc: Shudong Zhou , psarc@sac.eng.sun.com, Tom Caron Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol In-Reply-To: Venu Mula's message of 15 June 2005 12:25:05 References: <200506140538.j5E5c7BF147705@billybob.sfbay.sun.com> <17070.52083.894751.827662@gargle.gargle.HOWL> <42AF4293.3070009@Sun.COM> <17072.10188.287304.655758@gargle.gargle.HOWL> <42B03D43.5060204@Sun.COM> <17072.17122.610414.105842@gargle.gargle.HOWL> <42B05661.4070604@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Content-Length: 827 Status: RO X-Status: $$$$ X-UID: 0000000012 Venu Mula writes: > James Carlson wrote: > > I'm afraid that doesn't answer the question. SunVTS, Explorer, SunMC, > > Solaris, and the embedded controller software are all interlinked: > > changes to one can imply changes to the others. Each is delivered > > from a separate consolidation. Thus, coordination in any of those > > changes is required. > > We are establishing a private contract with all these applications for > using libpcp interfaces, as part of this PSARC case. How is there a contract without even a description of the interfaces under contract? What's the scope of this case? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Jun 15 09:34:23 2005 Received: from phys-bur-1 (phys-bur-1.East.Sun.COM [129.148.9.72]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5FGYMs0019477 for ; Wed, 15 Jun 2005 09:34:22 -0700 (PDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0II400001WOG1K@bur-mail1.east.sun.com> (original mail from Venugopala.Mula@Sun.COM) for psarc@sac.eng.sun.com; Wed, 15 Jun 2005 12:33:53 -0400 (EDT) Received: from Sun.COM (pandit.East.Sun.COM [129.148.184.67]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0II400JS3WOHME@bur-mail1.east.sun.com>; Wed, 15 Jun 2005 12:33:53 -0400 (EDT) Date: Wed, 15 Jun 2005 12:32:55 -0400 From: Venu Mula Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol In-reply-to: <17072.22465.810690.663313@gargle.gargle.HOWL> To: James Carlson Cc: Shudong Zhou , psarc@sac.eng.sun.com, Tom Caron Reply-to: Venugopala.Mula@Sun.COM Message-id: <42B05837.3010009@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_37qur/Ph3Ya4tuIPKfGrAw)" X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <200506140538.j5E5c7BF147705@billybob.sfbay.sun.com> <17070.52083.894751.827662@gargle.gargle.HOWL> <42AF4293.3070009@Sun.COM> <17072.10188.287304.655758@gargle.gargle.HOWL> <42B03D43.5060204@Sun.COM> <17072.17122.610414.105842@gargle.gargle.HOWL> <42B05661.4070604@Sun.COM> <17072.22465.810690.663313@gargle.gargle.HOWL> Content-Length: 15761 Status: RO X-Status: $$$$ X-UID: 0000000013 This is a multi-part message in MIME format. --Boundary_(ID_37qur/Ph3Ya4tuIPKfGrAw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT > How is there a contract without even a description of the interfaces > under contract? The libpcp specification does explain about these interfaces (section-3). I am not sure what interfaces you are talking about. Attached email from Showdong for fasttrack. Venu James Carlson wrote: > Venu Mula writes: > >>James Carlson wrote: >> >>>I'm afraid that doesn't answer the question. SunVTS, Explorer, SunMC, >>>Solaris, and the embedded controller software are all interlinked: >>>changes to one can imply changes to the others. Each is delivered >>>from a separate consolidation. Thus, coordination in any of those >>>changes is required. >> >>We are establishing a private contract with all these applications for >>using libpcp interfaces, as part of this PSARC case. > > > How is there a contract without even a description of the interfaces > under contract? > > What's the scope of this case? > -- Name : Venugopala Mula E-mail: venugopala.mula@sun.com Phone : 781-442-1050, x2150 --Boundary_(ID_37qur/Ph3Ya4tuIPKfGrAw) Content-type: message/rfc822; name="Attached Message" Return-path: Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0II200L016JYO7@bur-mail1.east.sun.com> (original mail from szhou@billybob.sfbay.sun.com) for mvgr@bur-mail1.East.Sun.COM; Tue, 14 Jun 2005 01:37:55 -0400 (EDT) Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0II2002D67N7R5@bur-mail1.east.sun.com> for mvgr@bur-mail1.East.Sun.COM; Tue, 14 Jun 2005 01:37:55 -0400 (EDT) Received: from billybob.sfbay.sun.com (billybob.SFBay.Sun.COM [129.146.224.123]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j5E5btPu022326 for ; Mon, 13 Jun 2005 22:37:55 -0700 (PDT) Received: from billybob (billybob [129.146.224.123]) by billybob.sfbay.sun.com (8.13.4+Sun/8.13.4) with SMTP id j5E5c7BF147705; Mon, 13 Jun 2005 22:38:07 -0700 (PDT) Date: Mon, 13 Jun 2005 22:38:07 -0700 (PDT) From: Shudong Zhou Subject: PSARC 2005/372 Ontario Platform Channel Protocol To: psarc@sac.eng.sun.com Cc: Venugopala.Mula@Sun.COM Reply-to: Shudong Zhou Message-id: <200506140538.j5E5c7BF147705@billybob.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_13 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-MD5: MEogDx7cWE5Ltn8AI6Bk1Q== Original-recipient: rfc822;mvgr@bur-mail1.East.Sun.COM I'm sponsoring the following fasttrack for Venugopala Mula. The requested release binding is patch. A contract for SunMC to use libpcp will be provided soon. The timer is set to expire on 6/20/2005. Shudong /* * Copyright 2005 Sun Microsystems, Inc. All rights reserved. * Use is subject to license terms. */ #pragma ident "@(#)ontario_pcp_spec.txt 1.4 05/06/10 SMI" /***************************************************** * * Platform Channel Protocol (PCP) Specification * ******************************************************/ 1. Introduction. This document explains in detail about the platform channel protocol (PCP) used by Host and ALOM tasks to communicate over platform channels on Ontario/Erie platforms. Note: The PCP protocol is based on FMA ETM protocol format which is used for communication between FMA and ALOM over FMA channel. Refer following documents for information about FMA channel protocol. * Ontario FMA Phase 1 ETM-to-ETM Protocol Interface Spec. * Ontario FMA Phase 1 ETM-to-Transport API Interface Spec. 2. Platform Channel Protocol Format To initiate messages on platform channels, the sender first sends the platform channel message header to the receiver. The message header is sent in network byte order. The message header always starts with a magic number, which will be same for all types messages on platform channels, to avoid message framing errors. /* * magic number for Platform Channel Protocol (PCP) * ~(rot13("PCP_") = 0xAFBCAFA0 * rot13 is a simple Caesar-cypher encryption that replaces each English * letter with the one 13 places forward or back along the alphabet. */ #define PLAT_CHNL_PROT_MAGIC_NUM (0xAFBCAFA0) The magic number is followed by protocol version. The protocol version field can be used for compatabiity of future protocol format changes. #define PLAT_CHNL_PROT_VER_1 1 Based on the message type ('msg_type') the message data is interpreted differently. The 'msg_type' and 'sub_type' fields are provided by user applications. /* * Platform Channel Request Message Header. */ typedef struct pcp_req_msg_hdr { uint32_t magic_num; /* magic number */ uint8_t proto_ver; /* version info for */ /* backward compatibility */ uint8_t msg_type; /* provided by user apps */ uint8_t sub_type; /* provided by user apps */ uint8_t rsvd_pad; /* padding bits */ uint32_t xid; /* transaction id */ uint32_t timeout; /* timeout in seconds */ uint32_t msg_len; /* length of request or response data */ uint16_t msg_cksum; /* 16-bit checksum of req msg data */ uint16_t hdr_cksum; /* 16-bit checksum of req hdr */ } pcp_req_msg_hdr_t; /* * Platform Channel Response Message Header. */ typedef struct pcp_resp_msg_hdr { uint32_t magic_num; /* magic number */ uint8_t proto_ver; /* version info for */ /* backward compatibility */ uint8_t msg_type; /* passed to user apps */ uint8_t sub_type; /* passed to user apps */ uint8_t rsvd_pad; /* for padding */ uint32_t xid; /* transaction id */ uint32_t timeout; /* timeout in seconds */ uint32_t msg_len; /* length of request or response data */ uint32_t status; /* response status */ uint16_t msg_cksum; /* 16-bit checksum of resp msg data */ uint16_t hdr_cksum; /* 16-bit checksum of resp hdr */ } pcp_resp_msg_hdr_t; The transaction id (xid) field is used to match the request and response messages. The timeout value indicates to the receiver the time in seconds the sender expects the response. Similar to FMA ETM protocol, (-1) indicates no response is wanted; (0) indicates a willingness to wait forever. #define PCP_TO_NO_RESPONSE (-1) #define PCP_TO_WAIT_FOREVER (0) The message length (msg_len) field tells the length of message data. The header and message checksum values (msg_cksum & hdr_cksum) are used for data integrity of message header and data. The receiver after receiving the message header waits until it gets 'msg_len' bytes before interpreting the message data. The status field in the message header is used in the response message to communicate following generic errors to the message sender. #define PCP_OK (0) /* message received okay */ #define PCP_ERROR (1) /* generic error */ #define PCP_HDR_CKSUM_ERROR (2) /* header checksum error */ #define PCP_MSG_CKSUM_ERROR (3) /* message checksum error */ #define PCP_XPORT_ERROR (4) /* message in complete error */ After sending the message header, the sender sends the message data. The sender waits for the response message, if it is expecting for a response. The message data, supplied by the user applications is assumed tobe already in some known byte order (network byte or XDR or ???). 3. Platform Channel Protocol Library interfaces. 3.1. Interface Table --------------------------------------------------------------- Name Stability comments --------------------------------------------------------------- struct pcp_msg_t contracted project private - function pcp_init() contracted project private - function pcp_send_recv contracted project private - function pcp_close contracted project private - --------------------------------------------------------------- 3.2. Interfaces Description. The host (solaris) applications provide message in the following format to Platform Channel Host Library for sending to the receiver (i.e Service processor ). struct pcp_msg { uint8_t msg_type; uint8_t sub_type; uint32_t msg_len; void *msg_data; } pcp_msg_t; The host library copies the 'msg_type', 'sub_type' and 'msg_len' fields into the platform channel message header. The format of 'msg_data' is to be defined for every application seperately. Every application will have a different format for 'msg_data' in request message and for 'msg_data' in response message. Platform Channel Host Interface Library provides following interfaces to host applications for communication on platform channels: a). The host applications first call "pcp_init()" with complete channel device path name as an argument to initialize the specific platform channel. The actual device path names for each platform channel to be defined. (TBD). The platform channel device pathnames will be defined in the host library header file. /* * Function: Initialize Platform Channel connection. * * Arguments: * * char *channel_dev_path - Complete device path of platform channel. * * Return: * * 0 - Platform channel initialization success. * (-ve) - Platform channel initialization failure. * * Different return values: * * PCPL_INVALID_ARGS - invalid args. * PCPL_GLVC_ERROR - glvc driver error. * PCPL_ERROR - for other libpcp internal errors. * */ int pcp_init(char *channel_dev_path); b). The host applications shall call "pcp_close()" after the communication on platform channel is done. This is just a cleanup routine. /* * Function: Close Platform Channel connection. * * Arguments: None * * Return: * * 0 - Success * -1 - Failure */ int pcp_close(void); c). The host applications shall call "pcp_send_recv()" for sending and receiving messages on platform channels. The host applications shall supply the pointer to the 'resp_msg'. The host library will create memory for the 'msg_data' buffer in response msg and the host applications are expected to free this msg_data buffer in response msg. The timeout value signifies the time in seconds the host application expects a response message. If the host applications are not interested in response message the timeout value can be set to PCP_TO_NO_RESPONE. /* * Function: Send Request message and Receive response message on platform * channel. * * Arguments: * * pcp_msg_t *req_msg - Pointer to Request message * pcp_msg_t *resp_msg - Pointer to Response message. * uint32_t timeout - timeout value in seconds. * * Return: * ( 0 ) - Success * ( -ve ) - Host library returns any of the generic errors defined above * for pcp_send_recv failures. * * Different return values: * * * PCPL_INVALID_ARGS - invalid args. * PCPL_GLVC_TIMEOUT - glvc call timeout. * PCPL_XPORT_ERROR - transport error in request message * noticed by receiver. * PCPL_MALLOC_FAIL - malloc failure. * PCPL_CKSUM_ERROR - checksum error. */ int pcp_send_recv(pcp_msg_t *req_msg, pcp_msg_t *resp_msg, uint32_t timeout); Note: see "usr/src/lib/libpcp/common/libpcp.h" more libpcp api return codes. 4. 'libpcp' interface usage by user application. libpcp api is available to user applications as a shared library (libpcp.so). The libpcp.so library will reside under "/usr/platform/`uname -i`/lib/" directory on Ontario and Erie platforms. libpcp user applications should follow following sequence of steps to exchange messages with SC on Ontario and Erie platforms. a). Call pcp_init() with appropriate application specific channel device path. Note: Refer platform specific PD (partition descriptor) about different channels. glvc driver creates channels device nodes under /devices/virtual-devices@100/ directory on Ontario platform. b). If pcp_init() fails (i.e return value < 0 ), the libpcp user application can not proceed further in using libpcp api to communicate with SC. At this point, the user application may want log an error and exit in using libpcp api. c). Call pcp_send_recv() with appropriate arguments for sending/receiving messages. d). If pcp_send_recv() fails either repeat step 'c' or goto step 'g'. e). If pcp_send_recv is successful, free the response message data memory. libpcp allocates memory for the response message data. Applications should free the memory using free() call. (i.e "free(resp_msg->msg_data") ) f). To exchange more messages with SC, goto step 'c', or if message exchange with SC is done goto step 'g'. g). Call pcp_close(). h). Message exchange with SC is completed. 5. Platform Channl Communication Block Diagram on Ontario platform. See Figure 1 for current libpcp interface users and complete communication path from libpcp user apps to Service processor. ________ | SunVTS | | ALOM |____ _______ | Task | | | |___ |________| | |SunVTS | | . _________ | |_______| | . | SunMC | | | . | ALOM | | | ________ . | Task |__ | ________ |____| | . |________| | | | | | | . _________ | | | SunMC |______| | . | |__| | |________| | | _______ . _________ ______ | Data |____| |libpcp | | | . | | | | | Socket |____ __________ | |__| Glvc |_.__| Hyper- |__| VBSC |___| Monitor|__ | | |____| | |_______| . | -Visor | |______| |________| | | | Explorer | | | . |_________| | | |__________| __| | . __________ | | | |_______| . | Explorer | | | __________ | . | ALOM |__| | | | | . | Task | | | Picl |__| . |__________| | | Plugin | . | |__________| . _________ | . | Picl | | . | Plugin |_____| . | Task | . |_________| . <-- Libpcp ---><---- Solaris ------->. <-System FW -><------ SC firmware -----> Users. Figure 1 : libpcp user apps <-> Service Processor communication mechanism over platform channels. --Boundary_(ID_37qur/Ph3Ya4tuIPKfGrAw)-- From sacadmin Wed Jun 15 09:40:47 2005 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5FGels0020381 for ; Wed, 15 Jun 2005 09:40:47 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j5FGeH0l013400; Wed, 15 Jun 2005 09:40:17 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id j5FGeCp04969; Wed, 15 Jun 2005 09:40:13 -0700 (PDT) Message-ID: <42B059F2.2090701@sun.com> Date: Wed, 15 Jun 2005 09:40:18 -0700 From: Scott Rotondo User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20050421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Venugopala.Mula@sun.com CC: psarc@sac.eng.sun.com, szhou@billybob.sfbay.sun.com, Tom.Caron@sun.com Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol References: <200506151438.j5FEcjRW009088@marduk.eng.sun.com> <42B0409E.1020108@Sun.COM> In-Reply-To: <42B0409E.1020108@Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 607 Status: RO X-Status: $$$$ X-UID: 0000000014 Venu Mula wrote: > > Gary Winiger wrote: > >>>We just wanted to pick some random unique sequence so signify start of >> >> >> "PCP_" isn't random, it's meaningful. Why isn't it unique. >> This is really just a NIT, but seems very odd. > > > Yes, it's unique. We wanted to pick a seq that doesn't presence in > normal data stream. In addition to the magic sequence, we do check > protocol version number and message type field in header to make sure > that this is the right header on platform virtual channels. I can see why you might have a magic sequence, but how does it help to rot13 it? Scott From sacadmin Wed Jun 15 09:40:50 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5FGeos0020386 for ; Wed, 15 Jun 2005 09:40:50 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j5FGeKN7023132; Wed, 15 Jun 2005 12:40:20 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j5FGeKX4023129; Wed, 15 Jun 2005 12:40:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17072.23028.406318.328693@gargle.gargle.HOWL> Date: Wed, 15 Jun 2005 12:40:20 -0400 From: James Carlson To: Venugopala.Mula@Sun.COM Cc: Shudong Zhou , psarc@sac.eng.sun.com, Tom Caron Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol In-Reply-To: Venu Mula's message of 15 June 2005 12:32:55 References: <200506140538.j5E5c7BF147705@billybob.sfbay.sun.com> <17070.52083.894751.827662@gargle.gargle.HOWL> <42AF4293.3070009@Sun.COM> <17072.10188.287304.655758@gargle.gargle.HOWL> <42B03D43.5060204@Sun.COM> <17072.17122.610414.105842@gargle.gargle.HOWL> <42B05661.4070604@Sun.COM> <17072.22465.810690.663313@gargle.gargle.HOWL> <42B05837.3010009@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Content-Length: 725 Status: RO X-Status: $$$$ X-UID: 0000000015 Venu Mula writes: > > How is there a contract without even a description of the interfaces > > under contract? > > The libpcp specification does explain about these interfaces > (section-3). I am not sure what interfaces you are talking about. > > Attached email from Showdong for fasttrack. It doesn't describe the application messages, where the messages are documented, how the messages might evolve, how changes are managed. It seems that's an integral part of the case, and it's not present. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Jun 15 09:53:23 2005 Received: from phys-bur-1 (phys-bur-1.East.Sun.COM [129.148.9.72]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5FGrNs0021169 for ; Wed, 15 Jun 2005 09:53:23 -0700 (PDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0II400601XFHWA@bur-mail1.east.sun.com> (original mail from Venugopala.Mula@Sun.COM) for psarc@sac.eng.sun.com; Wed, 15 Jun 2005 12:52:53 -0400 (EDT) Received: from Sun.COM (pandit.East.Sun.COM [129.148.184.67]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0II400J1NXK5ME@bur-mail1.east.sun.com>; Wed, 15 Jun 2005 12:52:53 -0400 (EDT) Date: Wed, 15 Jun 2005 12:51:55 -0400 From: Venu Mula Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol In-reply-to: <42B059F2.2090701@sun.com> To: Scott Rotondo Cc: psarc@sac.eng.sun.com, szhou@billybob.sfbay.sun.com, Tom.Caron@Sun.COM Reply-to: Venugopala.Mula@Sun.COM Message-id: <42B05CAB.6060008@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <200506151438.j5FEcjRW009088@marduk.eng.sun.com> <42B0409E.1020108@Sun.COM> <42B059F2.2090701@sun.com> Content-Length: 970 Status: RO X-Status: $$$$ X-UID: 0000000016 > I can see why you might have a magic sequence, but how does it help to > rot13 it? I just followed the same way how FMA was doing on Ontario platform. Please let me know if it's not the right way todo, i'll change it. Venu Scott Rotondo wrote: > Venu Mula wrote: > >>Gary Winiger wrote: >> >> >>>>We just wanted to pick some random unique sequence so signify start of >>> >>> >>> "PCP_" isn't random, it's meaningful. Why isn't it unique. >>> This is really just a NIT, but seems very odd. >> >> >>Yes, it's unique. We wanted to pick a seq that doesn't presence in >>normal data stream. In addition to the magic sequence, we do check >>protocol version number and message type field in header to make sure >>that this is the right header on platform virtual channels. > > > I can see why you might have a magic sequence, but how does it help to > rot13 it? > > Scott -- Name : Venugopala Mula E-mail: venugopala.mula@sun.com Phone : 781-442-1050, x2150 From sacadmin Wed Jun 15 09:58:01 2005 Received: from phys-bur-1 (phys-bur-1.East.Sun.COM [129.148.9.72]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5FGw1s0022963 for ; Wed, 15 Jun 2005 09:58:01 -0700 (PDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0II400801XN5LS@bur-mail1.east.sun.com> (original mail from Venugopala.Mula@Sun.COM) for psarc@sac.eng.sun.com; Wed, 15 Jun 2005 12:57:32 -0400 (EDT) Received: from Sun.COM (pandit.East.Sun.COM [129.148.184.67]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0II400J5TXRWME@bur-mail1.east.sun.com>; Wed, 15 Jun 2005 12:57:32 -0400 (EDT) Date: Wed, 15 Jun 2005 12:56:34 -0400 From: Venu Mula Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol In-reply-to: <17072.23028.406318.328693@gargle.gargle.HOWL> To: James Carlson Cc: Shudong Zhou , psarc@sac.eng.sun.com, Tom Caron Reply-to: Venugopala.Mula@Sun.COM Message-id: <42B05DC2.6030809@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <200506140538.j5E5c7BF147705@billybob.sfbay.sun.com> <17070.52083.894751.827662@gargle.gargle.HOWL> <42AF4293.3070009@Sun.COM> <17072.10188.287304.655758@gargle.gargle.HOWL> <42B03D43.5060204@Sun.COM> <17072.17122.610414.105842@gargle.gargle.HOWL> <42B05661.4070604@Sun.COM> <17072.22465.810690.663313@gargle.gargle.HOWL> <42B05837.3010009@Sun.COM> <17072.23028.406318.328693@gargle.gargle.HOWL> Content-Length: 1114 Status: RO X-Status: $$$$ X-UID: 0000000017 James Carlson wrote: > It doesn't describe the application messages, where the messages are > documented, how the messages might evolve, how changes are managed. > > It seems that's an integral part of the case, and it's not present. We are in the process of documenting all these application specific msg formats, message types etc..that are shared by platform applications and SC. I can have a reference from libpcp specification to this document, but libpcp as such doesn't depend on this. Venu > Venu Mula writes: > >>>How is there a contract without even a description of the interfaces >>>under contract? >> >>The libpcp specification does explain about these interfaces >>(section-3). I am not sure what interfaces you are talking about. >> >>Attached email from Showdong for fasttrack. > > > It doesn't describe the application messages, where the messages are > documented, how the messages might evolve, how changes are managed. > > It seems that's an integral part of the case, and it's not present. > -- Name : Venugopala Mula E-mail: venugopala.mula@sun.com Phone : 781-442-1050, x2150 From sacadmin Wed Jun 15 13:01:55 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5FK1ss0006566 for ; Wed, 15 Jun 2005 13:01:55 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j5FK1JC0022310; Wed, 15 Jun 2005 16:01:19 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j5FK1FAk012543; Wed, 15 Jun 2005 16:01:15 -0400 (EDT) Subject: Re: PSARC 2005/372 Ontario Platform Channel Protocol From: Bill Sommerfeld To: Venugopala.Mula@sun.com Cc: James Carlson , Shudong Zhou , psarc@sac.eng.sun.com, Tom Caron In-Reply-To: <42B05DC2.6030809@Sun.COM> References: <200506140538.j5E5c7BF147705@billybob.sfbay.sun.com> <17070.52083.894751.827662@gargle.gargle.HOWL> <42AF4293.3070009@Sun.COM> <17072.10188.287304.655758@gargle.gargle.HOWL> <42B03D43.5060204@Sun.COM> <17072.17122.610414.105842@gargle.gargle.HOWL> <42B05661.4070604@Sun.COM> <17072.22465.810690.663313@gargle.gargle.HOWL> <42B05837.3010009@Sun.COM> <17072.23028.406318.328693@gargle.gargle.HOWL> <42B05DC2.6030809@Sun.COM> Content-Type: text/plain Message-Id: <1118865675.8185.300.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 15 Jun 2005 16:01:15 -0400 Content-Transfer-Encoding: 7bit Content-Length: 635 Status: RO X-Status: $$$$ X-UID: 0000000018 given the nature of the discussion and the desire for rapid convergence we came to a consensus to derail this case during arc business. it will be scheduled for inception review for next week. Looks to me like libpcp is a message transport multiplexor. The specs I've seen so far appear to be silent on exactly how the protocol codepoint space is managed. (specifically, msg_type and sub_type in pcp_{req,resp}_msg_hdr_t). This is a big hole in the specs. I'm assuming that the protocols used by individual clients of this library&protocol will be ARC'ed separately with the protocols recorded in separate ARC cases. From sacadmin Fri Jun 17 11:32:06 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5HIW6Eu009631 for ; Fri, 17 Jun 2005 11:32:06 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j5HIUXi23684; Fri, 17 Jun 2005 11:31:53 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.175.66]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j5HIUWPu013478; Fri, 17 Jun 2005 11:30:33 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5HIUWEu009600; Fri, 17 Jun 2005 11:30:32 -0700 (PDT) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9/Submit) id j5HIUWhi009599; Fri, 17 Jun 2005 11:30:32 -0700 (PDT) Date: Fri, 17 Jun 2005 11:30:32 -0700 (PDT) Message-Id: <200506171830.j5HIUWhi009599@sac.sfbay.sun.com> To: PSARC@sun.com Cc: Venugopala.Mula@sun.com, PSARC-coord@sun.com From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2005/372 Ontario Platform Channel Protocol Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii plain Content-Length: 241 Status: RO X-Status: $$$$ X-UID: 0000000019 New Materials submitted for PSARC 2005/372 Ontario Platform Channel Protocol Status: inception scheduled 06/22/2005 Files: /shared/sac/PSARC/2005/372/inception.materials/ontario_pcp_spec Please let me know if you have questions. - PSARC From sacadmin Fri Jun 24 12:25:07 2005 Received: from phys-bur-1 (phys-bur-1.East.Sun.COM [129.148.9.72]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5OJP7Eu006043 for ; Fri, 24 Jun 2005 12:25:07 -0700 (PDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IIL00801SK9P9@bur-mail1.east.sun.com> (original mail from Venugopala.Mula@Sun.COM) for psarc@sac.eng.sun.com; Fri, 24 Jun 2005 15:25:06 -0400 (EDT) Received: from Sun.COM (pandit.East.Sun.COM [129.148.184.67]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IIL00ATGSLU3K@bur-mail1.east.sun.com>; Fri, 24 Jun 2005 15:25:06 -0400 (EDT) Date: Fri, 24 Jun 2005 15:24:04 -0400 From: Venu Mula Subject: PSARC 2005/372 In-reply-to: <42BC1C3B.9060702@sun.com> To: psarc@sac.eng.sun.com Cc: Sherri Shieh , Shudong Zhou , Tom Caron Reply-to: Venugopala.Mula@Sun.COM Message-id: <42BC5DD4.5020108@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_xi29gxYH4Zqs3962XiTNxw)" X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <200506240209.j5O29Xeg156851@billybob.sfbay.sun.com> <42BC1C3B.9060702@sun.com> Content-Length: 23155 Status: RO X-Status: $$$$ X-UID: 0000000020 This is a multi-part message in MIME format. --Boundary_(ID_xi29gxYH4Zqs3962XiTNxw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Please find the updated project case material according to the PSARC inception review feedback. Regards, Venu --Boundary_(ID_xi29gxYH4Zqs3962XiTNxw) Content-type: text/plain; name=ontario_pcp_spec.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=ontario_pcp_spec.txt /* * Copyright 2005 Sun Microsystems, Inc. All rights reserved. * Use is subject to license terms. */ #pragma ident "@(#)ontario_pcp_spec.txt 1.6 05/06/24 SMI" Name: Solaris 'libpcp' Library Specification Document. Location: https://hees.east.sun.com/X/ontario/sw/dat/teams/sw/pcp/ ontario_pcp_spec.txt Revision History: Version Author Date Comments 1.1 Venu Mula 05/13/05 Initial version 1.2 Venu Mula 05/13/05 Added libpcp api usage 1.3 Venu Mula 06/07/05 Added libpcp block diagram 1.4 Venu Mula 06/10/05 Added interface table 1.5 Venu Mula 06/17/05 Added libpcp guide lines 1.6 Venu Mula 06/24/05 Changed whole document according PSARC inception review feedback. 1. Introduction This document describes 'libpcp' (platform channel protocol library) specification and its interfaces available in Solaris for sending/receiving messages from Solaris to System Controller via platform virtual channels in Niagara CPU based Sun4v platforms. 1.1 References 1.1.1 Project Documents Archive : http://hees.east.sun.com/X/ontario/sw/dat/teams/sw/pcp/ 1.1.2 'libpcp' 1-pager : http://hees.east.sun.com/X/ontario/sw/dat/teams/sw/pcp/libpcp.1pager 1.1.3 PSARC Case for this project : http://sac.eng/arc/PSARC/2005/372/ 1.1.4 FWARC case for Hypervisor Service API : http://sac.sfbay.sun.com/arc/FWARC/2005/173/ 1.2 Terminology 1.2.1. The words "application" or "libpcp users" or "Solaris applications" identify the Solaris side of virtual channel end-point. 1.2.2. The words "channel" or "virtual channel" identify the virtual channel provided by hypervisor/glvc for communication between Solaris and SC. 1.2.3. The words "platform virtual channel" or "platform channel" or "PCP channels" identify the virtual channels provided by glv/hypervisor for platform support usage. 1.2.4. The words "SC application" or "ALOM Tasks" identify the Solaris side of virtual channel end-point. 1.3 Glossary PCP - Platform Channel Protocol SC - System Controller or Service Processor libpcp - Solaris platform channel protocol library PD - Partition Descriptor 2. Project Description 2.1 Overview In Niagara CPU based sun4v platforms (Ontario and Erie), Host to System Controller (SC) communication is done via virtual channels provided by Hypervisor/glvc. On Solaris, glvc driver provides generic read/write/ioctl interfaces for reading/writing data to and from virtual channels. glvc driver does not define any protocol on how the messages are exchanged between virtual channel end points (i.e Solaris and SC) or does not define any message format for the data sent on virtual channels. On Ontario and Erie platforms Solaris applications such as SunVTS, Explorer, SunMC etc.. are required to communicate with System Controller for platform support. The main aim of this project is to implement Platform Channel Protocol (PCP) on Solaris for proper message exchange with SC on platform virtual channels and to provide interfaces for Solaris applications able to send/receive data to and from SC. 2.2 Assumptions 2.2.1. To use libpcp interfaces, it is assumed that Platform System Controller firmware must implement Platform Channel Protocol (Refer APPENDEX B). 2.2.2. To communicate with SC on a virtual channel, it is assumed that corresponding virtual channel device node is created by glvc/ hypervisor. To create new platform virtual channels, hypervisor partition descriptor (PD) table should include an entry for each virtual channel. Hypervisor PD is defined by platform system firmware. 2.2.3. It is assumed that libpcp shall not mandate any specific byte order for the application specific message data. It's left upto to the channel end applications. 2.3 Out of Scope The following things are out of scope for this project. 2.3.1. This project doesn't cover System Controller side support for Platform Channel Protocol. System Controller support for PCP is implemented in SC firmware and is covered under platform SC FWARC. 2.3.2. This project does not define or cover application specific information such as message data format or message types that is passed across channels. Refer respective platform host applications and platform system firmware implementation for this type of information. 3. Communication mechanism on Platform Virtual Channels 3.1 Platform virtuanl Channel communication Block Diagram ________ | SunVTS | | ALOM |____ _______ . | Task | | | |___ . |________| | |SunVTS | | . . . _________ | |_______| | . . . | SunMC | | | . . . | ALOM | | | . ________ . . | Task |__ | ________ |_.__| | . . |________| | | | | . | | . . _________ | | | SunMC |___.__| | . . | |__| | |________| . | | _______ . _________ ______ | Data |____| . |libpcp | | | . | | | | | Socket |____ __________ . | |__| Glvc |_.__| Hyper- |__| VBSC |___| Monitor|__ | | |_.__| | |_______| . | -Visor | |______| |________| | | | Explorer | . | | . |_________| . | | |__________| .__| | . . __________ | | .| |_______| . . | Explorer | | | __________ .| . . | ALOM |__| | | | .| . . | Task | | | Picl |_.| . . |__________| | | Plugin | . . . | |__________| . . . _________ | . . . | Picl | | . . . | Plugin |_____| . . . | Task | . . . |_________| . . . <-- Libpcp --.-><---- Solaris ------>. <-System FW -><------ SC firmware -----> Users. . <- PSARC-2005/372 -> <- FWARC-2005/173 --> <- FWARC-2005xxx --> Figure 1 : libpcp user apps <-> System Controller communication mechanism over platform virtual channels. 3.2 Description of PCP channel communication The following steps explain the end to end communication on platform virtual channels on sun4v platforms using libpcp interfaces. 1. Host application (such as SunVTS, SunMC etc..) requests libpcp to send data on a particular virtual channel. Refer section 4 & APPENDEX:A for detailed information on how host applications requests libpcp to send and receive data on virtual channels. 2. libpcp first creates a request message header which includes PCP protocol specific information and host application specific information such as (msg_type, sub_type & msg_len) and requests glvc driver to send request message header on virtual channel. 3. Corresponding SC application (such as SunVTS ALOM task etc..) gets the request message header, does a sanity check on header and based on header information, it waits for the request message data to arrive from host application. 4. libpcp now sends request message data, provided by host applications, to SC. 5. After receiving request message data, SC application executes appropriate application specific functionality based on request message and sends response message header and response message data in two seperate packets to libpcp. 6. libpcp receives response message header, does a sanity check (such as checksum), and after receiving response message data, it passes host application specific information (available in response message header) and response message data to host applications. 4. Solaris 'libpcp' Library interfaces. 4.1. Interface Table ------------------------------------------------------------ Name Stability comments ------------------------------------------------------------ struct pcp_msg_t sun private - function pcp_init() sun private - function pcp_send_recv sun private - function pcp_close sun private - ------------------------------------------------------------ 4.2. Guidelines for communicate with Service Controller using libpcp interfaces via virtual channels on Ontario platform. a) For communicating from Host to Service Controller (SC) using virtual channels on Ontario, glvc/hypervisor (FWARC/2005/173) needs to create a seperate virtual channel for every channel consumer. This information needs to be added to platform specific Partition Descriptor (PD) which resides in System firmware. Based on PD, glvc/hypervisor creates virtual channel device nodes under /devices/virtual-devices@xxx directory in Ontario platform. In current implementation, libpcp consumers provides this virtual channel device node to libpcp initialization routine (pcp_init()). b) Solaris applications and Service Service Controller side needs to define and implement appropriate support for following information. - 'msg_type' and 'sub_type' fields in request and response message headers. - message data format for request and response messages. (i.e 'msg_data' field in pcp_msg_t struct) - Solaris applications and System Controller firmware needs to implement support for interpreting the request/response messages and appropriate functionality. Note: libpcp does not define or interpret 'msg_type', 'sub_type' or message data format fields. c) For examples on how to use libpcp interfaces, Refer Platform specific applications such as SunVTS hsclbtest, Explorer, SunMC which access SC using virtual channels to get platform related information. 4.3. Interfaces Description. libpcp supports following interfaces and data structures for host applications to send/receive messages on platform virtual channels. 4.3.1 "pcp_msg_t" structure Host applications exchanges information with libpcp for sending or receiving data on virtual channels using pcp_msg_t data structure. struct pcp_msg { uint8_t msg_type; uint8_t sub_type; uint16_t rsvd_pad; uint32_t msg_len; void *msg_data; } pcp_msg_t; * 'msg_type' & 'sub_type' fields are application specific fields interpreted by host applications and system controller. * 'msg_len' field identifies that length of message data. * 'msg_data' fields points to the message data. For every message on virtual channel, libpcp or SC first sends a message header, which includes host application specific information such as msg_type, sub_type & msg_len and then sends the message data (i.e msg_data) on platform virtual channel. * 'msg_type' & 'sub_type' fields are application specific fields interpreted by host applications and system controller. * 'msg_len' field identifies that length of message data. * 'msg_data' fields points to the message data. 4.3.1 "pcp_init()" interface NAME: pcp_init - initializate virtual channel SYNOPSIS: #include "libpcp.h" int pcp_init(char *channel_name); DESCRIPTION: pcp_init() function initializes the platform virtual channel. 'channel_name' refers to the virtual channel created by glvc/hypervisor. In current implementation host applications shall supply complete path of the virtual channel device node as 'channel_name' to pcp_init(). RETURN VALUES: Upon successful completion, the pcp_init() initializes the virtual channel and returns a non-negative integer representing the channel file descriptor. Otherwise, a negative interger is returned to indicate channel initialization error. PCPL_INVALID_ARGS - Invalid arguments. PCPL_GLVC_ERROR - glvc driver error. PCPL_ERROR - libpcp internal error. 4.3.2 "pcp_send_recv()" Interface NAME: pcp_send_recv - send/receive message on virtual channel SYNOPSIS: #include "libpcp.h" int pcp_send_recv(int channel_fd, pcp_msg_t *req_msg, pcp_msg_t *resp_msg, uint32_t timeout); DESCRIPTION: pcp_send_recv() function sends request message - 'req_msg' - on virtual channel pointed by 'chnl_fd' and if host application expects a response message, the response message is returned in 'resp_msg'. The 'timeout' field identifies the time in secs libpcp to wait for the response message before returning timeout error. The timeout field can have following valid values: PCP_TO_NO_RESPONSE - no response message is expected 0 - wait forever for the response message. (1 to 0xfffffffe) - time to wait in secs for the response message. Note: Upon receiving response message, host application shall free the memory allocated for response message data (i.e resp_msg->msg_data) using free() call. RETURN VALUES: Upon successful completion, the pcp_send_recv() returns zero value. Otherwise, a negative interger is returned to indicate an error while sending/receving messages on virtual channel. PCPL_INVALID_ARGS - Invalid arguments. PCPL_GLVC_TIMEOUT - glvc call timeout. PCPL_XPORT_ERROR - Channel transport error. PCPL_MALLOC_FAIL - malloc failure. PCPL_CKSUM_ERROR - channel data checksum error. PCPL_ERROR - libpcp internal error. 4.3.1 "pcp_close()" interface NAME: pcp_close - close virtual channel SYNOPSIS: #include "libpcp.h" int pcp_close(int channel_fd); DESCRIPTION: pcp_close() function closes the virtual channel connection. RETURN VALUES: Upon successful completion, the pcp_close() returns 0. Otherwise, it will return -1 to indicate an error during channel close. 4.4 Example for 'libpcp' interface usage by user applications. libpcp api is available to user applications as a shared library (libpcp.so). The libpcp.so library will reside under "/usr/platform/`uname -i`/lib/" directory. Note: In current implementation 'libpcp.so' is available under Ontario and Erie platforms. For other platforms to use this library, proper links shall be made from respective platform lib directory to libpcp.so files under Ontario platform lib directory. libpcp user applications should follow following sequence of steps to exchange messages with SC via virtual platform channels. a). Call pcp_init() with appropriate application channel name. Note: Refer platform specific PD (partition descriptor) about different channels. glvc driver creates channels device nodes under /devices/virtual-devices@100/ directory on Ontario platform. b). If pcp_init() fails (i.e return value < 0 ), the libpcp user application can not proceed further in using libpcp api to communicate with SC. At this point, the user application may want log an error and exit in using libpcp api. c). Call pcp_send_recv() with appropriate arguments for sending/receiving messages. d). If pcp_send_recv() fails either repeat step 'c' or goto step 'g'. e). If pcp_send_recv is successful, free the response message data memory. libpcp allocates memory for the response message data. Applications should free the memory using free() call. (i.e "free(resp_msg->msg_data") ) f). To exchange more messages with SC, goto step 'c', or if message exchange with SC is done goto step 'g'. g). Call pcp_close(). h). Message exchange with SC is completed. Appendix A: Example source code for SunMC usage of libpcp interfaces for getting fru related info from System Controller. #define SC_FIOBD_SEEPROM_HANDLE 65 #define SUNMC_CHANNEL_TIMEOUT 30 /* secs*/ typedef struct pcp_get_fru_data { dp_handle_t handle; } pcp_get_fru_data_t; typedef struct pcp_fru_data { dp_handle_t handle; unsigned char fru_presence; unsigned char fru_data_status; unsigned char part_no[PCP_MAX_FRU_PN]; unsigned char serial_no[PCP_MAX_FRU_SN]; unsigned char vendor_name[PCP_MAX_FRU_VEND_NAME]; unsigned char initial_hw_dash_level[PCP_MAX_FRU_HW_DL]; unsigned char initial_hw_rev_level[PCP_MAX_FRU_HW_RL]; unsigned char dimm_size[PCP_MAX_DIMM_SZ]; } pcp_fru_data_t; void main() { int chnl_fd; pcp_get_fru_data_t *fru_data_req; pcp_fru_data_t *fru_data_resp; pcp_msg_t send_msg; pcp_msg_t recv_msg; int ret; /* initialize virtual channel */ if ((chnl_fd = pcp_init("sunmc")) < 0) { printf("channel initialization failed\n"); exit(1); } /* create request message data */ fru_data_req = malloc(sizeof(pcp_get_fru_data_t)); if (fru_data_req == NULL) { printf("malloc failure\n"); exit(1); } fru_data_req->handle = SC_FIOBD_SEEPROM_HANDLE; /* fru handle */ /* Fill in request message */ send_msg.msg_type = PCP_GET_FRU_DATA; send_msg.sub_type = 0; /* not used */ send_msg.msg_len = sizeof(pcp_get_fru_data_t); send_msg.msg_data = fru_data_req; /* send and recv message on virtual channel */ ret = pcp_send_recv(chnl_fd, &send_msg, &recv_msg, SUNMC_CHANNEL_TIMEOUT); if (ret < 0) { printf("pcp_send_recv failed. ret=%d\n", ret); free(fru_data_req); exit(1); } /* Parse response message data */ fru_data_resp = (pcp_fru_data_t *) recv_msg.msg_data; if (fru_data_resp == NULL) { printf("NULL response message data\n"); free(fru_data_req); exit(1); } .... /* End of parsing response message data */ free(fru_data_req); /* free response message data */ free(recv_msg.msg_data); /* close virtual channel fd */ pcp_close(chnl_fd); exit(0); } APPENDEX B: Platform Channel Protocol Description : To initiate messages on platform channels, the sender first sends the platform channel message header to the receiver. The message header is sent in network byte order. The message header always starts with a magic number, which will be same for all types messages on platform channels, to avoid message framing errors. /* * magic number for Platform Channel Protocol (PCP) * ~(rot13("PCP_") = 0xAFBCAFA0 * rot13 is a simple Caesar-cypher encryption that replaces each English * letter with the one 13 places forward or back along the alphabet. */ #define PLAT_CHNL_PROT_MAGIC_NUM (0xAFBCAFA0) The magic number is followed by protocol version. The protocol version field can be used for compatabiity of future protocol format changes. #define PLAT_CHNL_PROT_VER_1 1 Based on the message type ('msg_type') the message data is interpreted differently. The 'msg_type' and 'sub_type' fields are provided by user applications. /* * Platform Channel Request Message Header. */ typedef struct pcp_req_msg_hdr { uint32_t magic_num; /* magic number */ uint8_t proto_ver; /* version info for */ /* backward compatibility */ uint8_t msg_type; /* provided by user apps */ uint8_t sub_type; /* provided by user apps */ uint8_t rsvd_pad; /* padding bits */ uint32_t xid; /* transaction id */ uint32_t timeout; /* timeout in seconds */ uint32_t msg_len; /* length of request or response data */ uint16_t msg_cksum; /* 16-bit checksum of req msg data */ uint16_t hdr_cksum; /* 16-bit checksum of req hdr */ } pcp_req_msg_hdr_t; /* * Platform Channel Response Message Header. */ typedef struct pcp_resp_msg_hdr { uint32_t magic_num; /* magic number */ uint8_t proto_ver; /* version info for */ /* backward compatibility */ uint8_t msg_type; /* passed to user apps */ uint8_t sub_type; /* passed to user apps */ uint8_t rsvd_pad; /* for padding */ uint32_t xid; /* transaction id */ uint32_t timeout; /* timeout in seconds */ uint32_t msg_len; /* length of request or response data */ uint32_t status; /* response status */ uint16_t msg_cksum; /* 16-bit checksum of resp msg data */ uint16_t hdr_cksum; /* 16-bit checksum of resp hdr */ } pcp_resp_msg_hdr_t; The transaction id (xid) field is used to match the request and response messages. The timeout value indicates to the receiver the time in seconds the sender expects the response. (0xFFFFFFFF) indicates no response is wanted; (0) indicates a willingness to wait forever. #define PCP_TO_NO_RESPONSE (0xFFFFFFFF) #define PCP_TO_WAIT_FOREVER (0) The message length (msg_len) field tells the length of message data. The header and message checksum values (msg_cksum & hdr_cksum) are used for data integrity of message header and data. The receiver after receiving the message header waits until it gets 'msg_len' bytes before interpreting the message data. The status field in the message header is used in the response message to communicate following generic errors to the message sender. #define PCP_OK (0) /* message received okay */ #define PCP_ERROR (1) /* generic error */ #define PCP_HDR_CKSUM_ERROR (2) /* header checksum error */ #define PCP_MSG_CKSUM_ERROR (3) /* message checksum error */ #define PCP_XPORT_ERROR (4) /* message in complete error */ After sending the message header, the sender sends the message data. The sender waits for the response message, if it is expecting for a response. --Boundary_(ID_xi29gxYH4Zqs3962XiTNxw)-- From sacadmin Mon Jun 27 12:11:35 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5RJBZEu006172 for ; Mon, 27 Jun 2005 12:11:35 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.144]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j5RJBUd25906; Mon, 27 Jun 2005 12:11:31 -0700 (PDT) Received: from [192.168.0.100] (vpn-129-150-26-123.SFBay.Sun.COM [129.150.26.123]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5RJBUZ7585069; Mon, 27 Jun 2005 12:11:30 -0700 (PDT) Message-ID: <42C04F61.2030403@sun.com> Date: Mon, 27 Jun 2005 12:11:29 -0700 From: Sherri Shieh Reply-To: sherri.shieh@sun.com User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psarc@sun.com, Venu Mula Subject: Updated PSARC Materials Submitted: Ontario Platform Channel Protocol (2005/372) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 356 Status: RO X-Status: $$$$ X-UID: 0000000021 All, Updated materials have been submitted: -rw-rw-r-- 1 ss146556 sac-2 22652 Jun 27 12:03 ontario_pcp_spec_update - Sherri -- ---------------------- Sherri Shieh Program Manager Systems Architecture Sun Microsystems, Inc. Phone #: 650-786-5245/x85245 Email: sherri.shieh@sun.com =========================================================== From sacadmin Tue Jun 28 13:59:43 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5SKxhEu017412 for ; Tue, 28 Jun 2005 13:59:43 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.166]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j5SKxgo06281 for ; Tue, 28 Jun 2005 13:59:43 -0700 (PDT) Received: from Sun.COM (sr1-usca-17.SFBay.Sun.COM [129.145.155.112]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5SKxgVJ172661 for ; Tue, 28 Jun 2005 13:59:42 -0700 (PDT) Message-ID: <42C1BA3E.1020108@Sun.COM> Date: Tue, 28 Jun 2005 13:59:42 -0700 From: Sherri Shieh Reply-To: Sherri.Shieh@Sun.COM User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psarc-members@Sun.COM Subject: REMINDER: voting to be done on case 2005/372 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 487 Status: RO X-Status: $$$$ X-UID: 0000000022 All, This is just a reminder that we still need to take a vote on case 2005/372. I believe Shidong has sent out the draft opinion on it. Please read it through and send me your vote when you get the chance. Thanks! =D - Sherri -- ========================================================= Sherri Shieh Sun Microsystems, Inc. Program Manager Email: sherri.shieh@sun.com Systems Architecture Phone: 650-786-5245/x85245 =========================================================== From sacadmin Wed Jun 29 09:27:06 2005 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5TGR6Eu017320 for ; Wed, 29 Jun 2005 09:27:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j5TGR5q02514; Wed, 29 Jun 2005 09:27:05 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IIU00G0NTP5HR00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 29 Jun 2005 09:27:05 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.226.130]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IIU00EVVTP40L00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 29 Jun 2005 09:27:04 -0700 (PDT) Received: from sun.com (vpn-129-150-28-123.SFBay.Sun.COM [129.150.28.123]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5TGR3UF253128; Wed, 29 Jun 2005 09:27:03 -0700 (PDT) Date: Wed, 29 Jun 2005 09:26:55 -0700 From: Sherri Shieh Subject: Status on PSARC 2005/372 To: psarc-members@sun.com Cc: Tom Caron Message-id: <42C2CBCF.90100@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.0.1.144180 Content-Length: 966 Status: RO X-Status: $$$$ X-UID: 0000000023 All, Here is the status (that I have) of the voting of 2005/372: Yes: Shudong, Ed Gould, Jim Carlson Please let me know if I have missed your vote. If you haven't voted yet, please do so by COD today. The project team would like to get a status in the next day or so. Thanks, Sherri -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherri Shieh Program Manager, System Architecture Sun Microsystems, Inc. Email: Sherri.Shieh@sun.com Phone: 650-786-5245/x85345 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From sacadmin Wed Jun 29 09:42:59 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5TGgwEu018946 for ; Wed, 29 Jun 2005 09:42:58 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk.SFBay.Sun.COM [129.146.11.21]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j5TGgoo02381 for ; Wed, 29 Jun 2005 09:42:52 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j5TGgn80021510; Wed, 29 Jun 2005 09:42:49 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id j5TGfC0Q025561; Wed, 29 Jun 2005 09:41:12 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id j5TGfC9r025560; Wed, 29 Jun 2005 09:41:12 -0700 (PDT) Date: Wed, 29 Jun 2005 09:41:12 -0700 (PDT) From: Gary Winiger Message-Id: <200506291641.j5TGfC9r025560@marduk.eng.sun.com> To: psarc-members@sun.com, sherri.shieh@sun.com Subject: Re: Status on PSARC 2005/372 Cc: tom.caron@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 371 > Here is the status (that I have) of the voting of 2005/372: > > Yes: Shudong, Ed Gould, Jim Carlson > > > Please let me know if I have missed your vote. If you haven't voted > yet, please do so by COD today. The project team would like to get a > status in the next day or so. Please go back to the mail. I believe Glenn and I also voted to approve. Gary.. From sacadmin Wed Jun 29 09:47:13 2005 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5TGlDEu019134 for ; Wed, 29 Jun 2005 09:47:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j5TGlDq14287 for <@sunmail2.sfbay.sun.com:psarc-members@sun.com>; Wed, 29 Jun 2005 09:47:13 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IIU00K01UMPIR00@nwk-avmta-1.sfbay.Sun.COM> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Wed, 29 Jun 2005 09:47:13 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IIU00EZAUMO0L10@nwk-avmta-1.sfbay.Sun.COM> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Wed, 29 Jun 2005 09:47:12 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j5TGlB80022355; Wed, 29 Jun 2005 09:47:11 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id j5TGjYsL025572; Wed, 29 Jun 2005 09:45:34 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id j5TGjXWf025571; Wed, 29 Jun 2005 09:45:33 -0700 (PDT) Date: Wed, 29 Jun 2005 09:45:33 -0700 (PDT) From: Gary Winiger Subject: Re: Status on PSARC 2005/372 To: psarc-members@sun.com, sherri.shieh@sun.com, gww@marduk.eng.sun.com Cc: tom.caron@sun.com Message-id: <200506291645.j5TGjXWf025571@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.0.1.144180 Status: RO Content-Length: 586 > > Here is the status (that I have) of the voting of 2005/372: > > > > Yes: Shudong, Ed Gould, Jim Carlson > > > > > > Please let me know if I have missed your vote. If you haven't voted > > yet, please do so by COD today. The project team would like to get a > > status in the next day or so. > > Please go back to the mail. I believe Glenn and I also voted > to approve. Sorry I missed noting Bill here as well. Bill, Glenn and I pointed out necessary (though minor) changes to the opinion before it gets published. Will you (Sherri) be making those changes? Gary.. From sacadmin Thu Jun 30 00:32:33 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5U7WXEu017085 for ; Thu, 30 Jun 2005 00:32:33 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.31]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j5U7WVo14728; Thu, 30 Jun 2005 00:32:31 -0700 (PDT) Received: from sun.com (vpn-129-150-24-42.SFBay.Sun.COM [129.150.24.42]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5U7WVW0117426; Thu, 30 Jun 2005 00:32:31 -0700 (PDT) Message-ID: <42C3A007.10107@sun.com> Date: Thu, 30 Jun 2005 00:32:23 -0700 From: Sherri Shieh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psarc@sun.com CC: Tom Caron Subject: Final Tally Vote for PSARC 2005/372 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 980 All, Here is the final tally vote case 2005/372: Yes - Bill, Jim, Ed Gould, Gary, Shudong NP - Glenn Therefore, this case is approved. The opinion has also had some minor adjustments as well. Please let me know if there are any questions or if I have captured the vote incorrectly. Thanks, Sherri -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherri Shieh Program Manager, System Architecture Sun Microsystems, Inc. Email: Sherri.Shieh@sun.com Phone: 650-786-5245/x85345 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From sacadmin Mon Nov 28 23:14:02 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAT7E1IQ019834 for ; Mon, 28 Nov 2005 23:14:02 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id jAT7E0j20758 for ; Tue, 29 Nov 2005 00:14:00 -0700 (MST) Received: from billybob.sfbay.sun.com (billybob.SFBay.Sun.COM [129.146.224.123]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAT7E0Te019439 for ; Mon, 28 Nov 2005 23:14:00 -0800 (PST) Received: from billybob (billybob [129.146.224.123]) by billybob.sfbay.sun.com (8.13.5+Sun/8.13.5) with SMTP id jAT7Jw6D145282 for ; Mon, 28 Nov 2005 23:19:58 -0800 (PST) Message-Id: <200511290719.jAT7Jw6D145282@billybob.sfbay.sun.com> Date: Mon, 28 Nov 2005 23:19:58 -0800 (PST) From: Shudong Zhou Reply-To: Shudong Zhou Subject: Opinion: PSARC 2005/372 Solaris libpcp To: psarc@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7y/UYj+GQu8GzijAgx+4eQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_13 SunOS 5.11 i86pc i386 Status: RO Content-Length: 4283 Please review by 12/05/2005. http://sac.sfbay/PSARC/2005/372/opinion.html This case was voted by email while I was on vacation. The case mail log mentions minor changes to the opinion from Bill, Glenn, and Gary, but doesn't go into specifics. Please let me know if the changes are not captured in the current version. Shudong Sun Microsystems Systems Architecture Committee Subject Solaris libpcp Submitted by Venu Mula File PSARC/2005/372/opinion.html Date June 30th, 2005 Committee Shudong Zhou, James Carlson, Edward Gould, William Sommerfeld, Gary Winiger Steering Committee Operating Systems and Networking 1. Summary This case proposes a library interface for Sun management applications to communicate with system controllers. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a patch release of Solaris. 3. Interfaces Interfaces Exported Interface Name Classification Comment pci_msg_t Sun Private message structure pcp_init() Sun Private init channel pcp_send_recv Sun Private send/recv message pcp_close Sun Private close channel 4. Opinion The ARC review focused on the completeness of the specification and the need for common interfaces for communicating with the system controllers. 4.1 Completeness The proposal appeared incomplete since it is not possible to write an application without a specification of the message format to be sent and received. After further discussion, PSARC is satisfied with limiting this case to abstract libpcp interfaces, with the expectation that the message specification will be provided as part of a future FWARC case covering the Ontario platform. 4.2 Common System Controller Interfaces PSARC has noted a plethora of interfaces for Solaris to talk to system controllers. o PSARC 2002/198 PICL Plugin environmental ioctls o PSARC 2002/199 Remote Management Control (RMC) o PSARC 2002/206 Environmental sysevents o PSARC 2002/437 PICL plugin environmental ioctls [updated] o PSARC 2002/361 PICL Class for Service Processors o PSARC 2000/019 LOMlite support software and documentation o PSARC 2001/412 LOM bus nexus driver o PSARC 1998/074 RSC: Remote System Control o PSARC 2000/157 Device Links for RSC o PSARC 1997/329 Starfire Network Console o PSARC 1999/302 Extend Starfire Network Console for Starcat o PSARC 2000/248 PICL Environmental Properties and Classes o PSARC 2001/418 PICL environmental classes o PSARC 2000/214 PICL classes addendum o PSARC 2002/045 Makaha System Management Controller(SMC) Driver o PSARC 2000/121 System Alarms and Service Monitoring This case is another platform specific addition to the collection. The lack of standardization in system controller interfaces results in a significant waste of resources and must be stopped. As each platform team designs and implements a different set of interfaces, various management applications must be rewritten to consume the new interfaces. Sun customers must also be retrained for the new system controller interfaces associated with new platforms. A strong advise is provided to the Solaris PAC in section 6. 5. Minority Opinion(s) None. 6. Advisory Information The Solaris PAC and SSG are strongly advised to start a project to standardize system controller interfaces and stop the waste of resources as described in section 4.2. Appendices Appendix A: Technical Changes Required None Appendix B: Technical Changes Advised None Appendix C: Reference Material Unless otherwise stated, path names are relative to the case directory (PSARC/2005/372). 1. ontario_pcp_spec.txt From sacadmin Tue Dec 6 14:03:16 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jB6M3GIQ028797 for ; Tue, 6 Dec 2005 14:03:16 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id jB6M3D127301 for <@sunmail3.sfbay.sun.com:psarc@sun.com>; Tue, 6 Dec 2005 14:03:13 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0IR30030DJWTIT00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Tue, 06 Dec 2005 14:02:53 -0800 (PST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IR3002GDJWTQL40@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Tue, 06 Dec 2005 14:02:53 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jB6M2qnj025035; Tue, 06 Dec 2005 14:02:53 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id jB6M1nCH021655; Tue, 06 Dec 2005 14:01:49 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id jB6M1nUN021654; Tue, 06 Dec 2005 14:01:49 -0800 (PST) Date: Tue, 06 Dec 2005 14:01:49 -0800 (PST) From: Gary Winiger Subject: Re: Opinion: PSARC 2005/372 Solaris libpcp To: psarc@sun.com, szhou@billybob.sfbay.sun.com Message-id: <200512062201.jB6M1nUN021654@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.0.207369 Status: RO Content-Length: 404 > This case was voted by email while I was on vacation. The case > mail log mentions minor changes to the opinion from Bill, Glenn, > and Gary, but doesn't go into specifics. Please let me know if > the changes are not captured in the current version. I believe the changes were to capture Bill, Glenn, and Gary as approving. I see this draft has Bill and Gary. It looks like Glenn was NP. Gary.. From sacadmin Tue Dec 6 18:47:56 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jB72ltIQ009751 for ; Tue, 6 Dec 2005 18:47:55 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id jB72lsk21839 for ; Tue, 6 Dec 2005 19:47:54 -0700 (MST) Received: from billybob.sfbay.sun.com (billybob.SFBay.Sun.COM [129.146.224.123]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jB72lsTe010537 for ; Tue, 6 Dec 2005 18:47:54 -0800 (PST) Received: from billybob (billybob [129.146.224.123]) by billybob.sfbay.sun.com (8.13.5+Sun/8.13.5) with SMTP id jB72s7Rt214735; Tue, 6 Dec 2005 18:54:07 -0800 (PST) Message-Id: <200512070254.jB72s7Rt214735@billybob.sfbay.sun.com> Date: Tue, 6 Dec 2005 18:54:07 -0800 (PST) From: Shudong Zhou Reply-To: Shudong Zhou Subject: Re: Opinion: PSARC 2005/372 Solaris libpcp To: psarc@sun.com, szhou@billybob.sfbay.sun.com, gww@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lupmpGlM/MwsdFQUiWODOw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_13 SunOS 5.11 i86pc i386 Status: RO Content-Length: 586 Gary, Thanks. The minor change could be about adding the list of approvers, which I did. The final mail from Sherri explicitly listed Glenn as NP. Shudong > > > This case was voted by email while I was on vacation. The case > > mail log mentions minor changes to the opinion from Bill, Glenn, > > and Gary, but doesn't go into specifics. Please let me know if > > the changes are not captured in the current version. > > I believe the changes were to capture Bill, Glenn, and Gary > as approving. I see this draft has Bill and Gary. It looks > like Glenn was NP. > > Gary.. From sac-owner Mon Dec 12 17:35:47 2005 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jBD1ZlIQ028840 for ; Mon, 12 Dec 2005 17:35:47 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.175.66]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jBD1ZlTe023998 for ; Mon, 12 Dec 2005 17:35:47 -0800 (PST) Received: from billybob.sfbay.sun.com (billybob.SFBay.Sun.COM [129.146.224.123]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jBD1ZkIQ028837 for ; Mon, 12 Dec 2005 17:35:46 -0800 (PST) Received: from billybob (billybob [129.146.224.123]) by billybob.sfbay.sun.com (8.13.5+Sun/8.13.5) with SMTP id jBD1gENr102331 for ; Mon, 12 Dec 2005 17:42:14 -0800 (PST) Message-Id: <200512130142.jBD1gENr102331@billybob.sfbay.sun.com> Date: Mon, 12 Dec 2005 17:42:14 -0800 (PST) From: Shudong Zhou Reply-To: Shudong Zhou Subject: Opinion: PSARC 2005/372 Solaris libpcp To: sac-review@sac.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /k3CUkEwZx0PXmBsIEJ6Ig== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_13 SunOS 5.11 i86pc i386 Status: RO Content-Length: 4282 Please review by 12/19/2005. http://sac.sfbay/PSARC/2005/372/opinion.html This case was voted by email while I was on vacation. The case mail log mentions minor changes to the opinion from Bill, Glenn, and Gary, but doesn't go into specifics. Please let me know if the changes are not captured in the current version. Shudong Sun Microsystems Systems Architecture Committee Subject Solaris libpcp Submitted by Venu Mula File PSARC/2005/372/opinion.html Date June 30th, 2005 Committee Shudong Zhou, James Carlson, Edward Gould, William Sommerfeld, Gary Winiger Steering Committee Operating Systems and Networking 1. Summary This case proposes a library interface for Sun management applications to communicate with system controllers. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a patch release of Solaris. 3. Interfaces Interfaces Exported Interface Name Classification Comment pci_msg_t Sun Private message structure pcp_init() Sun Private init channel pcp_send_recv Sun Private send/recv message pcp_close Sun Private close channel 4. Opinion The ARC review focused on the completeness of the specification and the need for common interfaces for communicating with the system controllers. 4.1 Completeness The proposal appeared incomplete since it is not possible to write an application without a specification of the message format to be sent and received. After further discussion, PSARC is satisfied with limiting this case to abstract libpcp interfaces, with the expectation that the message specification will be provided as part of a future FWARC case covering the Ontario platform. 4.2 Common System Controller Interfaces PSARC has noted a plethora of interfaces for Solaris to talk to system controllers. o PSARC 2002/198 PICL Plugin environmental ioctls o PSARC 2002/199 Remote Management Control (RMC) o PSARC 2002/206 Environmental sysevents o PSARC 2002/437 PICL plugin environmental ioctls [updated] o PSARC 2002/361 PICL Class for Service Processors o PSARC 2000/019 LOMlite support software and documentation o PSARC 2001/412 LOM bus nexus driver o PSARC 1998/074 RSC: Remote System Control o PSARC 2000/157 Device Links for RSC o PSARC 1997/329 Starfire Network Console o PSARC 1999/302 Extend Starfire Network Console for Starcat o PSARC 2000/248 PICL Environmental Properties and Classes o PSARC 2001/418 PICL environmental classes o PSARC 2000/214 PICL classes addendum o PSARC 2002/045 Makaha System Management Controller(SMC) Driver o PSARC 2000/121 System Alarms and Service Monitoring This case is another platform specific addition to the collection. The lack of standardization in system controller interfaces results in a significant waste of resources and must be stopped. As each platform team designs and implements a different set of interfaces, various management applications must be rewritten to consume the new interfaces. Sun customers must also be retrained for the new system controller interfaces associated with new platforms. A strong advise is provided to the Solaris PAC in section 6. 5. Minority Opinion(s) None. 6. Advisory Information The Solaris PAC and SSG are strongly advised to start a project to standardize system controller interfaces and stop the waste of resources as described in section 4.2. Appendices Appendix A: Technical Changes Required None Appendix B: Technical Changes Advised None Appendix C: Reference Material Unless otherwise stated, path names are relative to the case directory (PSARC/2005/372). 1. ontario_pcp_spec.txt From sac-owner Wed Dec 21 13:56:35 2005 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jBLLuYIQ001377 for ; Wed, 21 Dec 2005 13:56:35 -0800 (PST) Received: from sunmail4.Singapore.Sun.COM (localhost [127.0.0.1]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id jBLLuYVL013744 for ; Thu, 22 Dec 2005 05:56:34 +0800 (SGT) Received: (from noaccess@localhost) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/Submit) id jBLLuXP9013743 for sac-opinion-not-2b-used-directly; Thu, 22 Dec 2005 05:56:33 +0800 (SGT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id jBLLuNTg013613 for <@sunmail3.sfbay.sun.com:sac-opinion@sun.com>; Thu, 22 Dec 2005 05:56:33 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0IRV00G07BM85200@nwk-avmta-2.sfbay.sun.com> for sac-opinion@sun.com (ORCPT sac-opinion@sun.com); Wed, 21 Dec 2005 13:56:32 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IRV00B63BM7K550@nwk-avmta-2.sfbay.sun.com> for sac-opinion@sun.com (ORCPT sac-opinion@sun.com); Wed, 21 Dec 2005 13:56:31 -0800 (PST) Received: from billybob.sfbay.sun.com (billybob.SFBay.Sun.COM [129.146.224.123]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jBLLuVTe004850 for ; Wed, 21 Dec 2005 13:56:31 -0800 (PST) Received: from billybob (billybob [129.146.224.123]) by billybob.sfbay.sun.com (8.13.5+Sun/8.13.5) with SMTP id jBLM3HI5125368 for ; Wed, 21 Dec 2005 14:03:17 -0800 (PST) Date: Wed, 21 Dec 2005 14:03:17 -0800 (PST) From: Shudong Zhou Subject: Opinion: PSARC/2005/372 To: sac-opinion@sun.com Reply-to: Shudong Zhou Message-id: <200512212203.jBLM3HI5125368@billybob.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_13 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: ceZS+CydUgnMgK63TiIFFQ== X-PMX-Version: 5.1.1.222179 Status: RO Content-Length: 3945 Sun Microsystems Systems Architecture Committee Subject Solaris libpcp Submitted by Venu Mula File PSARC/2005/372/opinion.html Date June 30th, 2005 Committee Shudong Zhou, James Carlson, Edward Gould, William Sommerfeld, Gary Winiger Steering Committee Operating Systems and Networking 1. Summary This case proposes a library interface for Sun management applications to communicate with system controllers. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a patch release of Solaris. 3. Interfaces Interfaces Exported Interface Name Classification Comment pci_msg_t Sun Private message structure pcp_init() Sun Private init channel pcp_send_recv Sun Private send/recv message pcp_close Sun Private close channel 4. Opinion The ARC review focused on the completeness of the specification and the need for common interfaces for communicating with the system controllers. 4.1 Completeness The proposal appeared incomplete since it is not possible to write an application without a specification of the message format to be sent and received. After further discussion, PSARC is satisfied with limiting this case to abstract libpcp interfaces, with the expectation that the message specification will be provided as part of a future FWARC case covering the Ontario platform. 4.2 Common System Controller Interfaces PSARC has noted a plethora of interfaces for Solaris to talk to system controllers. o PSARC 2002/198 PICL Plugin environmental ioctls o PSARC 2002/199 Remote Management Control (RMC) o PSARC 2002/206 Environmental sysevents o PSARC 2002/437 PICL plugin environmental ioctls [updated] o PSARC 2002/361 PICL Class for Service Processors o PSARC 2000/019 LOMlite support software and documentation o PSARC 2001/412 LOM bus nexus driver o PSARC 1998/074 RSC: Remote System Control o PSARC 2000/157 Device Links for RSC o PSARC 1997/329 Starfire Network Console o PSARC 1999/302 Extend Starfire Network Console for Starcat o PSARC 2000/248 PICL Environmental Properties and Classes o PSARC 2001/418 PICL environmental classes o PSARC 2000/214 PICL classes addendum o PSARC 2002/045 Makaha System Management Controller(SMC) Driver o PSARC 2000/121 System Alarms and Service Monitoring This case is another platform specific addition to the collection. The lack of standardization in system controller interfaces results in a significant waste of resources and must be stopped. As each platform team designs and implements a different set of interfaces, various management applications must be rewritten to consume the new interfaces. Sun customers must also be retrained for the new system controller interfaces associated with new platforms. A strong advise is provided to the Solaris PAC in section 6. 5. Minority Opinion(s) None. 6. Advisory Information The Solaris PAC and SSG are strongly advised to start a project to standardize system controller interfaces and stop the waste of resources as described in section 4.2. Appendices Appendix A: Technical Changes Required None Appendix B: Technical Changes Advised None Appendix C: Reference Material Unless otherwise stated, path names are relative to the case directory (PSARC/2005/372). 1. ontario_pcp_spec.txt