home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / sgi / 16050 < prev    next >
Encoding:
Text File  |  1992-11-06  |  2.8 KB  |  58 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sun-barr!ames!sgi!fido!zola!zuni!anchor!olson
  3. From: olson@anchor.esd.sgi.com (Dave Olson)
  4. Subject: Re: MTIOCTOP w/ MT_NOP does not update mt_dsposn, shouldn't it???
  5. Message-ID: <s0lhhh8@zuni.esd.sgi.com>
  6. Sender: news@zuni.esd.sgi.com (Net News)
  7. Organization:  Silicon Graphics, Inc.  Mountain View, CA
  8. References: <fish.720998046@news2.gsfc.nasa.gov>
  9. Date: Fri, 6 Nov 92 03:26:26 GMT
  10. Lines: 46
  11.  
  12. In <fish.720998046@news2.gsfc.nasa.gov> fish@daacdev1.stx.com writes:
  13. | this is w/ irix 4.0.1 on a 4D/440S using jaguar controllers to a 8mm
  14. | 
  15. | i am trying to loop until i can detect a tape is loaded in a drive
  16. | via MTIOCGET using the mt_dposn MT_ONL bit - that works fine if there
  17. | is a tape in the drive before i do the open but if it gets put in later
  18. | (which is really the whole point of what i'm trying to do)
  19. | i then issue another ioctl GET to ascertain if its status has changed.
  20. | since that wasn't working i saw that the CTOP MT_NOP option states that
  21. | it does "no operation, sets status only" - so i stuck that in there 
  22. | and that didn't do anything either - what does it do?? only update
  23. | the mt_dsreg element and not the mt_dposn element?
  24.  
  25. MT_NOP is just that, a no op.  It is *completely* ignored (in all of
  26. our tape drivers).  All it tells you is that you are in fact talking
  27. to a tape driver, rather than some other kind of device (if you don't
  28. get an error).
  29.  
  30. MTIOCGET just returns the current info, it does nothing to the
  31. tape drive for the jagtape driver.  I had enough complaints about
  32. this and similar things, that for the tpsc driver, if the tape
  33. wasn't loaded, I loaded it, which updated all the position info.
  34.  
  35. In a future release, there will be only one scsi tape driver (talking
  36. to multiple chip drivers), so they will be consistent.  In this case,
  37. it will follow the tpsc model.
  38.  
  39. | i had to resort to reopening the file every time i check in the loop
  40. | (by closing and then opening again) and this works (but has the
  41. | unfortunate side-effect of having the jag driver repeatedly log
  42. | "BUSY, waiting" while the tape is loading and the open() is pending
  43. | 
  44. | i haven't tried this with the tpsc driver yet but i'll need to soon
  45.  
  46. The tpsc driver will load the tape on the MTIOCGET, if it wasn't already
  47. loaded.  The jag drives also tend to be a bit more verbose about
  48. issuing messages.
  49.  
  50. A *very quick* (and therefore possibly wrong) inspection of the jagtape
  51. driver makes it appear to me that the only way to do what you want with
  52. the jagtape driver is to do exactly what you are doing, close, and then
  53. re-open the drive.
  54. --
  55. Let no one tell me that silence gives consent,  |   Dave Olson
  56. because whoever is silent dissents.             |   Silicon Graphics, Inc.
  57.     Maria Isabel Barreno                        |   olson@sgi.com
  58.