Date: Fri, 22 May 1998 02:29:17 +0200 (CEST) From: Hans Huebner <hans@artcom.de> To: "Kenneth D. Merry" <ken@plutotech.com> Cc: gibbs@pluto.plutotech.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Tape driver - What do we really want? Message-ID: <Pine.BSF.3.96.980522005229.8858A-100000@transrapid.artcom.de> In-Reply-To: <199805212041.OAA05585@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > * 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. > > * 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'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). This is off-topic anyway ;) -Hans 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?Pine.BSF.3.96.980522005229.8858A-100000>