From owner-freebsd-hackers Sat Feb 1 16:22:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA18758 for hackers-outgoing; Sat, 1 Feb 1997 16:22:06 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA18751 for ; Sat, 1 Feb 1997 16:22:00 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA06695 for freebsd-hackers@freebsd.org; Sun, 2 Feb 1997 01:21:58 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id BAA03480; Sun, 2 Feb 1997 01:12:43 +0100 (MET) Message-ID: Date: Sun, 2 Feb 1997 01:12:43 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org Subject: Re: Mounting CD-ROM when data not on first track References: <199702012333.QAA06872@phaeton.artisoft.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702012333.QAA06872@phaeton.artisoft.com>; from Terry Lambert on Feb 1, 1997 16:33:52 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > I believe this is a perfectly legal thing to do, actually. One wonders At least not in the sense of CD9660 (which i think has a crippled idea in this respect). > why the cd device starts at the raw track one instead of the first data > track in any case... Because it always starts at the beginning, and covers the entire data area. You could look at it as if it were a huge sparse file in this special situation: seek to the right location, and you'll be able to read the data. Btw., this is exactly what the normal ``multi-session'' idea of CD9660 is: you've got the entire drive mapped, and the first track of the most recent session contains the CD9660 directory structure, where the block pointers are allowed to point back on the CD, or to point into this track itself. (Strictly spoken, they are allowed to point into the first track of each successive session only. See above.) That's why they call this entire beast a session then, despite of the matter that a single session might have multiple tracks. They always siltently assume at most the first track of each session being in CD-ROM data format. Our cd9660 filesystem code simply needs to examine the TOC (this can be done from userland, since there's an ioctl for it), and if it succeeds in this operation, it should default to the diretory structure from the first track of the last session. Voila!, this would allow us to read multi-session ISO-9660 CDs. The downside: _creating_ such a filesystem is way harder. mkisofs currently always runs in standalone mode. For ISO-9660 CDs however, it needs to examine the existing tree structure first (which can already be multi-session), and needs to figure out which files are to be replaced. It must then add them up to the new track, along with an entire new directory tree. (Maybe partial new would suffice, if parts of the tree remain untouched.) Things are even worse if audio tracks lie between the data tracks, since mkisofs must retains the holes in the block numbers, even if the data contents is unknown. > Finally, it seems to me that the CDROM device should impose "slices" > on its own, and it makes sense to me that 'd' is the whole disk and > that 'c' is the first data area. It makes no sense, i've already thought about this. There are up to 99 tracks allowed, so we need up to 99 subdevices. Maybe 100, to account for one covering the entire disk (subdevice 0 fits best for this, since it's not a legal track number). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)