> Actually you hit on the problem with using mt. Before you can do an ioctl() you have to open() the tape, but before you can open() the tape you have to > allocate it. I don't see how you can use ioctl() to allocate the tape.
Take a peek at "blockdev". It does a similar sort of thing to what I was thinking about. > Perhaps I know too much about how drivers work to see this the way the user would like this to work. Here's how I'd envision it working: At IPL, the Linux guest is informed that it's allowed to use tape addresses 10-20 in the zipl setup. The tape390 driver loads at boot, assumes that the tapes are in "shared" mode (or is told to do so via a parm), builds device entries for those drives, but does not issue ASSIGN CCWs at that time. The drives stay unallocated until someone wants to use one. User issues "mt reserve /dev/mt0" (or whatever device he wants to use). mt signals the device driver that a user has issued the reserve via ioctl(). Driver wakes up, issues the ASSIGN CCW. If successful (meaning the drive is now ours), we return rc=0 to the user and he can start doing his thing. If the assign fails, we issue an error to the user and it's up to him to cope. User reads and writes to his heart's content. User is done with tape and issues "mt release /dev/mt0". mt signals device driver that user released device via ioctl(). Driver wakes up, issues the release CCW. Physical drive goes back into the pool, device entry remains live Another idea I had was that perhaps the solution is for the tape390 driver to produce a psuedodevice (say /dev/mtctl0) for each real tape device that would allow issuing various commands to a underlying control layer (kind of like the extra device that the SCSI tape libraries use for manipulating the changer). If we set up the assumption that every drive is a "library" (single drives are treated as a one-drive changer), the model would work with mt, or with the UTS model, but at the expense of burning more device entries/minor #s. It'd also provide a way to trigger mounts, etc if needed. I don't like this solution very much in that it complicates the model, but it might satisfy some of the objections presented so far. It would also work with the existing Intel stuff (might even make that more general). I guess I don't see why this is so different from some of the "special" functions that mt already has for dealing with SCSI tapes. It's really not all that different semantically than setting the recording density or compression options before you start writing to a tape. Wrt to the unloading/reloading the tape driver, I don't think that losing all the tapes just to change the options on one drive is really an acceptable solution. There needs to be some way to work with individual drives.
