[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-scsi
Subject:    Re: cam.3: do not discourage use of cam_open_device
From:       Andriy Gapon <avg () freebsd ! org>
Date:       2010-04-23 20:00:52
Message-ID: 4BD1FC74.3090504 () freebsd ! org
[Download RAW message or body]

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
_______________________________________________
freebsd-scsi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]