Date: Sun, 2 Feb 1997 13:02:42 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@freebsd.org Subject: Re: Mounting CD-ROM when data not on first track Message-ID: <199702022002.NAA08336@phaeton.artisoft.com> In-Reply-To: <Mutt.19970202101850.j@uriah.heep.sax.de> from "J Wunsch" at Feb 2, 97 10:18:50 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > But it's not a data area... or rather, it's not a 'data' area. > > Doesn't matter. Disk frame numbers don't distinguish between data or > audio areas. Things like the CD9660 code are meant in terms of disk > frame numbers however, so you have to hole out the !data areas. They > are valid frame numbers (block numbers in the SCSI sense), it's only > that you cannot READ them. It matters, in that this disc is not mountable by FreeBSD. We need to blame FreeBSD, not the disc... "be generous in what you accept, conservative in what you generate". > > Does anyone else have this CD? Do you have a MacOS or SunOS or older > > Windows box with ASPI or proprietary CDROM driver you can try it in? > > If the non-Joliet aware OS recognizes it, I'd think that the FreeBSD > > interpretation is probably wrong. > > FreeBSD doesn't have any interpretation at all by now, so you don't > need this contest. Its only `interpretation' by now is ``all the > world's a data disk from the beginning through the end, and we assume > the directory tree won't touch outside the disk area''. FreeBSD is interpreting audio data as 'data'. Perhaps it should not be doing this. Yes, this causes problems for the CD player and audio data reading code, which is why I suggested the c/d "slices". > > The software we run on our mastering burners here knows about writing > > additional sessions. > > We are looking forward to your submission. Please, contact > ports@freebsd.org to make it a new port. > > Uh, it's not available in source form? Too bad. :-)] Uh, it's commercial software we didn't write which runs only on Windows95. > > It seems that > > Microsoft (stupidly) can not force a program image to be entirely > > resident in memory, and will blue-screen if the image is from a disc > > that has been removed, and it wants to page from it. > > Why do you call this `stupid'? That's the same way every Unix does. > It's only that they probably miss the mount philosophy, so they could > have locked the medium until it will no longer be required for paging. Uh, "sticky bit"... I can solve the problem in UNIX. The DDK says I can resolve this problem in Windows95 as well, but the procedure described (marking the segments "preload") doesn't work. > > Why would you need 99 sub-devices? > > Because it's the most logical way. I don't wanna enforce a policy > (like ISO-9660) in the device driver, since that's a matter of the > filesystem code. A non-CD9660 CD for example might contain up to 99 > UFS filesystems, one per each track, which are fully self-contained > (i.e., with block numbers relative to the start of the track, as any > UFS used to have). Heh. Then you probably want to impose a "partitioning schema" outside the scope of the physical device driver. You'd do this using devfs and a logical-to-physical translation layer that knew to break it up into one device per track. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702022002.NAA08336>