Date: Wed, 27 May 1998 20:29:57 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: hans@artcom.de Cc: gibbs@pluto.plutotech.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Tape driver - What do we really want? Message-ID: <199805280229.UAA08222@panzer.plutotech.com> In-Reply-To: <Pine.BSF.3.96.980522005229.8858A-100000@transrapid.artcom.de> from Hans Huebner at "May 22, 98 02:29:17 am"
next in thread | previous in thread | raw e-mail | index | archive | help
[ I've been inexcusably lazy in replying to this... ] Hans Huebner wrote... > Kenneth D. Merry wrote: > > Hans Huebner wrote... > > > > * Implement MTIOCGET fully > > > > We might want to have two versions of the > > MTIOCGET ioctl -- one with all the bells and whistles (i.e. density, > > compression, etc.) and one that uses the "traditional" structure that other > > machines accessing a FreeBSD box via the rmt protocol would understand. > > The "traditional" structure does provide for sending current position > > information, though. > > I am not sure whether the current rmt protocol is used at all. The mtget > structure is directly passed between the rmt client and server, which > makes the protocol non-interoperable between platforms. The system itself > does not use the mtget structure except in mt(1), all other references to > MTIOCGET seem to not use the returned data. > > I can't see what other applications do, but I suspect that nobody really > uses the mtget structure. Please correct me if I'm wrong. You're probably right. > > > * Create 'mt capabilities' command > > > > > > The permissible compression modes should be printable with a new > > > subcommand to mt, maybe 'capabilities'. Along the way, the permissible > > > modes of the tape should be made a list (contrasted to the four-mode > > > scheme we currently have). > > > > Right. If we're going to have a list of things, we should make it > > dynamic, not a fixed size. > > I'd even propose to pull the model- and vendor-specific driver > initialization out of the kernel into a user mode application. Basically, > this seems to require a get/set ioctl interface to the quirks of a device. > This will require documentation and review of quirks usage in the driver. > > The user-mode application would use standard CAM calls to access the mode > pages of the drive as well as on-disk configuration information to > determine the permissible modes and set up the driver-internal mode > configuration table or list. > > The default configuration should be sane enough to restore common tape > formats without having to perform elaborate initialization upon the > device, though. This is what we already have. Well, I would rather have the kernel automatically setup known drives. For unknown drives, or to override the kernel defaults, we could have some sort of config file or options to mt to setup various quirks or register capabilities for the device. What I want to avoid is the situation that you need to run mt or some other program in order for the driver to run optimally with the device. It would be acceptible to have to run mt to set quirks/capabilities if the drive in question is unknown to the kernel, but once we know enough about it, the device's capabilities and quirks should go into the kernel database. Another thing I would like to avoid is having mt groking through the passthrough driver and mode pages. mt is more of a generic magnetic tape interface, and so needs to be extensible to IDE and floppy based tape drives. > > > * Make mt work with remote tape drives > > > > > > The mt command should work with remote tape drives to the extent that the > > > rmt protocol allows. This is needed to support media changer servers > > > which, through a custom protocol, mount tapes at the request of > > > applications running on other systems in the network. > > > > Sounds interesting...but if the media changer servers in question > > use a custom protocol, how is adding rmt support to mt going to help? > > It would save me from having to implement a special mt-type utility to > remotely work with a tape drive. The changer protocol is only concerned > with media and drives, not with the data contained on the media. I see. Well, maybe what you could do is have device specific routines in separate files that are linked into mt. Then, based on a command line option mt would call the device-specific routines to formulate the rmt protocol commands to send to the remote device. > I'm well aware about the limitations of the rmt protocol. In practice, > using it to transfer data from or to a remote tape drive is often avoided > in favour of a transparent tcp data channel (e.g. rsh, ssh). It could be > useful for remote control, though (if mt would support remote tape > drives). Yeah, I can see how that would be cool. Something like: mt -f ken@hostname:/dev/nrsa0 fsf 2 I take it that's what you're talking about? Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805280229.UAA08222>