From owner-freebsd-current Tue Feb 24 00:46:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA28898 for freebsd-current-outgoing; Tue, 24 Feb 1998 00:46:46 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA28879 for ; Tue, 24 Feb 1998 00:46:38 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA07901; Tue, 24 Feb 1998 08:11:39 +0100 From: Luigi Rizzo Message-Id: <199802240711.IAA07901@labinfo.iet.unipi.it> Subject: Re: ATAPI related patch .. To: mike@smith.net.au (Mike Smith) Date: Tue, 24 Feb 1998 08:11:39 +0100 (MET) Cc: hasty@rah.star-gate.com, mike@smith.net.au, scrappy@hub.org, freebsd-current@FreeBSD.ORG In-Reply-To: <199802232218.OAA12635@dingo.cdrom.com> from "Mike Smith" at Feb 23, 98 02:18:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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 bus. Since many people might have another IDE disk on the same bus, they risk losing their data which is undesirable... > With a little more work, once you support audio accesses in the driver > properly, you become able to produce a "cdrom audio FS", where tracks > on the disk appear as files when the disk is mounted. I think there are priorities, and in this case making the system more robust with a proper watchdog is by far more important than implementing read access to audio, or a audio cd filesystem, etc. etc. This even for the impending release of 2.2.6. Those (forget the name(s)) who said it would be easy to add a proper read() interface to audio cd, should really consider spending this time into making the watchdog work for the atapi devices as well. >From what i have seen (but my knowledge of the wd/wcd driver is too limited) it might just require adding a reference to the IDE bus descriptor in the atapi device descriptor, and then more or less invoke the same routines which already exist for ide devices. I can't do that because at the moment i have no easy access to a crash machine. cheers luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message