Monty wrote...
>
> (A wholesale round of catching up. The things I miss by going to lunch!)
>
> Jvrg wrote:
> >>This depends on the point of view. /dev/sr0 is not opened and then
> >>explicitly attached to a B:T:L; who is introducing the dichotomy is up
> >>for argument. I will submit, also, that B:T:L is a foreign concept in
> >>ATAPI, something which is very much within the realm we're concerning
> >>ourselves with here. For ATAPI and parport SCSI, we have to assign
> >>the device illusory numbers.
> >
> >That's not true:
> >
> >- The SCSI bus numbering is up to the kernel software.
> >- ATAPI is SCSI over IDE. Luns a handled the samw way as they
> > ar in old 8-bit/PP SCSI
> >- It is obvious to assign targets 0 and 1 to master and slave
> > as the SCSI target is derived from a HW protocol that
> > selects the targets. On a different transport hardware
> > (SCSI-3 introduces different HW transport layers e.g. fiber SCSI)
> > you need target numbers that fit fot that transport.
>
> Just because the numbering is logical does not mean it is not
> artificial. But this argument is going off on a tangent, so I'll
> drop/rescind the point and try a different direction.
>
> Let's look at it this way. CAM adds an extra layer of indirection
> over a particular /dev entry being hardwired to a particular device.
> The argument is about this layer of indirection. What functionality
> does that layer of indirection get me in return for added complexity?
>
> Answer: none. There is nothing new I can do with the layer of
> indirection that I couldn't do with the old 'hardwired' approach.
> Also in return, my application code becomes more complicated and to
> use any specific device (eg CDROM drive) I have to scan *every device
> on the machine* to find it. The other solution is to maintain a
> registry; another added complexity for no new functionality.
>
> *This* is why I object to CAM.
>
> I'm Joe Linux User. When I want to use my cdrom drive, do I think,
> "I'll just plop a disk in old 1:3:0" or do I think "I'll just plop a
> disk in the old CDROM drive"? 99% of uses don't give a rat's ass
> about B:T:L. They want the first cdrom. They want the scanner. They
> want the hard disk. Why should I have to scan the whole machine in
> the common case such that the <1% usage case is easier?
>
> You argue that CAM gives us a uniform addressing scheme on every
> platform, yet the very presence of CAM requires a user space library
> (such as your lib or mine) to map a /dev entry to a scsi device. Why
> then not have a simpler addressing mechanism in the kernel and place
> the abstraction you want into libscg (the way it is now)? Either way,
> ya gotta have the lib to do what you want. With the 'hardwired'
> approach, common cases of addressing a device are simpler and faster.
Just to clarify things a little here wrt CAM:
The CAM spec does not, as far as I know, specify how SCSI passthrough
should be done. (If I'm wrong, and someone can cite the section of the CAM
spec that proves it, I'll happily recant.)
So, the method of interaction you're complaining about must be specific to
one of the two CAM implementations of CAM that I know of: FreeBSD's or
DEC's.
I know very little about DEC's CAM implementation, but I can explain
briefly how the FreeBSD/CAM passthrough mechanism works, and why we did
it the way we did it (for most of you who probably don't know, I'm
co-author of the FreeBSD CAM layer):
- There is a separate SCSI passthrough peripheral driver. (i.e., separate
from the CD, DA, SA, etc. drivers) It attaches to every device. So it
allows access to a given SCSI device even if there isn't a "regular"
peripheral driver attached.
- SCSI passthrough is optional. You have to include the 'pass' driver in
your kernel config file.
- SCSI passthrough ioctls must be done on /dev/passN, where N is the
passthrough device unit number.
- Passthrough devices (like any other SCSI peripheral driver) may be
hardwired, so that for instance /dev/pass0 always points to a particular
CDROM drive.
There are three primary reasons we went with a separate SCSI passthrough
driver, rather than just having users do the ioctls through /dev/rcd0.ctl
or some similar device:
- Having control minor numbers means hacking up your open() and close()
routines so that most of their "guts" are skipped for the control minor
number case. This is because the open() routines in some drivers have
to do checks that may not succeed in all cases. For instance, with a CD
driver, an open() won't succeed if there isn't media inserted. But you
may still want to send a test unit ready to the drive. You can't open
the device to do the SCSI passthrough ioctl to send a TUR unless you
skip most of the open() routine. Having a control minor number allows
for "restricted" opens (i.e., ioctls only), but it does add extra
complication to every peripheral driver.
- A separate passthrough device makes a good generic peripheral driver
that even attaches to devices that don't have a "regular" peripheral
driver attached.
- Consistency. Say Joe User has a scanner, but doesn't have the processor
target device (pt) configured in his kernel. With the old FreeBSD SCSI
layer, he'd have to have the "unknown" (uk) device configured to be able
to talk to his scanner. Application writers would have to figure out
whether to talk to /dev/pt* or /dev/uk* to do SCSI passthrough,
depending on which device the user had configured. With the
FreeBSD/CAM passthrough scheme, you always talk to /dev/pass*.
We could have easily stayed with the method of doing SCSI passthrough that
the old FreeBSD SCSI layer used, but we chose not to for the reasons above.
So it isn't really an issue addressed by the CAM spec, but rather an issue
that is specific to the implementation.
All of the passthrough to device mappings can be determined by userland
code without going through any library routines. The various CCBs
supported through the CAM transport layer device (/dev/xpt0) provide all
the necessary functionality. (Of course you don't need to look anything up
if a passthrough device has been hardwired to the device you're interested
in.)
We do, however, provide a number of convenience routines in the userland
CAM library (libcam) that allow opening a device by specifying:
- bus/target/lun
- device name and unit number (e.g. "da" and 5)
- passthrough device (e.g. /dev/pass15)
- regular device name (e.g. /dev/rcd0a)
Anyway, this may be more than most folks want to hear, but I thought I
would clarify that the way passthrough works isn't necessarily a requirement
of the CAM spec, but an issue specific to a CAM implementation.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
