================================================================================ Note 63.0 Other things we might consider in meeting our deliverables 2 replies EVMS::RLORD "Rick Lord" 122 lines 3-NOV-1995 12:26 -------------------------------------------------------------------------------- 3-Nov-95 Friday Regardless of what our problem statement is, I think that in real terms this is what we have to deliver, and that whatever we do has to specifically address each of these things: 1) Smaller backlog of QARs and CLDs - clean up old work 2) Lower QAR and CLD arrival rate - suggests better design, code, testing 3) Higher QAR and CLD closure rate, lower average days-open value - suggests that we're bug-fixing more effectively 4) Shorter new-feature turnaround time - suggests more extensible design & code 5) SCSI contribution to every release of VMS - suggests that we know what we're doing 6) Documentation that 3rd party developers can rely on - stable interfaces 7) Improved response to customer problems - utilities to update firmware, manage SCSI devices (for field workarounds), collect problem info We can go a long way towards meeting these deliverables by concentrating on things which make it faster or easier to do the following - and I'm basing this only on my own experience, my own observation of where my time goes when I'm working on a problem. Usually designing and coding the fix itself represents a smaller percentage of the time than I'd like: 1) Determine the cause of a crash 2) Make sense of an error log entry 3) Build a new driver 4) Figure out how this particular driver works Having a clean, documented subsystem design that someone can become familiar with quickly will definitely help us meet our deliverables, but I think that we should also consider the following: 1) Team member skills and knowledge 2) Driver implementation 3) Maintenance documentation 4) Other Stuff 1) Team member skills and knowledge - o Work on developing a consistent set of debugging skills across all members of the team: SDA, XDelta, HLL debugger, building systems and drivers, etc. Sometimes the learning curve for a utility can make you decide that it's faster to just use what you know. Tutorials or even cheat sheets can make a big difference here - I put off learning the HLL debugger longer than I should have, but the hour that Jim took talking me through getting it up and running has I'm sure been recovered over my using XDELTA. 2) Driver implementation - these are isolated changes which might be worthwhile even if we don't have time to figure out if they'll fit into the new design: o Back the mode sense code off to issuing 6-byte mode sense commands just by not setting the 10-byte bit, ever. We risk literally nothing at this point in terms of missing Mode Sense data because nothing is returning more than 255 bytes of data yet. It's a quick way of eliminating the admittedly few problems which might be reported when someone's device doesn't do Mode Sense 10 correctly and logs a bunch of errors on startup. When we do set the 10-byte bit later it might be that we've figured out a clean way to suppress those initial errors. o Reduce the volume of code we have to maintain by identifying subroutines which do the same thing and replacing them with a single subroutine in common code, changing the subroutine's clients as little as possible. o Make sure that every single error logged by any driver is identified by a unique type and subtype so that even if the same error is logged five times in a driver the specific instance of it can be identified. o Make sure that every single bugcheck in a driver is unique - jumping or branching to a common bugcheck obscures the cause of the bugcheck and makes it hard to determine exactly why it occurred. o Make our error log entries useful, and never omit sense data when it's available or log anything inaccurate (like the dummy mode sense CDB - I understand the reason for it, but it's not obvious from the error log that it's a dummy). o Implement a single ring buffer mechanism in a common module and make all drivers use it instead of implementing their own. Define a structure for the entry, allowing each driver to specify some of it's own data too. o Without adding a whole new interface, modify the IO$_DIAGNOSE interface to accept one modifiers to enable ring buffers and another to disable and extract ring buffers; add just that level of IO$_DIAGNOSE support to the port drivers too. This might be a V7.1 throwaway. 3) Maintenance documentation - o Create VAX and Alpha tables which map drivers to adapters to platforms. Given the number of each that we have, it can be tricky keeping them straight. o Have the reigning expert for each driver do a white paper on it describing it. What's the use of script code? When is firmware loaded? What modules are specific to this driver? This wouldn't have to be a thesis, just a quick tutorial on a specific driver. o Document library, source and image module relationships on both VAX and Alpha - the scope of module modifications should always be clear. o Create an area for the SCSI team to archive working documentation and make keeping it up-to-date a priority - it may not always be complete, but it should always be correct. Keep the white papers, tables, cheat sheets, etc. here. 4) Other stuff - o Create and maintain a build procedure which will allow quick, painless builds of any SCSI facility component, any VMS release, VAX or Alpha. This can be done much more easily than with FACGEN. Check it in to the SCSI facility and maintain it with the code. o Keep SCSI$CORONER, one person to collect all of the information related to a given problem and put it all in one place for someone to draw from. When someone starts working on a problem they should have everything they need in front of them. Until all of the information is together, no one should be assigned to work on the problem. o Limit the combined number of QARs and CLDs assigned to any one person to 2 or 3 at a time. ================================================================================ Note 63.1 Other things we might consider in meeting our deliverables 1 of 2 EVMS::EVERHART 43 lines 6-NOV-1995 08:52 -< My take on projects >- -------------------------------------------------------------------------------- This is a cut at 7.2 time projects... 1. Insert set/sense mode code into any drivers not done in 7.1 and allow control of: 6/10 byte mode sense sdtr wdtr tcq timeout values used for devices ring buffer control (see below) special tape processing choices if tape at least, per device. This would provide the beginnings of a mechanism to let us address CLDs & QARs that have to do with commodity devices that don't respond right to something. We should attempt to put in some device capabilities structures too, though not necessarily start using them as part of this subproject. 2. Address the lots-o-IDs 'n' LUNs problems of 16 IDs and even of FC/AL scsi3 fiber loops. These are getting attention from outside and we need to get data structures in shape for this at least. Possibly leave the option open while mucking into data structures here to pull CMD buffers into SCDRPs. (Depends on scope of work which Mary's study will make more clear.) We're getting lots of push from storage and clusters for this and addressing it may not be optional. 3. Rationalize error log entries & messages, as Rick suggested. 4. Generate some ring buffer code for problem diagnosis that can be enabled at customer sites to get us better info what goes wrong. 5. (If there's time to schedule it): reorganize either mkdriver or scsicommon so that in the first case special case code is better isolated, or in the second so we start moving the queue manager into specific port drivers. 6. I think Rick's "white paper" about how current drivers work could be a good thing and will help people understand what might have to be altered when writing glue code somewhere else in the system. Glenn ================================================================================ Note 63.2 Other things we might consider in meeting our deliverables 2 of 2 STAR::S_SOMMER 35 lines 6-NOV-1995 08:59 -------------------------------------------------------------------------------- I agree wholeheartedly with Rick's emphasis on choosing deliverables which would make the system overall more maintainable. An additional suggestion along those same lines: Before we pick our final "top N" projects for proactive maintenance, we might ask the reigning expert on each component to scan the EVMS-ZETA and EVMS-THETA databases for that component; list each QAR and give a one-line root cause underneath the stated abstract. At the end, give a paragraph summary to categorize the top 2 or 3 troublemakers for the component. (And place a time deadline of, say, two days to accomplish this.) The troublemakers are not just the bugs themselves, but what in the environment made it tricky to fix them. Until that is done, the final list can't be drawn up accurately. But I have a hunch that some of the projects will be in the area of: o Enhanced error logging o Enhanced, well-documented debug buffers to trace bus/adapter activity. o Tagged queuing path (queue manager especially) o Third party friendliness in establishing a connection o Bus reset o Data structure cleanup o Documentation-only projects for DK, SCSI2COMMON, PKE, PKQ. o (Maybe) Sharing of more routines o (Maybe) Cleanup of MKDRIVER to include less device-dependent code, though I'm not at all convinced (yet) that will lower any QAR rates. I feel especially strongly about the first two. SCSI is a unique subsystem in that we can never 100% prepare for the wide variety of SCSI vendor implementations. Perhaps more than any other component in VMS we should invest in the development of detailed troubleshooting tools which can be used in the field. I don't think that points to any excessive flaws in SCSI; it's just part of maintaining a subsystem that by nature is firmware-vulnerable. ================================================================================ Note 64.0 List of potential projects for IR 1 reply EVMS::RLORD "Rick Lord" 32 lines 6-NOV-1995 14:30 -------------------------------------------------------------------------------- The first reply to this note will contain a more detailed list of the following projects: 1. Project: Big IDs and LUNs 2. Project: Maintenance Interface (IO$_DIAGNOSE) 3. Project: Mount Verification Support 4. Project: Shadowing Support 5. Project: Control Interface (IO$_SExMODE or similiar) 6. Project: SDTR & Fast SCSI 7. Project: WDTR (16 or 32 bits) 8. Project: Bus Resets 9. Project: SCSI Commands 10. Project: AEN 11. Project: Target Mode 12. Project: Power Management 13. Project: Cancel I/O 14. Project: Error Logging 15. Project: Flow Control 16. Project: Memory Management 17. Project: Skip Files 18. Project: Device-Specific (Device-Class+Device-Type+Firmware) Treatment 19. Project: Driver Diagnostics 20. Project: Utility Applications 21. Project: Documentation 22. Project: Quick & Dirty 23. Project: SCSI Command Error Recovery 24. Project: Data Structure Cleanup 25. Project: Restructure Drivers 26. Project: Queue Manager 27. Project: High-Risk SCSI Features 28. Project: Provide Support For > 64KB Transfers at Port Level ================================================================================ Note 64.1 List of potential projects for IR 1 of 1 EVMS::RLORD "Rick Lord" 438 lines 6-NOV-1995 14:30 -< More detail for some of the base note projects >- -------------------------------------------------------------------------------- 1. Project: Big IDs and LUNs Description: Modify the class and port drivers to work with 64 bit IDs and LUNs. Motivation: Driver data structures must be changed to allow supporting more than 8 devices anyway, whether to 16 bits for full support of wide busses or 64 bits for supporting serial busses; take the hit once and go to 64 bit fields instead of doing it incrementally. Drawbacks/Limitations: ? Cost: ? 2. Project: Maintenance Interface (IO$_DIAGNOSE) Description: Add an extended IO$_DIAGNOSE interface to port drivers. Motivation: Allows us to issue commands to SCSI device slots arbitrarily; by itself this would be a useful test/debug capability for devices that either didn't make it through configuration or for those whose configuration we wanted to suppress to get access to the power up state; in combination with target mode this would provide us with a way of duplicating device sequences which are causing us problems. Drawbacks/Limitations: ? Cost: ? 3. Project: Mount Verification Support Description: Figure out what special support is needed for Mount Verification in the SCSI class drivers, implement and document it. Motivation: This would a tough code path to troubleshoot without documentation, but I don't think that it is documented anywhere other than in the driver code. Drawbacks/Limitations: ? Cost: ? Page 2 4. Project: Shadowing Support Description: Same as mount verification. Motivation: Same as mount verification. Drawbacks/Limitations: ? Cost: ? 5. Project: Control Interface (IO$_SExMODE or similiar) Description: For enabling, disabling and extracting ring buffers and controlling driver functionality such as SDTR, WDTR, TCQ, etc. Motivation: In combination with common ring buffer code and a user-mode utility, this functionality would allow us to collect diagnostic information from the field without having the customer send us their system or devices. Drawbacks/Limitations: Does not help us with problems devices may have when we are configuring them, such as not liking SDTR. Drawbacks/Limitations: ? Cost: ? 6. Project: SDTR & Fast SCSI Description: Implement and document a consistent mechanism for determining whether SDTR should be negotiated or not, what parameters to use if so, when it should be renegotiated and when it should be negotiated OFF: does clearing the SYNCHRONOUS bit in the IO$_DIAGNOSE interface mean to turn synchronous off, or just use whatever mode the device is in? Also, respond correctly to devices negotiating SDTR with us. Motivation: Prevent running asynchronously unnecessarily, prevent issuing an SDTR message for every command, prevent bus uh-oh's from our port drivers not being able to handle a device initiating (instead of just responding to) SDTR. Drawbacks/Limitations: ? Cost: ? Page 3 7. Project: WDTR (16 or 32 bits) Description: Enable negotiation of WDTR in a manner similiar to that used for SDTR, and able to be disabled easily. Motivation: We want to take advantage of having a wide bus available to us whenever we can, unless at boot time the device is identified as having a problem with it. Drawbacks/Limitations: ? Cost: ? 8. Project: Bus Resets Description: Avoid when possible, minimize impact when not Motivation: Drawbacks/Limitations: ? Cost: ? 9. Project: SCSI Commands Description: Remove construction of SCSI commands from the class drivers and move it into a class-common module, providing an API so any class driver can issue any SCSI command. Motivation: It would simplify the class drivers if all they had to deal with was the data returned from SCSI commands instead of the SCSI commands themselves; Drawbacks/Limitations: ? Cost: ? 10. Project: AEN Description: Implement consistent, mostly port-common AEN code. Motivation: Drawbacks/Limitations: ? Cost: ? Page 4 11. Project: Target Mode Description: Implement consistent, mostly port-common Target Mode code. Motivation: Drawbacks/Limitations: ? Cost: ? 12. Project: Power Management Description: We need to define and implement a policy on power management. Motivation: It would be nice if a user didn't have to run an application to enable or disable power management on their new disks. Drawbacks/Limitations: I'm not sure that this is defined in a standard manner yet, I think that on the Burns disks we've tested, two pages are used to define the power management bits and they're both either reserved or device-type specific. Cost: ? 13. Project: Cancel I/O Description: We could be cancelling more I/O than we currently do, if we were willing to scan the IRP list and set a bit in the IRP which would tell the port driver to either not bother issuing the command (in the case where the SCDRP is sitting in the port queue) or to attempt to cancel just that command (maybe issue an Abort or Abort Tag the next time the device reselects us). Also, the current implementation doesn't quite handle the IO$_DIAGNOSE channel interlock problem correctly, it's still possible for a process to die and leave the IO$_DIAGNOSE interface inaccessible due to a PID mismatch. Motivation: Speed up cancellation, channel deassignment, prevent the loss of the IO$_DIAGNOSE interface. Drawbacks/Limitations: Ports would have to be massaged individually. Cost: ? Page 5 14. Project: Error Logging Description: Improve error logging in all drivers, making them more useful in diagnosing problems. Motivation: Incomplete and inaccurate error log entries are sometimes less than useful and sometimes even misleading. Drawbacks/Limitations: ? 15. Project: Flow Control Description: Implement some means of controlling the flow of I/O and command through the SCSI drivers at different levels, ideally able to be tuned at run time with a call through the control interface. Motivation: Allows us to characterize mixtures of devices, provides some level of tunability to bizarre customer configurations. Drawbacks/Limitations: ? Cost: ? 16. Project: Memory Management Description: Implement a consistent method of memory management across the class and port drivers, and provide common code for all drivers to use. Motivation: Reduced maintenance. Drawbacks/Limitations: ? Cost: ? 17. Project: Skip Files Description: Provide the ability to skip by file rather than by record. Motivation: Improved tape performance. Drawbacks/Limitations: ? Cost: ? Page 6 18. Project: Device-Specific (Device-Class+Device-Type+Firmware) Treatment Description: Implement a class-common means of identifying a device by class, type and firmware revision and mapping into a device table to determine if the device needs special treatment; until the device is identified and it's limitations, if any, are known, no optional SCSI features such as TCQ, SDTR, WDTR, 10-byte Mode Sense, etc. should be used. Motivation: Until we have a registry in which to store driver-accessible information across boots we have to either use SYSGEN parameters or a consistent means of identifying SCSI devices at boot time so we can take special action in the drivers to avoid certain actions which might prevent them from being configured properly. We could identify the device when we boot and use the information to determine whether any special action is required for the device, setting a composite bit to minimize the impact on mainline code. Drawbacks/Limitations: Temporary fix - the registry would be the right method. Cost: ? 19. Project: Driver Diagnostics Description: Common ring buffer format & code Motivation: Drawbacks/Limitations: ? Cost: ? 20. Project: Utility Applications Description: User mode applications to issue targeted SCSI commands to device, or to collect ring buffer, mode sense, etc. information from SCSI devices or drivers. Utilities like this are dependent upon a good IO$_DIAGNOSE interface. Motivation: Simplify getting information from the field by distributing applications like SCSI_INFO which allow someone to mail us an ASCII file so we can see how the device is configured. Drawbacks/Limitations: Applications which allow us to tell customers how to customize mode pages or do bus resets, etc. present a risk if misused. Cost: ? Page 7 21. Project: Documentation Description: Define what it is we want to produce for documentation, both internal and external. Motivation: I don't think anyone questions the value of documentation, but every document also presents something of a maintenance burden - if it's not going to be kept up to date it's probably not worthwhile to do it at all. One thing we should consider is that the code base is likely to be undergoing some signficant changes in the near future - we are committed to documenting the new code base, but this will leave the V6.2 code base essentially undocumented, and if we expect that some customers will be running V6.2 for five years then we have to hope that the reigning experts on those versions of the drivers are still here (and doing SCSI) in five years. o White Papers - release-specific revisions starting with V6.2 o Cheat Sheets - on how to do the HLL debugger, read a KP stack, etc. o Driver+Adapter+Platform Tables - o Formal Documentation - Drawbacks/Limitations: ? Cost: ? 22. Project: Quick & Dirty Description: Low impact code tweaks Motivation: Easy to implement, improved debugging, slightly fewer calls from people who own disks that don't do 10 byte Mode Sense correctly. o Back off to 6 byte Mode Sense commands o Make sure every bugcheck in every driver is unique. o Make sure every error log is uniquely typed+subtyped Drawbacks/Limitations: Someday a device will want to return more data then can be returned in the buffer described by a 6-byte Mode Sense command (256 bytes), but I don't think it's likely to happen soon - it would break too many things in the PC and U*ix world. SCSI-3 may have huge Mode Sense pages, but at least those devices will be new devices that probably don't clone their 6-byte code to build thier 10-byte code, so we could base our 6 vs 10 byte decision on that. Page 8 Cost: ? 23. Project: SCSI Command Error Recovery Description: Take the Progressively Bigger Hammer approach toward cleaning up failed or timed out SCSI commands: start with Abort Tag, go to Abort, then to Bus Device Reset and only then to Bus Reset. Motivation: Reduced number of Bus Resets, which are time consuming and error prone to clean up after. Drawbacks/Limitations: ? Cost: ? 24. Project: Data Structure Cleanup Description: Reorganize and document data structures, clean up naming and maybe sizing and alignment; define and enforce access rules. Motivation: Simplified maintenance. Drawbacks/Limitations: ? Cost: ? 25. Project: Restructure Drivers Description: Restructure the drivers to have more common code. Motivation: Reduced maintenance due to fewer lines of class or port specific code, which usually ends up being mastered by only one or two people in the group; they become the reference for that code, not only making them bottlenecks for maintenance of the code but also keeping them from being able to work as effectively on other code; unique code also increases the documentation burden. Drawbacks/Limitations: ? Cost: ? 26. Project: Queue Manager Description: Get rid of the Queue Manager for those port drivers which do not require it. Motivation: Simplified code, improved performance for those ports which do not need the Queue Manager. Drawbacks/Limitations: ? Cost: ? Page 9 27. Project: High-Risk SCSI Features Description: Identify high-risk SCSI features and ensure that there is an easy run-time way to disable them both for single devices and across all devices on a bus; these features should not be enabled until after a boot-time check has ensured that the device class, type and firmware revision are not known trouble-makers. Motivation: Prevent problems like the one Sue had with the scanner in Spain, or the many instances of problems we've had with devices that don't really do 10 byte Mode Sense correctly. Drawbacks/Limitations: ? Cost: ? 28. Project: Provide Support For > 64KB Transfers at Port Level Description: Modify the port drivers for those ports for which hardware will support it to handle transfers greater than 64KB. Motivation: If we can get to 256KB this will allow us to do firmware updates to some of the older devices in the field; I think that newer firmware will support segmented firmware downloads so it's less an issue for them. There may obviously also be some performance benefit in this. Drawbacks/Limitations: ? Cost: ? ================================================================================ Note 65.0 Prioritized Project Lists 4 replies EVMS::RLORD "Rick Lord" 59 lines 7-NOV-1995 12:55 -------------------------------------------------------------------------------- 1) Maintainability - what does this project contribute to the increase of SCSI code base maintainability? This doesn't mean just the number of problems it might eliminate or prevent, but also whether or not the project makes the code easier to read and follow - that could mean anything from documenting modules to going through and making sure that comments are sufficient and accurate, a consistent coding style is used, etc. 2) Extensibility - what does this project contribute to making it easier to add new functionality to the SCSI code base? Poorly or inaccurately commented code that's hard to read and follow is hard to modify, but so is code that's well documented and commented but which relies on knowledge of how global data is "really" used to get something done, or code in which single data cells are used for more than one thing. 3) New functionality - what are the most important new features to get into the code? 4) Maintenance history - related to but different than maintainability. For instance, if we determine that DKDRIVER has been the the most problematic component of the subsystem then it may make sense to target DKDRIVER for more maintainability work than other components, but there may be other maintainability work that cuts across modules and so offers a bigger improvement in maintainability. 5) Schedule - once the magnitude of each project is somewhat defined, consider using release schedules to select or reject projects - if the projects which are going to have the biggest impact are going to be impossible to get into the next release then it's probably a good idea to look at smaller projects. I think it's important that we contribute something to every release. I broke them down as they were listed into either Maintainability or New Functionality projects and prioritized them as follows. I admit that I'm biased towards getting things into the code that are going to make it easier to find and fix problems - this is because I think that the goal of eliminating or preventing problems is longer term, requiring redesigns, big data structure changes, code reviews, major documentation efforts, etc. Maintainability: New Features: o Documentation o Big IDs and LUNs o Quick & Dirty o Skip Files o Error Logging o Big Transfers o Driver Diagnostics o SCSI Command Error Recovery o Control Interface o Bus Resets o Data Structure Cleanup o Cancel I/O o Maintenance Interface o Target Mode o Utility Applications o Power Management o Device-Specific Code o Queue Manager o High-Risk SCSI Features o Flow Control o Mount Verification Support o AEN o Shadowing Support o SDTR & Fast SCSI o WDTR (16 or 32 bits) o SCSI Commands o Restructure Drivers o Memory Management ================================================================================ Note 65.1 Prioritized Project Lists 1 of 4 STAR::DJBROWN "Have you hugged your system disk today?" 48 lines 7-NOV-1995 17:17 -< My top four >- -------------------------------------------------------------------------------- Since I have no experience maintaining the code, most of my focus is on projects that improve extensibility and add functionality. Here are my top-priority projects, in order. #2 Maintenance interface We should provide a supported method (such as IO$_DIAGNOSE) for issuing generic SCSI commands. The benefits include faster reproduction of problem reports, and do-it-yourself support of power management (project #12), by letting customers modify the appropriate mode page(s). This project would also provide a foundation for project #20, Utility Applications. A few words about what the interface should look like: In the PC world, the standard interface for issuing SCSI commands is ASPI. It includes routines to execute arbitrary commands, abort commands, reset the bus, return information about SCSI adapters and devices, and set host-adapter parameters. A full ASPI implementation would cover most of project #5, possibly excluding the ring-buffer handling. Even a subset of ASPI would be very useful, though. #1 Big IDs and LUNs I expect that customers will ask for access to all 16 IDs on a wide SCSI bus, and that the customers who buy the most equipment will ask the loudest. I also expect the sales force to ask for it, so they can configure systems with more storage. The argument for 128 IDs, to support SSA or FibreChannel, is not quite as strong. The primary need is for a port driver, delivered fully featured and on time. If the driver is months late because the source code has poor extensibility, then it won't much matter how many IDs it supports. #22 Quick & Dirty This project may give more bang for the buck than any other. #18 Device-Specific Treatment Actually, the priority should go toward a registry, which would define capabilities for generic devices and specific devices in a customer-modifiable format. The purpose is to improve our ability to handle random SCSI devices. Embedding device-specific information in the drivers at compile time should be a non-goal. ================================================================================ Note 65.2 Prioritized Project Lists 2 of 4 STAR::TGOODWIN 120 lines 8-NOV-1995 09:42 -< My perspective of the SCSI project list >- -------------------------------------------------------------------------------- WARNING: This note is formatted for 80 columns. The following is my assessment of whether each of the following projects, as described by Rick in Note 64.1, will address: (1) maintenance problem areas; (2) improving maintainability; (3) improving extensibility; (4) adding new functionality. In addition, the schedule column has an assignment from 1-4 which I will explain following the chart. Project |Problem|Improve|Improve| New | Sched. | Areas | Maint | Exten | Funct | ----------------------------------------+-------+-------+-------+-------+------- Big IDs and LUNs | | | | X | 1 Maintenance Interface (IO$_DIAGNOSE) | | X | | | 2 Mount Verification Support | X | X | | | 3 Shadowing Support | | X | | | 3 Control Interface (IO$_SExMODE) | | X | | | 2 ----------------------------------------+-------+-------+-------+-------+------- SDTR & Fast SCSI | | X | | | 1 WDTR (16 or 32 bits) | | X | | | 1 Bus Resets | X | X | | | 3 SCSI Commands | | X | X | | 3 AEN | | | | X | 4 ----------------------------------------+-------+-------+-------+-------+------- Target Mode | | | X | X | 4 Power Management | X | X | | X | 1 Cancel I/O | | X | | X | 3 Error Logging | | X | | | 3 Flow Control | X | X | | | 3 ----------------------------------------+-------+-------+-------+-------+------- Memory Management | | X | | | 2 Skip Files | | | | X | 1 Device-Specific Treatment | X | X | X | X | 4 Driver Diagnostics | | X | | | 2 Utility Applications | X | X | | X | 2 ----------------------------------------+-------+-------+-------+-------+------- Documentation | | X | X | | 1,2,3 Quick & Dirty | X | X | | | 1 SCSI Command Error Recovery | | X | | X | 3 Data Structure Cleanup | | X | | | 2 Restructure Drivers | | X | | | 3 ----------------------------------------+-------+-------+-------+-------+------- Queue Manager | | X | | | 4 High-Risk SCSI Features | X | X | | | 2 Support For > 64KB Port Transfers | | X | | | 2 ----------------------------------------+-------+-------+-------+-------+------- Schedule -------- I have tried to organize these projects into logic groupings and assign them to one of three releases. The numbers 1,2 & 3 in the chart above represent the GRYPHON, post-GRYPHON and post-post-GRYPHON releases respectively. The number 4 represents projects which I could not assign to a release grouping for one reason or another. A schedule assignment of 4 does not indicate that I feel this is a low priority. #1 - GRYPHON projects --------------------- High Priority New Functionality - Big IDs and LUNs - Power Management - Skip Files SCSI Clusters Maintenance Issues - SDTR & Fast SCSI - WDTR (16 or 32 bits) General Code Improvements - Quick & Dirty SCSI Documentation - Documentation - Phase I #2 - Post-GRYPHON ----------------- SCSI Control & Maintenance I/Fs - Maintenance Interface (IO$_DIAGNOSE) - Control Interface (IO$_SExMODE) - Driver Diagnostics - Utility Applications - High-Risk SCSI Features - Support For > 64KB Port Transfers Other Projects - Memory Management - Data Structure Cleanup SCSI Documentation - Documentation - Phase II #3 - Post-Post-GRYPHON ---------------------- Error Recovery - Mount Verification Support - Shadowing Support - Bus Resets - Cancel I/O - Error Logging - SCSI Command Error Recovery Common Code Base - SCSI Commands - Restructure Drivers SCSI Documentation - Documentation - Phase III #4 - No Targeted Release ------------------------ - AEN/Target Mode Let customer needs determine the priority of this new functionality. - Device-Specific Treatment Proper implementation requires an available registry. - Queue Manager Little benefit in removing it from any of the current port drivers, let the development of a new port driver which doesn't require a queue manager drive the need for this project. As always, these are just my options and are subject to change without notice. ================================================================================ Note 65.3 Prioritized Project Lists 3 of 4 VMSRMS::GWANG 61 lines 8-NOV-1995 10:32 -< My choice of projects for V7.2 >- -------------------------------------------------------------------------------- I divided the 28 projects from note 64.0 below by their nature of "why they were listed" based on their description in note 64.1. For example, every project listed under Maintainability is of some problematic nature that does not fit into proactive maintenance requirement. For most tasks listed under Extensibility, they do not take new code from the beginning to the end, but it adds new functions. Yet, some calls for the re-architecture of drivers (eg. Restructure Drivers, SCSI command, ...), [We can never get away from re-architecture the subsystem, aren't we?] others are new enhancements to suppport VMS. Other than the three categories, I don't bother to list any project under "schedule" because its knowledge is not totally within or controlled by our group. Similarly, I don't vote on new SCSI functions for I believe that our management already spoken for V7.2 release and there is no need to go beyond V7.2 now. Maintainability Extensibility New SCSI Support o Documentation o Big IDs and LUNs o AEN o Quick & Dirty o Skip Files o Target Mode o Error Logging o Big Transfers o WDTR (16 or 32 bits) o SCSI Command Error Recovery o Driver Diagnostics o Flow Control o Restructure Drivers o Data Structure Cleanup o Cancel I/O o High-Risk SCSI Features o Device-Specific Code o Bus Resets o Mount Verification Support o SDTR & Fast SCSI o Maintenance Interface o Memory Management o Control Interface o Queue Manager o Utility Applications o Shadowing Support o Power Management o SCSI Commands The fact of not having a completed or published subsystem architecture in hand now prevent me from considering any major project that requires an overall architecture plan. Therefore, my criteria for picking projects are: (1) works seem mostly needed to satisfy the current and near-future customer demand and support; (2) works to correct wrongfully or incompletely coded current functions. In the Maintainability group, my priorities are: SDTR & Fast SCSI High-Risk SCSI Features Bus Resets In the Extensibility group, my priorities are: Big IDs and LUNs Maintenance Interface--+ Control Interface | These 4 are closely related and much needed Utility Applications | to support 3rd-party devices. I would combine Driver Diagnostics-----+ them into one project. ================================================================================ Note 65.4 Prioritized Project Lists 4 of 4 STAR::RITTER 34 lines 8-NOV-1995 10:49 -< prioritized list of projects >- -------------------------------------------------------------------------------- I worked through this list trying to order things a level at a time. This is the sorted list that I ended up with. (I used Rick's original list as a starting point). m means maintnence projects m111 21. Project: Documentation m112 24. Project: Data Structure Cleanup (ie access rules defined) m113 19. Project: Driver Diagnostics m121 14. Project: Error Logging m122 20. Project: Utility Applications m131 6. Project: SDTR & Fast SCSI m132 5. Project: Control Interface (IO$_SExMODE or similiar) m21 8. Project: Bus Resets m22 16. Project: Memory Management m23 4. Project: Shadowing Support m24 3. Project: Mount Verification Support m25 15. Project: Flow Control m31 2. Project: Maintenance Interface (IO$_DIAGNOSE) m32 9. Project: SCSI Commands m32 18. Project: Device-Specific (Device-Class+Device-Type+Firmware) Treatment m32 23. Project: SCSI Command Error Recovery m32 25. Project: Restructure Drivers m32 26. Project: Queue Manager n means new functionality n11 1. Project: Big IDs and LUNs n11 7. Project: WDTR (16 or 32 bits) n11 11. Project: Target Mode n12 12. Project: Power Management n12 *22. Project: Quick & Dirty n2 10. Project: AEN n2 17. Project: Skip Files n2 27. Project: High-Risk SCSI Features n2 28. Project: Provide Support For > 64KB Transfers at Port Level n3 13. Project: Cancel I/O