Date: Tue, 24 Feb 1998 01:12:29 -0800 From: Amancio Hasty <hasty@rah.star-gate.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: mike@smith.net.au (Mike Smith), scrappy@hub.org, freebsd-current@FreeBSD.ORG Subject: Re: ATAPI related patch .. Message-ID: <199802240912.BAA22624@rah.star-gate.com> In-Reply-To: Your message of "Tue, 24 Feb 1998 08:11:39 %2B0100." <199802240711.IAA07901@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
> > The low-level SCSI I/O routines need a freeform I/O approach, and > > they're designed for casual poking at things in an out-of-band fashion, > ... > > Luigi's hack is for CDDA (sucking audio off the CD) acccess; this is > > basically bulk data transfer. Being a read-like operation, it's better > > handled as such. > ... > > I appreciate that Luigi's hack is expedient, and as I said if there's a > > strong precedent (ie. binary compatability issues) then sure, we should > > support it. > > as a precedent, i would like to mention that access to audio/videocd > and other stuff from a SCSI CD is done using the generic IO approach. > Same thing is done for accessing SCSI scanners. I am the first to > say that this is not nice but at least you get the job done in a > simple way. > > This said, i _DON'T_ like to have this patch NOW in the -current > tree because our atapi subsystem, as i mentioned far too many times, > does not have proper timeout handling, and implementing a generic > ATAPI ioctl, together with broken firmware in the atapi peripherals, > opens the door to all sort of deadlocks on the corresponding IDE We forgot to mention that whomever embarks on a high level abstraction for dealing with multimedia devices including scanners has to also content with writing and supporting the underlying hardware which in many instances has not been standardized or hardware vendors are very lax . Do a net search on the linux scsi scanner project SANE and dig up the code to get a hint. If someone decides to support the new IDE standards for reading audio or video then we have the problem of backwards compatibility. For sure in scsi land , we will have a problem take a peek at the code for tosha if you you are curious -- we of course can drag all the brand/model specifics details for dealing with different scsi cdroms to the kernel. The Philips format for video cds is propieratory and over the long run it is not a good idea to have it in the kernel or the sources widely available. We can get around this obstacle by having someone with a license from Philips to write a user land program, driver, or an lkm. If memory does fail me the Philips license prohibits the distribution of source code to decode CDI or Video CDs. We can try to publish the code however we will be asking for trouble. brian@worldcontrol.com can explain further for we have discuss this issue in the past and he has had the opportunity to chat with Philips with respect to this issue. While we are in the topic of audio/video interfaces for CDs someone should take a look at what Linux is doing in this area for we can potentially benefit in this area . Quake ][ is a key program which currently we don't support reading the CD's audio track. Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802240912.BAA22624>