>From [EMAIL PROTECTED] Fri Feb 12 00:51:22 1999
>From: Monty <[EMAIL PROTECTED]>
>>>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.
But there will be more and more reasons why it would be a bad idea
to keep using readcdda. Future versions of cdrecord may need additional
information which may be found in the *.inf files of cdda2wav.
Users of a final cdrecord-1.8 will most likely force Thomas to
either add support for thi *.inf file content or to switch to cdda2wav.
>>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'.
OK, then let's call it _not yet_ used which shows that they may become
meaningful in the future.
>>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?
Then how about adding an ioctl() to tell the driver:
"Hey I am a good guy! You may trust the content in the extra flags"
This would bring us to the same level of confusion as recent
protocls that made it into a standard ;-)
>>>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.
Of course, you _need to know exactly_ what you want to do in such a case!
>>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.
I hope we could convince the Authors of the low and mid level code....
>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.
All I need is a _working_ and stable relation between device nodes and
SCSI addresses. I definitely need the libscg as it:
1) Helps to make application programs simpler and allows them
to print readable error messages.
2) Makes the application portable as it itroduces a level
of abstraction.
>>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>
Now we are friends again :-{}
>>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.
How do you distinguish between the NULL charaters you inserted and the
NULL characters you got from the device?
Are you using radioactive NULL's ?
>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.
I thought that this mailing list is related to CD-writing and related themes.
Cdrecord hast been written for Solaris and then ported to other platforms.
It still maintained and enhanced on Solaris mostly because the Solaris
driver interface will give me the information I need to verify my code
and most other OS including Linux won't give me that information.
>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 :-)
The device filesystem is a Sun idea. Automatic creation of device nodes
by the driver has been introduced with Solaris-2.1 (~ 1991) and is needed
to allow self configuring loadable drivers.
NOTE that Solaris will automatically give you a major number
for your driver when you install it on your machine.
Different machines will use different major numbers!
The numbers depend on the order of driver installation.
>>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>
Don't laugh!
If you add a disk, you obviously only need to call:
drvconfig
disks
But Solaris will allow you to add any peripheral hardware if the
basic system supports it (e.g. a UE10000).
You simply deconfigure the board that has the empty slot,
pull it out, insert the hardware, reinsert the board and reconfigure it.
The only disadvantage is that while 'drvconfig' is running, you will
not have realtime responses ad all interrupts are blocked.
But this is usually only a few seconds.
J�rg
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
