Date: Sun, 4 Feb 2001 12:53:49 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Soren Schmidt <sos@freebsd.dk> Cc: David Kelly <dkelly@hiwaay.net>, multimedia@FreeBSD.ORG Subject: Re: Cd-paranoia Message-ID: <20010204125349.A76354@panzer.kdm.org> In-Reply-To: <200102040842.JAA92575@freebsd.dk>; from sos@freebsd.dk on Sun, Feb 04, 2001 at 09:42:08AM %2B0100 References: <200102040012.f140C0N22052@grumpy.dyndns.org> <200102040842.JAA92575@freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 04, 2001 at 09:42:08 +0100, Soren Schmidt wrote: > It seems David Kelly wrote: > > Soren Schmidt writes: > > > It seems Olexander Kunytsa wrote: > > > > how can i create such devices -- /dev/acdNtY? I have none of them nor in > > > > /dev/ neither in /dev/MAKEDEV;( > > > > > > Hmm, seems the device entries in MAKEDEV never got committed in -stable.. > > > > > > Now they are :) > > > > And please add to the man pages? Maybe acd(4) needs to be a separate man > > Well, maybe, I'll think about it.. > > > page now? Oh, and wouldn't it be nice if SCSI cd(4) behaved the same? Or > > is that undocumented too? > > SCSI CDROM's are accessed through CAM which AFAIK doesn't support > != %512 byte sectors, so this won't work there, without extensive > changes to the CAM layer... That isn't a CAM issue, but rather more of an issue with the cd(4) driver and SCSI cdrom drives in general. Unlike the ATAPI world, there are lots of SCSI cdrom drives out there that support non-standard (i.e. non-MMC) ways of getting at CD-DA data. You can't just blindly issue a READ_CD command and have it work. For an illustration of this, look at tosha's tosharc file (installed in /usr/local/etc) or the code in cdda2wav that deals with different CDROM drives. So although MMC-compliant drives are probably the norm now, there are still a fair number of drives that use different ways of getting at CDDA data. The other issue is the disk/slice code. The cd(4) driver uses it, the acd(4) driver does not. The slice code, from my reading of it, can handle block sizes that are not a multiple of DEV_BSIZE, with the possible exception of blocksizes that are less than 1024 bytes but not a multiple of 512 bytes. (See dsmakeslicestruct() in sys/kern/subr_diskslice.c, specifically the part that calculates ssp->dss_secmult, and then look at dscheck(), where it checks for ssp->dss_secmult == 1.) Of course in the normal case, that won't be an issue with CDROM drives. The thing about the slice code that it expects the sector size to be constant within a given slice. This may not be the case with CDs, since you may have a bunch of audio tracks followed by a data track, so you'd have a combination of 2352 and 2048 byte tracks. Which blocksize do you pick? These problems are solveable, but not trivial. Soren has gotten around the disk/slice code issues by avoiding it. I'm not entirely sure what the "right" thing to do is for the cd(4) driver, especially in light of writeable CD support (DVD-RAM, PD, etc. drives). It'll probably take some more chats with BDE to figure out the best thing to do. In the mean time, there are plenty of fully functional CD rippers that work just fine with most SCSI CDROM drives. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010204125349.A76354>