Fwd: Re: cam.3: do not discourage use of cam_open_device

I would like to commit the following proposed changes in about a week.

-------- Original Message --------

Reviving this thread. Sorry for top-posting.
Here's a patch that removes any "artificial intelligence" from cam_get_device()
and thus from cam_open_device() as well:
http://people.freebsd.org/~avg/cam_get_device.diff

This removes the following features:
1. ignoring 'r' and 'n' at the start of device name
2. ignoring whitespace at end of device name (why put it there in the first place)
3. parsing and ignoring slice and partition names

So, only plain device names like /dev/foo0 or foo1 are supported.

Perhaps we could also remove sd => da and st => sa mapping at this time too?

on 23/04/2010 23:00 Andriy Gapon said the following:
> 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)
>>> _at__at_ -190,12 +190,6 _at__at_
>>>  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