(A wholesale round of catching up. The things I miss by going to lunch!)
Jvrg wrote:
>>inquiry (SCSI Programming HOWTO - Heiko Eissfeldt)
> Heiko already tole me that he will change this file...
We only know of 5 major applications that used this for the past N
years. How many do we *not* know about?
>>readcdda (T. Niederreiter)
> T. Niederreiter promised me about a year ago
> that he will discontinue readcdda in favour of
> cdda2wav because:
> 1) It is non portable
> 2) It does not support ATAPI
Yet people still use it.
>There should be a warning about this in the howto....
There is not.
>Any programmer who writes code that does not clear reserved fields
>needs to know that his code will most likely fail sometimes in
>tht future.
The fields are not marked reserved. They are marked 'not used'.
>Then Monty should clean up his code at this point.
Indeed I should, but That misses the point. You know that I'm using
SG in my software and you can bonk me on the head when you want to
change the interface. How much other code uses SG that you *don't*
know about?
By all means, go wild in 2.3. NO NEW FEATURES in 2.2. I want to see
this interface cleaned up as much as anyone. 2.2 is not the time to do
it, your comments about trying to get it into 2.1 notwithstanding.
>>Joerg, do you ever use cdb_len to _usefully_ override
>>the scsi command length that would otherwise be calculated
>
>Not on Linux so far.... but:
>Yes. Note that there are other SCIS devices (e.g. jukeboxes)
>that may define vendor unique commands and thos vendor
>unique commands sometimes are not of the size you expect.
I second Joerg here. It's very easy to crash buggy SCSI devices with
vendor-specific commands of sizes other than what they expect. Some
devices will also jam the SCSI bus when this happens; a poor
situation.
>>There only needs to be one major 'non-conforming' application out there
>>to make it very unpleasant for sg.h.heiko to go into 2.2 . I think I
>>have found 2 today.
>
>I don't think so.
>
>1) thos applications are written insane.
Gee thanks.
>2) Linus personal oppinion is that interfaces should be changed to become
> binary incompatible from time to time.
Linus is a bit of a hypocrite on this issue; I don't hold his opinion
on the matter in the highest regard. Of course he's right in the
strictest sense; binary compatability must sometimes be sacrificed to
move forward. However, in practice he is much too willing to
sacrifice compatability for my (and a large number of other
developers') comfort.
>I hope that an enhanced sg driver will point the mid level programmers
>to missing features.
>
>BTW: CCS and SCSI-2 or later require to fetcch at least 18 bytes of
>sense data. The actual Linux code is wrong anyway.
I agree with both of Joerg's wishes here.
>>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.
>This is really funny if you read his mail in the linix-kernel list
>
>http://www.tux.org/hypermail/linux-kernel/this-week/0057.html
>
>He should not ask for things he is not willing to grant to others.
<g>
>>...and God would I love to have it :-) Until then, I'll just keep
>>clobbering the transfer buffer.
>
>There are reasons, why you currently cannot use Linux to develop SCSI
>code: If you don't know whether the actual DMA count was what you expected.
>It may be that your code is wrong. This _did_ happen with the hack on
>the old cdwrite source that should support the Sony drives.
I think you misunderstand. I'm clobbering the transfer buffer *very
much on purpose* to get data on the actual DMA transfer count for all
reads. This is why Paranoia has access to the actual transfer size
under Linux. The way I do it, though, is very sensitive to kernel
implementation and violates all sorts of good programming sense. It
just happens to work and is too useful not to use.
> 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).
Or, 30 drives on three scsi chains and four IDE interfaces, like my
cdparanoia test machine SnotFish ;-)
>You could use a different name for the mapping file and make all applications
>use this file. I may thing about putting it into a later version of the
>SCSI transport lib. In this case, only the SCSI name mapping should be in this
>file.
The current approach works quite well and doesn't need this complication.
Michael writes:
>I only need this to work on Linux. If another OS uses a different method,
>thats fine to me - we are not talkig about defining a SCSI layer which will
>then be used by all operating systems, but we are talking about a working
>solution for Linux. You will need special code for every different OS
>anyway.
Actually, Joerg *is* arguing exactly that: CAM is a method of having
an identical SCSI addressing/usage scheme on every platform.
*That* is the thing that should go in a lib. We are talking about the
Linux kernel here after all, not userspace applications. As you need
a lib anyway, put the platform abstraction into the lib. The Linux
kernel is and should be concerned only with Linux and the best thing
for Linux. It should take the outside world into consideration, of
course, but there's a limit to altruism when one considers the outside
world to have an inferior way of doing things.
Jvrg wrote:
>But Linux is not the world. We are currently discussing problems of
>creating a easy to lern/use user interface for a highly portable user level
>SCSI application like cdrecord and cdda2wav.
No, but when we're talking about Linux, we're concerned with Linux,
not evey other platform.
Richard wrote:
>Have you heard about devfs? It allows device drivers to register
>device entries which will automagically appear in /dev. It supports
>the old-style names "/dev/sg0" as well as the new-style names
>"/dev/sg/c0b0t0u0" (controller, bus, target, unit).
>
>It's not just for SCSI: it's for *all* devices. It's been around for a
>year now.
*This* I like (and it's sort of like what I was talking about
earlier). We both get what we want, and we can put the same generic
access interface on each of the devices.
Two questions about devfs unrelated to the ongoing argument: Do the
device entries show up when the device module is not loaded? (If not,
how do you know the hardware is there? Having to probe by forcing
module loads would be a nightmare and only accessible to root).
Second: What is the chance of this becoming mainline? I tend not to
code to interfaces that only a few users have patched in.
I've been warned by a few linux-dev folk here that devfs has caused a
few flamewars due to opposition; I'm unfamiliar with the arguments
against it. Would it be possible to summarize presented pros/cons or
point me to somewhere a discussion may have been archived?
Jvrg wrote:
>Interesting, this is a SYSVr4 idea (around since 1987).
I never said only BSD had good ideas, just that it got most of 'em :-)
>Howerver, it is possible to add hardware to a running system.
>Then you need to call:
>
>drvconfig tells the kernel to reconfigure the drivers
>devlinks general symlinks program
>disks symlink program for disks
>tapes symlink program for tapes
>ports symlink program for serial lines
>audlinks symlink program for audio devices
>ucblinks creates BSD compat dev entries
>
>If you don't call all programs corectly, it's your fault.
<rotfl>
Monty
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
