>>I would welcome even this overall, but I disagree with the device
>>addressing scheme of SCG and CAM. It introduces an artificial
>>dichotomy between the specialized and generic interfaces, resulting in
>>more complex application code (or more likely, lazy application code
>>that dumps the responsibility for matching up devices onto the user).
>>/dev/sg devices should exist only as placeholders, not a primary
>>access mechanism.
>
>I disagree with anything else. Your suggestion introduces this artifical
>difference between the SCSI devices and the UNIX device I would have to open.
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.
The argument is basically boiling down to addressing by UNIX idiom (my
position) versus addressing via B:T:L (your position). I can see that
to get to 'a cdrom', perhaps my way is more direct but I do want to
addess the SCSI bus in methodical fashion, your way is more direct.
Let me try an alternative that allows both without complicating the
matter too much:
We present an SG ioctl interface (BSD influenced) on the specialized
device. We present the *same* interface on a BTL addressed device
after attachment (or perhaps we should have dedicated device file
entries for each bus/target/lun present, ala Solaris?) I haven't
thought through the potential complications of this yet.
The key here is that the interface is the same, real SCSI can be used
via B:T:L, and we don't introduce artificial addressing numbers for
protocols (ATA/ATAPI) that don't have them.
>SCSI is protocol with it's own paradigmas and with it's own addressing methods.
>If you want to write a generic SCSI access driver you should conform to
>the addressing methods of SCSI.
I'm looking for a way of doing this without poking the edges of scsi
through the brown paper bag that is UNIX. I'm not *technically*
opposed to "your" addressing mechanism; it crosses my instincts as an
interface designer.
>>referring to specific implementation problems, but rather the idea of
>>presenting a generic interface via the specialized scsi device file
>>entry. I'm not denying one needs access to the BUS/TARGET/LUN
>>numbers, just that these details should not be the responsibility of
>>an unsuspecting user. It would be like naming a serial port
>
>Therefore cdrecord supports a scanbus command...
As does Paranoia scan the bus in an automated fashion. But what
software mightn't bother? You have to admit that most of the software
out there was written with expediency and raw function in mind, not
ease of use. I don't like system interfaces that encourage sloppy
application code.
>>things sorta this way before the idea of specialized interfaces caught
>>on. All device drivers were in userspace and applications had to
>>include device drivers for all the specific hardware they wanted to
>>use. I'd like to think that BSD4.2 was an overall advance in moving
>>away from this) instead of just opening /dev/cua0 (and having links to
>>/dev/modem and /dev/serial0).
>
>This has nothing to do with the problem discussed above.
Very well, I retract the argument.
>>All this hunting and error prone device mapping isn't necessary if one
>>lets go of elevating SCSI over the design idiom of the native OS.
>
>This error prone device mapping is only needed on Linux because the
>kernel SCSI modules are using the wrong addressing methods.
I fully agree that the implementation of Linux further complicates the
matter, moreso than the worst SCG would.
>Hey, I also could name my computer /dev/sol/terra/deutschland/berlin/fokus/...
The Sinclair Quantum Leap did something very much like this back in
'83. Each computer on the network had a device entry in the global
equivalent of /dev/net. Just a neat little aside.
>But it is called *.fkus.gmd.de because the internet community decided
>to use this addressing method. To address my computer I need to know
>the IPaddress and I know it because I did set it up.
Even IP sets up an abstraction over the raw numbers, because the
numbers are not suitable for everyday use by humans. Note that DHCP
obsoletes even knowing the IP quartet during setup.
>To address a SCSI device, I need to know the bus/target/lun numbers and
>I know them because I did set them up when I connected the device
>to my machine.
Many users today do not set up their own machines. My sister uses a
Windows machine with a SCSI subsystem (disks, cdrom) that I built for
her. She has no idea what a SCSI or LUN is. She just knows she has
two hard drives and a cdrom. She has no trouble using the machine and
the software she buys for it.
All Macs until recently were SCSI. I seriously doubt more than a
single-digit percentage of Mac users knew the B:T:L of their SCSI
devices... So the argument that everyone must know BTL to interact
usefully with SCSI doesn't hold water.
Monty
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
