[5925] in linux-scsi channel archive
Re: WG: AW: cdrecord problems on recent Linux versions
daemon@ATHENA.MIT.EDU (Joerg Schilling)
Sat Feb 13 11:42:20 1999
Date: Sat, 13 Feb 1999 17:33:40 +0100 (MET)
From: Joerg Schilling <schilling@fokus.gmd.de>
To: schilling@fokus.gmd.de, xiphmont@mit.edu
Cc: Dominik.Stadler@btk.de, bsc@fleggaard.dk,
cdwrite@lists.debian.org, dgilbert@interlog.com,
heiko_eissfeldt@z.detesystem.de, linux-scsi@vger.rutgers.edu,
michaels@stochastik.rwth-aachen.de
>From cdwrite-request@other.debian.org Fri Feb 12 23:35:38 1999
>From: Monty <xiphmont@mit.edu>
>>>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
Looks cool but (specially the second argument to memcpy().
Unfortunately, this would make the code non-portable to K&R only systems.
>>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 :-)
It is really the successor of a beta-development chip called BIG MAC :-)
And you would aggree that that's a neat mame for a BIG (100MB)
Medium Access Controller. You see, Sun guys still have some sort of humor.
BTW: did you know that the SYSvr4 kernel is mostly based on the SunOS 4.0
object oriented memory and mmap system where Sun introduced a kernel function
called as_hole() that is used to find a hole in the address space of a process
that may be used for an mmap().
When AT&T and Sun made the contract for SVR4, AT&T forced Sun to rename that function
to as_gap().
Jörg
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.gmd.de (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 majordomo@vger.rutgers.edu
