Date: Sun, 21 Jun 1998 22:40:50 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: dufault@hda.com (Peter Dufault) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? Message-ID: <199806220440.WAA25738@panzer.plutotech.com> In-Reply-To: <199806212315.TAA28473@hda.hda.com> from Peter Dufault at "Jun 21, 98 07:15:33 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806220440.WAA25738>