> > "control open" - Already on my list. > > > > "mt_fileno/mt_blkno" - I'm mulling that one. Yes, I think I will, but > > it'll take a lot of work because there are (now) a large number of > > conditions that invalidate and make completely unknown those > > relative positions (EOD, hard block locating). > > > > "current state" - Interesting notion. > > My motivation for wanting these things is that I have a program >....
All three items are to be integrated today. There will be a control open device that allows you to open the device to retrieve stats (even if another application has the device open). You can (try) and set block size and density and compression via the control device open, but you'll pin (interruptibly) waiting for access to the device if another application has it open. There already is an Error Stats ioctl that is different from the regular MTIOCGET. The mt_fileno/mt_blkno will go in. Hopefully I'll have caught all the spots, but I will document in the man page that this information is not definitive. The only definitive information about tape position is BOT, End of Recorded Media and hardware block position (if supported by the drive). Current state will now be loaded int mt_dsreg. There will be some FreeBSD specific defines as to what the tape driver thinks that it is doing. mt(1) will be modified to print out the latter two items. After this point I plan to start development on using the HP TapeAlert initiative's rulesets for new tape behaviour. That should leverage FreeBSD into a number of markets. -matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
