Date: Fri, 19 Jun 1998 18:47:10 -0700 (PDT) From: dan@math.berkeley.edu (Dan Strick) To: ken@plutotech.com Cc: dan@math.berkeley.edu, freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? Message-ID: <199806200147.SAA01444@math.berkeley.edu>
next in thread | raw e-mail | index | archive | help
> 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. > - 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. > - 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. 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. 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? 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). (As mentioned above, tape may be a special case. Tape drivers might make read/write operations wait when there is tape motion such as rewind or load in progress. A special control device might be useful to allow status requests and such when the drive is already busy.) Dan Strick dan@math.berkeley.edu 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?199806200147.SAA01444>