Date: Sun, 15 Nov 1998 16:41:17 -0700 (MST) From: "Kenneth D. Merry" <ken@plutotech.com> To: dan@math.berkeley.edu (Dan Strick) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: bug in cam_real_open_device() Message-ID: <199811152341.QAA23512@panzer.plutotech.com> In-Reply-To: <199811151458.GAA26354@math.berkeley.edu> from Dan Strick at "Nov 15, 98 06:58:44 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Strick wrote...
>
> In file: camlib.c,v 1.2 1998/10/12 21:54:00 ken Exp
> beginning at line 587:
>
> if ((fd = open(path, flags)) < 0) {
> sprintf(cam_errbuf, "%s: couldn't open passthrough device %s\n"
> "%s: %s", func_name, newpath, func_name,
> strerror(errno));
> goto crod_bailout;
> }
>
> The bug is that "newpath" hasn't been filled in at this point.
> Another bug is that since the contents of newpath is unknown,
> cam_errbuf might not be large enough (resulting in buffer overflow).
Yep, it's a bug. I just checked in fixes; get version 1.4 of camlib.c
> I feel compelled to express severe irritation with this part of the
> cam design.
[ complaints essentially about using /dev/pass* instead of the 'normal'
device nodes ]
Since Justin covered most of your comments, I'll just say one or two things
here.
> There are a lot of little glitchy consequences of this aspect of the
> cam design. For example, cam_open_device() will fail if the required
> passthrough device has not been created in /dev, but there is currently
> no way for a program using camlib to determine the name of the required
> passthough device until after camlib has successfully opened it.
> (The camlib routines happen not to fill in this cam_device struct
> member until after the open succeeds. There is no camlib routine
> that does just the CAMGETPASSTHRU ioctl(). Since the CAMGETPASSTHRU
> ioctl() is undocumented, using it on the side is not an option.)
> As a consequence, my program cannot produce an error message
> telling the user that he has to create a specific passthrough
> device in /dev. This is a real bummer.
The fact that the CAMGETPASSTHRU ioctl isn't documented is probably a bug.
Just like the fact that none of the CCB types are documented is a bug.
We didn't have time before 3.0 went out to document everything, and we
still don't have much time. (Justin and I are both very busy with "real"
work, which at the moment doesn't include CAM work.)
I think it would probably be better to use the XPT_DEV_MATCH CCB. It
performs device matching functions in a much more general way than the
CAMGETPASSTHRU ioctl. (Which, in retrospect, probably should have been
implemented as another CCB type. I think I had a reason at one point for a
separate ioctl, but I can't remember what it was now.)
As Justin mentioned, the CAM library is just "sugar coating" on top of the
regular ioctls/CCBs. You can use the ioctls directly, if it makes your job
easier. If you want to determine whether the user has the necessary
passthrough device created in /dev, I would suggest doing the following:
- Assuming you have the device name (e.g. "da" or "cd") and unit number of
the device the user wants to talk to:
- send an XPT_DEV_MATCH CCB with the device name and unit number,
and set it up to match against the device name and unit number.
- you will receive the bus, target and lun for that particular
device when the CCB returns.
- now, send another XPT_DEV_MATCH CCB. Specify the bus/target/lun
for the device that you got from the last CCB, and specify the
device name "pass".
- you will receive the unit number for the passthrough device that
you want to open.
You can also just issue the CAMGETPASSTHRU ioctl, which will do the same
thing more or less. There are two different versions of the ioctl, one
that gets called when you go through the transport layer device, and the
other when you go through one of the 'normal' devices.
If you're going to use that ioctl, I would recommend using the one in the
transport layer (/dev/xpt0) device. This is because when you use the one
that's available via the regular devices, you have to go through that
device's open routine. The open routine may not succeed in all cases.
(This gets back to the reason we went with a separate passthrough device as
opposed to integrating the ioctls in the standard device nodes. Justin
covered that pretty well in his mail.)
If you'd like to make a CAM library function that checks for the existence
of a passthrough device for a given "regular" device or bus/target/lun,
feel free to send me the diffs.
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?199811152341.QAA23512>