On Wed, Feb 10, 1999 at 09:36:45PM +0100, Joerg Schilling wrote:
> But the mapping from bus/target/lun should not be done inside the kernel.
> The kernel cannot help you:
>
> Let's assume I have 8 CD-recorders on 4 SCSI busses each two sharing
> a fast cache disk and I put them somehow into 2 boxes (4 into each).
>
> Now you are right, the drives don't send you a serial number
> and for this reason, the kernel cannot help you.
>
> But you most likely will but labels on the drives.
>
> Well cdrecord gives you the possibility to mapo the device name exactly to the
> name you put on the labels.
>
> cdrecord dev=burner_1
Nice. However, this should not be done in every single application.
Locally, we use a system called scsiscan[1], which creates aliases in
/dev/scsi/ - in you example, I would set up the scsiscan configuration so
that /dev/scsi/burner_1 is automatically created as a device node with the
correct major/minor/type for the device, whetever ID I switch it to. When
using disks or other devices that can be identified 100% (using contents of
sector 0, plus device/vendor name), this works 100% automatic. On identical
devices which can not be told apart, you still have to specify the IDs (like
in the cdrecord config file).
However, this needs to be done only once - in my case, scsiscan is a simple
user mode program that is run on every reboot (or by hand, to add/remove
devices), but I don't care if this is done in the kernel or in user space -
however, it should *not* be done in every single application, but in one
central place.
I think it should be possible to call a program which does SCSI calls by
specifying a kernel device - eg. /dev/scd0, or a link (/dev/cdrom). In that
case, the user does not have to worry about IDs at all in a typical system.
If no special device (eg. cdrom) exists, a generic one can be used. IMHO,
the user should only be concerned with IDs when caling a program if it is
absolutely unavoidable.
cu
Michael
[1] a similar tool is available somewhere, but we wrote a more flexible
version here. However, this is currently not in a state that is fit for a
public release :-(
--
In the beginning there was nothing, which exploded.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
