Date: Sat, 20 Jun 1998 21:19:38 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: dan@math.berkeley.edu (Dan Strick) Cc: ken@plutotech.com, dan@math.berkeley.edu, freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? Message-ID: <199806210319.VAA20588@panzer.plutotech.com> In-Reply-To: <199806200147.SAA01444@math.berkeley.edu> from Dan Strick at "Jun 19, 98 06:47:10 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Strick wrote... > > Right, that's what I'm interested in. I talked to Julian this > > morning (in person, actually!) and that's the question I had. So I'll say > > it so everyone can see: > > > > - How many more programs use this (scsireq) interface? > > I recently ported a rather useful general scsi device utility program to > FreeBSD. It slices, dices, and knows a great deal about mode parameter > pages. What's the name of the program? Is there a URL? I'd like to have a look at it, see what it does and see how difficult it would be to port it. Does it do things that camcontrol doesn't? > > - Are people going to yell and scream loudly if it goes away when CAM > > is integrated into the tree?? > > Not if we have a reasonable alternative. It would be nice if both > interfaces worked side-by-side for a while to facilitate migration. > It would also be nice if the new scsi passthrough ioctl() was documented. > I had a little difficulty with SCIOCCOMMAND. I certainly agree that the current interface needs to be documented. I think the current libcam is a good alternative to the old libscsi library. You should be able to do all of the same things, including using the old command string format to do cdbs. (that's with the latest version of the library, which isn't "out" in a snapshot yet) Before I (or someone else) go hacking through things to add in support for the old passthrough interface, I really would like to know the scope of the porting problem. You're the first person (other than Julian and Poul-Henning, who said something vague about some internal program at TFS) that's mentioned any program other than the ones I know about that needs to be ported. We can provide backwards compatibility, but if it goes away in say FreeBSD 3.1 or 4.0, people may still scream, since they never noticed that the interface was "deprecated." > > - the problem is that with the old SCSI code, to send SCSI commands > > directly to a device, you opened the device itself (/dev/rcd0a or > > whatever) and did the SCIOCCOMMAND ioctl on that device. CAM does > > things differently, primarily because users may want to send > > commands to device, even though the device's open() routine may > > fail. For instance, you can't open a CD device if there is no > > media inserted. But the user may want to send an INQUIRY command > > to the drive, whether or not there's a CD in the drive. So, to > > solve this, you have two choices: (that I can think of offhand) > > - have a special control minor number for each device, and > > have the open call ignore failures in read capacity, test > > unit ready, etc. > > - have a separate passthrough driver that doesn't have to > > have any commands succeed to attach or open. > > A special control device is important if the regular device is > exclusive-open or touching it may affect the status of the device > (example: tape) but I don't think a control device should be used > to solve the open-failure problem. Right. > A second approach might be to add a special open() flag to the fcntl.h > repertoire. Sun uses O_NDELAY for this purpose. I don't much like > this either. It seems like an unnecessary complication to me. You might as well open the control device, the code would be similar. > I think the open-failure problem is best solved by not creating it in the > first place. This is a totally artificial problem. Let the drivers allow > the open() even if the device it not ready. The system calls that should > fail if the device is not ready are read() and write(). Why should > open() fail? What existing application programs are broken by this > approach? I'm not sure what applications would be broken. The current passthrough driver approach fixes the open() problem already. It doesn't depend on the device returning *any* commands successfully to complete. That was a major reason for doing a separate passthrough driver with different open() requirements than the "normal" peripheral drivers. > We might define a special file for the controller itself. > It could be used for non-device-specific operations (e.g. bus or controller > reset) or truly general SCSI passthrough (you specify the bus-id and the lun). Well, actually, we have something like that already in CAM. There's the transport layer device (/dev/[r]xpt[n]). That's how you send bus rescans, and a few other commands. It also provides mapping from device type / unit number to the correct passthrough driver. 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?199806210319.VAA20588>