/* @(#)README.session	1.3 99/03/02 eric */

	This release of mkisofs has basic support completed for
multiple sessions.  However, we still need some interaction 
between cdrecord and mkisofs for this to work correctly. This is needed as
only cdrecord knows the different ways to gather these numbers for all 
different drives. It may be that future versions of mkisofs will include 
the needed support for MMC compliant drives.

	There are a few new options to mkisofs to allow for this.
The first one is "-M /dev/scd0", and is used so that mkisofs can examine
the entirety of the previous image so that it can figure out what additional
files need to be written in the new session. Note that there are operating
systems that don't allow to read from CD drives with a sector size
of 2048 bytes per sector. To use mkisofs on such an operating system, you
will need a version of mkisofs that includes the SCSI transport library 
from cdrecord. Simply use the dev= syntax from cdrecord with -M in
such a case. It will tell mkisofs to use the SCSI transport library to 
read from the CD instead of using the standard read() OS interface.

	There is also a temporary hack in mkisofs in the form of a '-C' option.
The -C option takes two numbers as input, which are delimited by commas.
For example, you could specify "-C 1000,1020", but you should never just
make up numbers to use here.  These numbers are determined from cdrecord.

	Note that if you use -C and omit -M, it effectively means that
you are writing a new session, starting at a non-zero block number,
and you are effectively ignoring all of the previous session contents.
When this session is sent to the writer, the new session effectively
"erases" the previous session.

	In practice you should be able to do something like:

mkisofs [other options] -C `cdrecord dev=b,t,l -msinfo` \
		-M /dev/cdblkdev

Replace 'b,t,l' by the aproriate numbers for SCSIbus, target and lun
of your drive.

Note: As of the 1.12b5 release, the multi-session technology has
matured quite significantly.  It is entirely possible that bugs
exists, or that further tweaks will be required somewhere along the
way to get things working correctly.  The data gathering mode of
cdrecord has been tested, and I believe it works correctly.  Caveat
Emptor.

[Mar 1, 1999].