From owner-freebsd-scsi@FreeBSD.ORG Fri Apr 23 20:00:56 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5CA2106566C for ; Fri, 23 Apr 2010 20:00:56 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9B6B38FC0A for ; Fri, 23 Apr 2010 20:00:55 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA12344; Fri, 23 Apr 2010 23:00:54 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1O5P3V-000CZl-Id; Fri, 23 Apr 2010 23:00:53 +0300 Message-ID: <4BD1FC74.3090504@freebsd.org> Date: Fri, 23 Apr 2010 23:00:52 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: "Kenneth D. Merry" References: <4BCDEBF6.3030609@icyb.net.ua> <20100423184412.GA5016@nargothrond.kdm.org> In-Reply-To: <20100423184412.GA5016@nargothrond.kdm.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: cam.3: do not discourage use of cam_open_device X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 20:00:56 -0000 on 23/04/2010 21:44 Kenneth D. Merry said the following: > On Tue, Apr 20, 2010 at 21:01:26 +0300, Andriy Gapon wrote: >> This is based on my understanding what Scott Long tried to explain me a while ago. >> >> Index: lib/libcam/cam.3 >> =================================================================== >> --- lib/libcam/cam.3 (revision 206902) >> +++ lib/libcam/cam.3 (working copy) >> @@ -190,12 +190,6 @@ >> Once the device name and unit number >> are determined, a lookup is performed to determine the passthrough device >> that corresponds to the given device. >> -.Fn cam_open_device >> -is rather simple to use, but it is not really suitable for general use >> -because its behavior is not necessarily deterministic. >> -Programmers writing >> -new applications should make the extra effort to use one of the other open >> -routines documented below. >> .Pp >> .Fn cam_open_spec_device >> opens the >> >> >> It seems that this warning about ambiguity came from pre-devfs days when e.g. cd0 >> nodes in different directories could correspond to different actual SCSI >> peripherals. It seems that there wasn't an ambiguity if an absolute device path >> was given. >> >> Nowadays, cam_open_device seems to always do a proper job of finding a correct >> pass device. > > The warning had more to do with the ambiguity trying to make sense of > device names than having different device nodes lying around. > > cam_get_device() (which is called by cam_open_device()) tries to do > some things that will break on devices that start with n (unless it's a > non-rewound tape device) or r. Right now we don't have any CAM peripheral > drivers that start with those letters, so it works. It also won't do the > right thing on devices with gpt partitions. Some of that can be fixed, > though. > > So it's mostly deterministic, but it may not do exactly what you expect. > > It may be good to keep some statement in there pointing people to the other > routines as being preferred because they're a little more deterministic. These are very valid concerns. I was aware that we ditched "r" (raw) devices quite a while ago, but wasn't sure about "n" kind as I have never dealt with tapes in my life. Perhaps we can just remove that code now? Also, from my point of view, it doesn't make any sense to support cam_open_device() calls on slices, partitions, etc. I mean, what is a passthough device for a slice of disk? Can you send SCSI commands to a slice? All these comes from my (limited) practical experience with some userland applications where people were afraid to use cam_open_device() because of the warning in question. So they went out of the way to "manually" establish mapping from an original device name to a corresponding passthough device. So, I'd like to let people know that it's totally OK to use cam_open_device() with "normal" device names. I don't care about the extra logic ("r", "n" prefixes; partition/slice suffixes). But that's only my point of view. And thank you for the explanation! -- Andriy Gapon