From owner-freebsd-scsi Sun Jun 21 21:41:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA10552 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 21:41:04 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA10539 for ; Sun, 21 Jun 1998 21:40:59 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id WAA25738; Sun, 21 Jun 1998 22:40:51 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806220440.WAA25738@panzer.plutotech.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806212315.TAA28473@hda.hda.com> from Peter Dufault at "Jun 21, 98 07:15:33 pm" To: dufault@hda.com (Peter Dufault) Date: Sun, 21 Jun 1998 22:40:50 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Dufault wrote... > > > I don't know where it is archived now. There wasn't much interest > > > in this the last time I showed it around. > > > > Well, I would be interested in taking a look at it. I may be able > > to incorporate some of the ideas/features into the CAM userland stuff. > > It is at least in my home directory on freefall, and is someplace > else. I've lost track of what the incoming elves do to files > uploaded to incoming. I poked around on the FreeBSD home page and didn't > find out. If you don't see it I can upload another copy. I don't have an account on freefall, and I don't see it in the incoming directory. Could you upload it again? > > I've already incorporated the buffer parsing code from libscsi into libcam, > > and I've put the mode page editing code from scsi(8) into camcontrol. > > (neither is in the currently released snapshot, but both will be in the > > next snapshot) > > Good - then you may like the newer stuff. I didn't incorporate > it into scsi(8) because I didn't want an sbin binary to grow. I don't > know what your plans are for camcontrol, however, you'll probably > want to keep the sbin-ness in mind. The server ability would be > good even for a program in sbin to support remote support on some > sort of embedded scsi device. Hmm, yeah, I'll have to keep the size in mind. The current version of camcontrol is only about 100K, which is smaller than many of the programs in /sbin. I'll have to take a look at this server capability, it sounds interesting. > > One thing I'll probably do is make hardlinks to camcontrol so that > > there are several different programs you can call, rather than trying to > > remember command line switches that sometimes don't really resemble the > > functions they perform. i.e.: scsi_tur, scsi_start, scsi_stop, > > scsi_read_defects, scsi_inquiry, scsi_cmd, scsi_mode_page, scsi_rescan, and > > so on. > > I don't like this - this boils down to "scsi_tur" versus "scsi tur". Good point. I guess I could just do it that way. Basically, the problem I have now is that camcontrol is starting to get optionitis. I can just continue to use more option letters, or I can try doing something to make it a little more sane. Here's what the current usage statement looks like: usage: camcontrol [ optional args ] camcontrol -l [-n dev_name] [-u unit] camcontrol -t [ optional args ] camcontrol -i [-D] [-S] [-R] [ optional args ] camcontrol -s <0|1> [-j] [ optional args ] camcontrol -r camcontrol -d -f format [-P] [-G] [ optional args ] camcontrol -m page [-p pagectl] [-e] [-B] [ optional args ] camcontrol -c cmd [opt. args] <-I len fmt|-O len fmt [args]> Specify one of the following options: -l list all CAM devices attached to a device -t send a test unit ready to the named device -i send a SCSI inquiry command to the named device -s <0|1> send a Start or Stop Unit command to the device -r rescan the given bus, or bus/target/lun -d read the defect list of the specified device -m page display or edit (-e) the given mode page -c cmd send the given scsi command, needs -I or -O as well Optional arguments: -v be verbose, print out sense information -T timeout command timeout in seconds, overrides default timeout -n dev_name specify device name (default is da) -u unit specify unit number (default is 0) -E have the kernel attempt to perform SCSI error recovery -C count specify the SCSI command retry count (needs -E to work) -e edit the specified mode page (used only with -m) -B disable block descriptors for mode sense (used with -m) -p pgctl page control field 0-3 (used with -m) -j load or eject media -- can only be used with -s -f format specify defect list format (block, bfi or phys) -G get the grown defect list (used only with -d) -P get the permanant defect list (used only with -d) -D get the standard inquiry data (used only with -i) -S get the serial number (can only be used with -i) -R get the transfer rate, etc. (used only with -i) -I fmt specify input data and input data format (used with -c) -O fmt specify output data and output data fmt (used with -c) Fair number of options, 'eh? Maybe what you're saying would work better, i.e.: camcontrol inquiry -S da0 (I may try putting in support for just specifying devices like that instead of -n da -u 0 if I end up re-working the command line options.) A complicating factor to all this is all the arguments for the command line CDB parsing code. > Just to show I'm not a stickler about high level interfaces, I > think that in addition to preserving the current ioctl interface > (which I think should be done) it would be good to support > the Linux SCSI interface thus extending the Linux binary support. That is an option, although I'd have to look at it and see what it would entail. Linux binary support is good, since it allows us to run commercial applications that haven't been ported to FreeBSD. The question is, what sort of application base are we talking about here? Are there lots of binary-only Linux applications (or even just one major application) that need SCSI passthrough support? I'm still not convinced it's absolutely necessary to support even the current ioctl interface, since I haven't really heard of many programs that would be affected. The current list is: cd-write, SANE, and cdd. (cdrecord, tosha and xmcd have been ported) That certainly isn't an insurmountable list, and once those are ported, it'll be a simple matter of rebuilding the port once we switch over to CAM. You say that you think we should support the current ioctl interface. Other folks have said we should support it for one release, and then take it out, and others have said they don't care as long as the new interface is documented. I'm really not opposed to any of these approaches, but I'd like to know why you think we ought to continue to support the current interface. As far as applications go, I haven't seen that there are any really sticky problems so far. I think that supporting the current interface for one release might be a good idea, although people will probably still scream when we remove it in FreeBSD 3.1 or 4.0. Anyway, I'm just trying to get a feel for what your reasoning is. I'm not opposed to doing it, but I haven't really seen a good argument for continuing to support it. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message