Date: Mon, 22 Jun 1998 06:59:22 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: ken@plutotech.com (Kenneth D. Merry) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? Message-ID: <199806221059.GAA00230@hda.hda.com> In-Reply-To: <199806220440.WAA25738@panzer.plutotech.com> from "Kenneth D. Merry" at "Jun 21, 98 10:40:50 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <options> [ 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 <bus[:target:lun]> > 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 <b[:t:l]>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 > -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval 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?199806221059.GAA00230>