Commitment: Domain Services (2006/055) Submitter: eric.sharakan@sun.com Owner: Hitendra Zhangada Intern: Narayan Venkat SUMMARY ======= 1. Delete .93 versions of the documents and the delta file. 2. Fix an oversight for section 3.3.3 (Success = 0x0) 3. Define MAXSTRLEN in section 2.5 and add a note that it applies to entire document - this will also be an interface. 4. Define error codes in a common way 5. Change seq_no to req_num and move it as a first element of the structure 6. Change CPU IDs to 8 bytes and be consistent with calling it a virtual CPU ID. 7. After project team sends out an updated document we will determine if we need another review next week or can we vote via e-mail. For now we will hold a spot for the next week's meeting. ISSUES ====== Issues from inception - this will be updated for commitment --------------------- Narayan's issues: ---------------- 1.2.1 - can you also put LDC in parentheses same place where it is being spelt out for the first time. Status: OPEN NEW STATUS: CLOSED 1.2.1, 2nd para - you are using the acronym 'DS' for the first time can you expand this further in the first para of this section. Status: OPEN NEW STATUS: CLOSED 2.3 - the word "..following.." is slightly misleading in the first sentence. Status: OPEN NEW STATUS: CLOSED 2.3.{1,2,3} minor nit, Can you make it more clear that the value here is msg_type. I presume the structure here defines the content of the payload .. The size of the payload will then correspond to the size of this structure .. - correct ? Status: OPEN NEW STATUS: CLOSED 2.4 It is implicit in the explanation here why you dont send back a major version in the ACK or what the minor version means. The minor version in the ACK means that you support the corresponding major version and all the minor version <= the version in the ACK. Right ? Status: OPEN NEW SATUS: has been corrected 2.5.4 would it make sense to add a line or two to state when a DS_REG_NACK will be sent. Status: OPEN NEW STATUS: CLOSED 2.5.5 4th para, I dont see anywhere in your structures the status field you are referring to here. There is no msg format defined for the error response. Status: OPEN NEW STATUS: CLOSED 3.{1,2,3}.1 There is no explanation of what the seqno in these requests are for. Status: OPEN NEW STATUS: CLOSED The seqno needs to be in both the request and the response. So we can match the request to a response. It might be more like a streamID. This is a opaque value and will be generated by the upper level service. We will need to define how we generate this number. Status: OPEN NEW STATUS: CLOSED 3.2.1 what is the 'ms_delay' value for. Revise description on how it is used. Status: OPEN NEW STATUS: CLOSED Sunit's issues: -------------- [1] Section 2.5.1.3 Register Failed Are the values of 'svc_handle' and 'major_vers' valid for all cases for which NACK is generated? Even for DS_REG_NACK & DS_REG_DUP? Revise doc to revise that fields are not valid for DS_REG_DUP? Status: OPEN NEW STATUS: CLOSED Please explain status DS_OK - 'NACK with Status=Success' sounds confusing. I think DS_OK is really returned when the major version do not match and 'major_vers' contains supported major version. If that right, it needs to be added to the document. Shoiuld no have a DS_OK with a NACK messages. Status: OPEN NEW STATUS: CLOSED [2] Sections 2.5.5 & 256 'ds_handle' is not defined in any of the structures in previous sections. Is 'ds_handle' same as 'svc_handle' ? They are the same. Change all references to svc_handle. Status: OPEN NEW STATUS: CLOSED Steve's issues: -------------- A simple flow chart of how a domain services provider/consumer negotiates capabilities with respect to the versioning would be much easier to understand than a textual step-by-step description. Of course, it's up to the project team to decide if they want to implement that. same versioning mechanism as sun4v Status: CLOSED Appendix A should be some sort of registry, not just an appendix to a document in the materials directory (similar to the hypervisor API registry, or the vendor FCode registry). Create a registry on FWARC for each service Status: OPEN NEW STATUS: update spec Will OBP be expected to support DS? If so, can we present the structures in block/packet format instead of C-style so there are no endianness issues. A table might be better since we are sending LDC packets, we should use a block structure as supposed to a c-style. Rewrite doc in table format. C is not contrained to put data in blocks. Add a bit layout and specify endianness. Status: OPEN NEW STATUS: CLOSED Inception issues: ---------------- sunit> 3.{1,2,3}.2 - Make SUCCESS as 0. Status: OPEN NEW STATUS: CLOSED 3.3.1 reason string - should be null terminated Status: OPEN NEW STATUS: CLOSED New sections in spec --------------------- 3.4.1 3.4.2 - Message Header 3.4.3 3.4.5 VOTE ==== yes - no - abstain - NP - NEXT STEP ========= * Project team will update the document by COB today - there will be a tentative schedule for a commitment 2 review pending on the updated documentation. This meeting will be cancelled if this can be done through email. ===========================================================================