送信者: Alan R. Whitney 宛先: Wayne Cannon ; Brent Carlson ; Dick Ferris ; Dave Graham ; Nori Kawaguchi ; Tetsuro Kondo ; Sergei Pogrebenko ; Misha Popov ; Jon Romney ; Ralph Spencer ; Alan Whitney ; Ed Himwich 件名 : Fwd: Re: Strawman VSI-S spec 日時 : 2001年3月6日 3:45 Gentlemen, I have received the following note from Dick Ferris with his usual careful and complete comments and suggestions. I would like to try to update the strawman by the end of this week (if I can!) and re-distribute. Therefore, I solicit any comments you may have ASAP. Thanks, Alan - >X-Authentication-Warning: venice.tip.CSIRO.AU: dferris owned process doing -bs >Date: Mon, 5 Mar 2001 22:35:00 +1100 (EST) >From: Dick Ferris >X-X-Sender: >To: "Alan R. Whitney" >Subject: Re: Strawman VSI-S spec >- >Hi Alan, >- >I wish to begin my comments with a run-through of Strawman 1.0 taken at >face value, then canvas some more general ideas arising from the >discussion so far. >- >"H-" and "S-" prefixes will be used to distinguish paragraph numbers in >the current VSI-H and VSI-S documents. >- >- >Strawman Review >--------------- >S-4.1 Command Syntax >Colon looks good on the page as the field separator, but comma is >universally used for this purpose, does not require case-shift, and is >used in the familiar and closely related SNAP language. >Suggest we use comma. >- >- >S-4.4 .. Execution Syntax >Should not act as an implicit terminator (semi-colon) when necessary? >Not a sop to lazy typists, but a means of avoiding the consequences of the >inevitable unterminated comment. (The suggestion lapses if trailing >sequence numbers and sumchecks are adopted.) >- >- >S-4.6 P/QDATA Syntax and Usage >Should (H-7.1.1[5.]) act as ';', or should P/QDATA >steams be regarded as logically continuous? >- >- >S-4.6 P/QDATA Syntax and Usage >There is a contradiction between "except that the content is strictly >informational" and suggestions (H-14.3.1 and others, S-3.3) that PDATA be >used to cause execution of a 'dotset' command or its equivalent, or that >PDATA be used for general control of the DIM [H-14.3.2]. >- >- >S-4.6 Keyword and Field Rules >"Case is significant" (two places). Outside of ASCII Literals, >significant mixed case commands are a source of error and frustration, for >little real gain. It is notable that the suggested command tables in >S-6.1 to 6.6 get by with lower case only. >- >Suggest case is insignificant for keywords and fields. >- >If case remains significant, then we should (and either way we could) >recognise and name VSI-H objects properly when they appear in keywords and >fields, vis:DIMsync, CLOCKfreq, DOTset, PVALID, TVR etc. >- >- >S-6.1/2 DIM ..Cmnds/Resps >clockfreq #1 Description: "Clock frequency" should be "CLOCK frequency" >- >clockfreq #[2] Description: "Sample rate divider ratio" is not a concept > expressed in VSI-H. The correct form is "bit-stream > information rate" but I would settle for "Input bit-rate" >- > Then Allowed Values and Comments are the same as for #1, > and Default = CLOCK >- >- >mask: Like an image from MC Escher, 0xffffff can be interpreted two ways. > If seen as a set of flags then BS0 is on the left. If seen as > register contents then BS0 corresponds to bit-0, on the right. We > need to be specific; I have a slight preference for the second > form. >- >PDATA Control > In systems supporting command execution via the PDATA interface, as >suggested by CRL/Kashima group and anticipated by H-14.3.2, it may be >prudent to give ultimate authority to the Control interface with > PDATActrl= enable|disable >- >- >S-6.4 DOM/5 .. Cmnds/Resps >domclock Allowed Values: I believe 'tapetime' or some such should be > included for standalone playback as per H-14.2 >- >rclockfreq Description: Should be "DOM RCLOCK frequency" >- >- >S-6.5 DOM Query Resps >We need a 'mask' response to reveal the results of that command in the >DIM. Field values etc as in S-6.1 >- >- >S-6.6 Suggested P/QDATA formats >With the exception of 'time' the items listed could equally be accessed >via the DTS control interface, not just P/QDATA. Perhaps the table should >be titled 'Suggested Information Commands' (or 'Aux Data Commands'). >- >Additional examples are : > tape= Tape ID, tvg= (is) on|off, data= (is) valid|invalid. >- >As noted above in the discussion of S4.6, PDATA may be used as an >additional or alternative source of DTS commands, and 'time' is really >just an unnecessary alias for 'dotset' (which could easily acquire >its field #2). >- >- >Previous Comments >----------------- >Checksum and sequence numbers : agree. >- >Action on checksum failure : > First note that S-4.4 introduces a superior level to the VSI-S > protocol, a string of zero_to_many commands plus , which > for brevity we call a 'line'. >- > The line is the unit of execution in the DTS, the unit of > qualification via the CRC, and the unit of repetition by the > controller when necessary. >- >There appears to be no problem with the DTS reporting a checksum failure. >Since its exact cause in the line is unknown, no part of the line can be >acted on, and the controller will necessarily repeat the whole line, >whereupon processing resumes. Reporting the failure provides useful >information to the controller, and distinguishes the event from a true >timeout due to communications failure. >- >If a response CRC fails, then this information is necessarily already with >the controller. The unavoidable repetition of the command line is duly >taken care of by the proposed sequence number mechanism. >- >- >Note that the line parser cannot determine the identity of until it >finds an immediate . Otherwise these characters could be part of a >command. In the case of missing or corrupt the DTS must time-out, and >must do so before the controller gets bored and sends a repeat, since any >new characters must necessarily be appended to the current buffer and thus >create chaos. >- >In this case a sequence, is better defined >than a sequence, and maintains >the normal request/response part of the basic protocol. >- >- >4096 buffer length, distinction between error codes and status returns >instead of periodic returns: agree. >- > >Omit Comments: disagree >- >The comment is a valuable tool in our environment as a means of injecting >information into the log file. This in turn is about the only reliable >means of making (DIM) operator's reports available at the DPS at >processing time. The most obvious example is the regular use of SNAP's >comment facility to report impromptu local editing of the PCFS command >file, and to report minor (and not so minor!) run-time disasters. >- >The strawman comment syntax in S-4.3 is a bit problematic. A safer and >more regular form is as a standard command, vis: comment=; >- >- >User registered Ether port: agree. >Presumably access to port number, IP address, Ethernet address, baudrate >etc are handled by DTS specific system resources at boot-time. >- >- >Allow disable checksum/sequence num: disagree >To provide a command generator on an intelligent terminal (pc) for testing >purposes should not be a significant problem. On the other hand providing >a means of bypassing security and quality measures is to invite their >general avoidance. >- >In any case this is really part of a larger issue: >- >The Role of VSI-S >----------------- >VSI-S provides for communication across the DTS Control Interface for some >controlling process, and as noted by Crestch group is a machine-machine >protocol. The existence of the DTSCI does not preclude the existence of >an on-board 'console' process providing user-level access, either >separately or simultaneously. The controlling process will itself usually >provide such a console facility, supporting keyboard entry and user-level >control files. As such, VSI-S need not and should not try to support >user-level access directly. >- >A significant number of suggestions to date (including some at the >beginning of this epistle) are actually aimed at facilitating direct >(manual) interaction with the DTS at the cost of complicating the >protocol, and as such might be better avoided. As C-group have also >noted with respect to user control files, user interfaces are outside the >scope of this document. >- >In this category I would put; > multi-command 'line's [S-4.4] > anywhere transparent Comment [S-4.3] > line-breaks [RS 21Feb] > cscheck [C-group 20Feb] > act