Date: Fri, 23 Apr 2010 23:00:52 +0300 From: Andriy Gapon <avg@freebsd.org> To: "Kenneth D. Merry" <ken@freebsd.org> Cc: freebsd-scsi@freebsd.org Subject: Re: cam.3: do not discourage use of cam_open_device Message-ID: <4BD1FC74.3090504@freebsd.org> In-Reply-To: <20100423184412.GA5016@nargothrond.kdm.org> References: <4BCDEBF6.3030609@icyb.net.ua> <20100423184412.GA5016@nargothrond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BD1FC74.3090504>