home *** CD-ROM | disk | FTP | other *** search
/ Amiga Developer CD 2.1 / Amiga Developer CD v2.1.iso / DevInfo / DeviceDevelopment / NSD-Thoughts < prev    next >
Encoding:
Text File  |  1997-05-15  |  6.2 KB  |  124 lines
  1.  
  2.     $Id: NSD-Thoughts 1.4 1997/05/15 18:09:27 heinz Exp $
  3.  
  4.  
  5. Thoughts & Consequences
  6. =======================
  7.  
  8. This chapter may count as a set of annotations to NSD. It
  9. should shed some light on certain decisions and the consequences
  10. for users and implementors of NSD devices.
  11.  
  12. You may have noticed that there isn't a device type for SCSI or
  13. narrator. This is intentional. There is no NSD narrator right now
  14. and it is probably unwise to rely on the interface of the old
  15. narrator. A scsi device is typically a logical superset of
  16. trackdisk functionality and, for non disk devices relying only on
  17. HD_SCSICMD, a subset of scsi.device, which in turn classifies as
  18. trackdisk like. So in some way simple trackdisk functionality is
  19. the common base. It is also expected that any user visible
  20. difference between a SCSI like device and a trackdisk like device
  21. will tend to disappear. So SCSI and trackdisk like device have been
  22. put under the common label of NSDEVTYPE_TRACKDISK. The CD 32
  23. cd.device is also a trackdisk like device within this meaning.
  24.  
  25. IOERR_NOCMD support is a design basis for NSD. Actually, support of
  26. IOERR_NOCMD is _the_ design basis for NSD. There are very few very
  27. broken devices out there which don't even support IOERR_NOCMD
  28. correctly and simply crash on unknown commands. These are not
  29. supported under NSD, and some kind of patch or "wrapper device" is
  30. needed for them to avoid a crash with a NSD using application. This
  31. was expected when NSD was designed, and based on the saying "the
  32. needs of the many outweigh the needs of the few", it was accepted
  33. that NSD cannot be safe for absolutely every single device in
  34. existance.
  35.  
  36. Another design basis for NSD is mentioned in the RKM Libraries, 3rd
  37. edtion on page 445:
  38.  
  39.     The philosophy behind the devices is that I/O operations should
  40.     be consistent and uniform.
  41.  
  42. This means that many commands like CMD_WRITE have similar
  43. functionality among very different types of devices. The
  44. philosophy is reflected by the general reserved command area and
  45. the general query command. This philosophy also extends to the
  46. meaning of IOERR_NOCMD which is described in <exec/errors.h> and
  47. referred to on page 924 of the RKM Libraries, 3rd edition.
  48. IOERR_NOCMD should be returned consistently for unsupported, i.e.
  49. unimplemented commands by the device. This means that it is not an
  50. acceptable error value for commands that are in fact supported by
  51. the device, but can't be executed correctly currently, because of
  52. limitations of the currently set up underlying hardware or
  53. configuration. It is only acceptable as error value if the
  54. respective command will never ever at any time under any
  55. circumstance be available.
  56.  
  57. A basic problem exists with old style SANA devices. They tweak the
  58. OpenDevice() usage by passing in parameters via the request. The
  59. RKM Libraries 3rd edition, page 447, says:
  60.  
  61.     In addition to establishing the link to the device,
  62.     OpenDevice() also initializes fields in the I/O request.
  63.  
  64. Passing in configuration data via an "uninitialized" request on
  65. OpenDevice() is therefore somewhat special and unusual. This is
  66. considered a design flaw in the SANA specification as it breaks the
  67. uniformness of device access. So SANA devices can put a monkey
  68. wrench into the NSD system and this lead to the "safer assumptions"
  69. kludge. NSD is based on the assumption that devices can be
  70. "probed", so a general query on a SANA device may not return what
  71. you expect. Unless absolutely required by the original device
  72. specification, it is unwise to pass in configuration information on
  73. OpenDevice() within the NSD framework. For a SANA-device you would
  74. have to close it after the query and reopen it with the correct
  75. configuration data to be able to use it, if you don't pass in the
  76. configuration information right away. This leaves an access hole
  77. that isn't there for other types of devices. 3rd party devices
  78. needing this feature for 3rd party functionality should better use
  79. a configuration command to set parameters. For device specific
  80. usage of an NSD device, this isn't really a problem as you expect
  81. to get the right device type on OpenDevice(), which should be OK
  82. except for pathological cases. A query is mainly a verification of
  83. the required feature set here, so the risk is minimal. In general,
  84. it is an issue to think about, though.
  85.  
  86. The mn_Length check has been originally introduced into NSD to make
  87. use of a device safer. The easiest check is for the minimum
  88. required request size in OpenDevice(). This will catch basic
  89. programming errors and, in the worst case, only make OpenDevice()
  90. fail, rather than make the computer crash in unexpected ways.
  91. Refusal to open is deemed better than definitely overwriting or
  92. referencing garbage memory.
  93.  
  94. An exact check for mn_Length is very unwise and cannot be
  95. recommended, as a user may decide to use an extended IORequest with
  96. some additional user private fields. It would also be a fairly
  97. simple improvement to add mn_Length checks to all individual
  98. commands in the device. The overhead of a simple compare can
  99. typically be neglected, and the device can make sure that the size
  100. of the request is acceptable for the specific command. This would
  101. be of additional help for devices which support different sizes of
  102. IORequests for different commands.
  103.  
  104. Be aware that the minimum required request size on OpenDevice() may
  105. be less than what the commands need. So design the mn_Length check
  106. in OpenDevice() carefully to include the most error checking
  107. possible right there without keeping the device from opening. Don't
  108. forget that a general NSCMD_DEVICEQUERY must be possible, too, even
  109. if the device itself does use completely different request sizes.
  110. Note also that early NSD using software may use just a simple
  111. struct IOStdReq for the general query. As you can see by now,
  112. checking mn_Length for each command is not a bad idea, either.
  113.  
  114. Validating mn_Length is a very simple way to catch fundamental but
  115. obscure errors to avoid a system crash. There will always be a
  116. pathological case that cannot reasonably be caught like special
  117. broken parameter settings, but simple validations like an mn_Length
  118. check make device access a lot safer. Along these lines, other
  119. fields, like io_Unit, of a request could be validated. If a device
  120. can easily check for broken user SW, it should do so and return
  121. decent error values instead of crashing the system.
  122.  
  123. *** EOT ***
  124.