>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.
Urg. Which means I need to add it too :-P Or make a util to generate
it...
>>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.
Fine. We both knew I was nitpicking.
>All I need is a _working_ and stable relation between device nodes and
>SCSI addresses.
I don't want to deny you this functionality. Does the /devfs scheme
(or a related method that achieves similar ends) make us both happy?
>>>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 :-{}
I'm truly touched :-)
>>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?
I'm not using NULLs ;-) I use whatever value I least expect to see at
the end of a specific transfer. Note that I'm not 100% proof to a
'false positive', only 99.9% (in most situations, like reading the
TOC, I am proof). I accept the false positive in some CDDA data
transfers as a situation I must deal with in other ways; I'd rather
catch all the errors (with a few bogus errors thrown in) than miss a
few errors now and then.
>Are you using radioactive NULL's ?
Yes, absolutely ;-) See:
http://www.mit.edu/afs/sipb/user/xiphmont/radioactive_null.gif
>Let's assume you want to talk to your second 'hme' Interface.
> HME stands for Happy Meal Ethernet.
I was reading this during the Day Job's weekly development meeting and
started giggling uncontrollably :-)
>So why don't you like to use the same semantics in SCSI?
Simply because the sematics grant no new functionality for the extra
layer of indirection.
>>> Under CAM, a generic scsi device does not refer to any particular
>>> piece of hardware. The device is oppened, then attached to a specific
>>> bus:target:lun combination.
>
>>Gross. Doesn't make sense at all. One device per real device. That's
>>the way it always has been and the way it always should be. Someone
>
>/*--------------------------------------------------------------------------*/
>This is not true! Please read my mail that I just send as a reply to
>Monty.
I never asserted it makes no sense. I *have* asserted it makes *less*
sense than other approaches :-)
Monty
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
