> So, I've been looking at adding multisession support to the SCSI cd
> driver.  Doesn't look too hard - looks like the right thing to do is
> read the TOC, generate a synthetic disklabel using the information from
> the TOC, and then you can just access the the different sessions as different
> partitions.

But that's not what multisession CDs are about.

On multisession CDs, you should only read the directory tree of the last
session. This one will have pointers to files in previous sessions, too.

Yes, there are CDs out there that have multiple sessions with separate
directory trees, but that's a different concept. They happen to be called
(unfortunately, see my previous post about the correct definition of this
term) multi-volume CDs.

> When looking at the disklabel-generation code, I've come across something
> that seems rather odd.  From looking at the code in cd.c (and sd.c as well),
> it seems that the partition size is stored in the disklabel as 512 byte
> blocks, no matter what the actual number of bytes/sector is.  Also, it seems
> that this is _not_ true for the partition offset - that seems to be stored
> in blocks that are really the size of the media.
> 
> Is my understanding of this correct?  If so, does anyone know if this behavior
> is historical, or is there some larger purpose I don't quite understand? :-)

As far as I understand this, it's purely historical. It's probably the result
of a quick and dirty attempt to get something like non-512-byte blocksizes
into it.

> Oh, while we're on the subject -- I'm wondering what to do about the case
> of a CD-ROM that has more than 8 data tracks.  The Photo-CD I have happens
> to have 12 :-)  I know that most of these are not valid ISO-9660 partitions,
> but I'm not sure if it makes sense to try to detect an ISO-9660 filesystem
> and try to only show those, or have some frobby utility to switch between
> different groups of labels, or what.  And does anyone happen to know if there
> is any way to differentiate between different data track types?  I've
> figured out that I can look at the Q channel codes to determine if it's a
> data track, but I don't see any way to differentiate between different
> types of data tracks.

I'm not sure what you mean by "different types of data tracks". There is this
Q channel information, that has this address field, where, among other things,
you can find out, whether some track is a data track.

If you want to determine, whether some track is ISO-9660, or some other format,
that's only distinguished by its contents. Like the difference between say
tar and cpio format.
--
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800