Skip site navigation (1)Skip section navigation (2)
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
Message-ID:  <Mutt.19970202011243.j@uriah.heep.sax.de>
In-Reply-To: <199702012333.QAA06872@phaeton.artisoft.com>; from Terry Lambert on Feb 1, 1997 16:33:52 -0700
References:  <Pine.BSF.3.95.970201014125.5705A-100000@alpha.risc.org> <199702012333.QAA06872@phaeton.artisoft.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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. ;-)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970202011243.j>