Folks - The following assumes some familiarity with the SCSI architecture document. These are topics which need to be further investigated to fill in details in the architecture. This is a design activity and will require that you think about issues of performance, maintainability, usefulness to customers, etc. The topics here may in some cases need only a couple days, or in other cases maybe a couple weeks to investigate. Please think about the topics and how long you expect to be needed for them. The investigations need to produce more detailed text to go into the architecture at the next level down in details. My hope is that most of these will be relatively short since there is plenty of additional detail to go beyond this. We will parcel these out at or about the Thursday meeting; the idea of passing the list around is that people might have favorite topics or want clarification or further definition. The time before then will give you some chance to seek such. More details of the interfaces at various levels of SCSI and the interfaces for common routines will need to be worked out, but these questions need to come first. The times needed will be negotiated after selections. glenn ----------------------------- SCSI architectural issues needing investigation reports 1. Support of SDTR/WDTR and LUNs. SDTR/WDTR are ID wide, but one gets inquiry data per LUN. How should SDTR be treated (pref. for smart adapters) in terms of the various enabled bits? Ditto WDTR. Force all to be the same? Switch on reselect? Disallow certain configurations? what? The question is what operations should be performed, when, to handle these negotiations correctly and in a fashion to support most devices. (There are comments in existing code about SDTR and these issues which will help.) 2. The architecture document proposes a super-SCDRP containing command buffers as well as state information and possibly custom packing calls to port drivers to handle very unique packing (i.e., not just copy SCSI command into buffer) as well as some means of telling where the CMD buffer should be located. Are there any hidden issues with doing this that would act as problems? Any reasons such a proposal might negatively impact function or performance? 3. How should SCSI data structures be linked together? (Remember SCSI3 is likely to mean larger IDs, LUN numbers, and maybe wider constants.) Moving from one data structure to another is frequent and we need to be sure a scheme in the architecture can handle growth and be efficient. 4. Is a single level selector sufficient for matching device "SCSI IQ" or peculiarities within class level? Or are there examples where additional capabilities lists should be maintained per device? Suggest forms for these to take if needed. Can one create a single number (or a single number per VMS function) as suggested in the architecture to be a valid representation of a SCSI IQ, or must more dimensions be used? If so, what? (Can a SCSI device be an idiot savant?) 5. What parts of flow control can be reasonably handled at class startio and what needs to be done at port level? Would it be more advantageous to just have flow control all handled at port level? The object is to avoid resource exhaustion and strive for some I/O fairness. This involves questions of whether the class busy bits are adequate, how should queue depth and queue full status interact, and at what level, and whether one should (try to) use mode pages to tell how full a TCQ queue is and adapt to the hardware. How to handle the switch to single command vs. TCQ mode is an issue too. (Should one issue bus device reset or some such to stop long operations?) Also an issue: multi-initiator busses. If one can setmode-control quotas one might adapt total quotas so the queues would retain room even though >1 initiator is using the bus. (Since the queue manager is to be part of only those port drivers for "dumb" ports, the current flow control scheme resident in it needs to be revisited.) (Any issues with "large" I/Os?) 6. What do SCSI control chips supply by way of bus quality metrics? Is there any common information that can be captured and made available to users in some fashion about this, or are the control chips so different that basically no common information is conceivable? Bus quality metrics are desirable for diagnosis of field problems, possibly for field tuning of parts of SCSI, and for determining when path failover might be needed...IF it is feasible to obtain any such thing in a reasonable way. 7. At what level can RESET be handled? Is it possible to move such handling all (or mostly: some code would be common with packack handling) down to the top level port code? In general can more specific rules of thumb be given about which errors should be handled at low level vs. handling in class code? The architecture document proposes a rule that states you handle errors in class code unless knowledge of the error condition is complete at lower levels. Can we be more specific about various types of errors? The current use of mount verify to respond to SCSI bus reset makes its use for path failover difficult and imposes performance penalties which have no business being present; handling RESET should be done somewhere within the SCSI subsystem envelope. Since it is a bus-wide condition it would seem logical to do so in the bus level code (i.e., in the port driver.) Question is, is this feasible, and what issues arise from doing such? 8. What SCSI knobs and switches should be made controllable for starters? (There's a good deal in the documents about things to control, but also how does one set profiles?) 9. What is needed for a driver disconnect capability? (How should one idle a device? What about long I/O operations? ) (Involves disconnect, reconnect, and possibly driver unload as a further option.) 10. How should VMS locate port drivers and initialize SCSI subsystems? 11. Is there a better way to pass I/O to port level than the current svapte/bcnt/boff one? What general memory management routines are needed to translate addresses? Can we specify the interface to such? 12. How should AEN be handled? (Target mode too.) Best to put any of it into port code (beyond the interrupt recognition)? Should a new class driver be present? 13. Time-out. Can anything more general be done than having the timeout set by class level function dispatch? Adapt to devices perhaps? Again how might one store and init a profile in clusters? 14. When should errors be logged and in what form? Can some generic rules of thumb (testable!) be given more than are in the current document for this?