[openbeosstorage] Re: session module
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Tue, 18 Feb 2003 00:14:16 CET (+0100)
> I've finally finished revamping the cdrom session module. It's a lot
> more robust, and ought to handle audio and data sessions correctly
> now. Please let me know if you find anything that breaks it. :-)
> Also, my R5 CD is now recognized flawlessly thanks to the updated
> partition module. Thanks Ingo. :-)
For the partition module there is a narrow line between being too
tolerant -- and mistakenly recognize a partition map -- and being too
strict -- making the users life hard, when a partition descriptor is
not valid. Originally the module was very lax. Then, after your
discovery, I made it fail whenever there was a problem in any of the
partition table sectors. This was too strict, as it turned out. I
relaxed the rules a bit, but maybe that's not enough.
> One thing I've noticed is that the CDROM table of contents currently
> is read two or three times (I forget which) for each effectively
> recognized session. It would probably be a lot faster if we could
> return a cookie after the first call to get_nth_session(), or at
> least cut the number of calls down from the disk_scanner to the
> session modules to once per session index. Is this multiple call
> behaviour expected?
The way get_nth_session_info() works is, that it first identifies the
module responsible by calling the identify() hook of the available
modules until the correct one has been found. Then the get_nth_info()
hook is invoked to get the session info.
Since get_nth_partition_info() only gets the session index, for each
call the session has to be found first. If a session_info would be
provided, the disk_scanner could work with that, but I don't feel very
comfortable with passing such an info to the kernel without checking
it.
BTW, this would be a reason to move the DiskDevice stuff from the
registrar into the kernel. It could also keep a pointer the module,
avoiding even the module loading/unloading completely. And we could
completely get rid of the current (libroot) disk_scanner API functions,
which I don't find very nice anyway.
> So, my current task list now looks like this:
>
> + Join the multi-session volume set investigation
> + Have a closer look at Ingo's C++ Device API stuff
> + Add Joliet volume name support to iso9660 add-on
Great!
BTW, I ran the test program with my precious Portishead `Roseland NYC
Live' CD, which contains among the great music also a data session.
Here's what I got:
device: `/dev/disk/ide/atapi/1/master/0/raw'
session 0
offset: 0
size: 530139136
block size: 2048
index: 0
flags: 0
get_nth_partition_info() failed: Device format error
session 1
offset: 553486336
size: 110739456
block size: 2048
index: 1
flags: 0
partition map: `'
partition 1_0
offset: 553486336
size: 110739456
block size: 2048
session ID: 1
partition ID: 0
device: `'
flags: 2
partition code: 0xeb
partition name: `'
partition type: `'
FS short name: `iso9660'
FS long name: `iso9660 CD-ROM File System'
volume name: `PNYC'
FS flags: 0x4
The `Device format error' occurs when the disk_scanner module tries to
load the first block of the audio session. To provide the possibility
for a cdda file system, I would like to call the FS module hooks
nevertheless. Maybe with an optional flag. In case we'll get rid of the
FS modules, the FS add-on hook must be able to deal with that.
Then it seems the flags for session 1 are not set correctly. They
should indicate a data session.
But there's more interesting to learn from that data, especially when
comparing it with the info the old Device API returns:
device: /dev/disk/ide/atapi/1/master/0/raw
display name(0, 0): `IDE master bus:1'
display name(0, 1): `IDE master bus:1'
display name(1, 0): `IDE master bus:1'
display name(1, 1): `IDE master bus:1'
session 0 (apple)
offset: 270257
virtual: 0
data: 1
partition 0 (MRKS)
offset: 1
blocks: 2
block size: 512
hidden: true
partition code: 0x0
partition name: `MRKS'
partition type: `Apple_partition_map'
FS short name: `'
FS long name: `'
volume name: `'
mounted at: `'
partition 1 (Toast 3.0.2 PPC HFS Optimizer)
offset: 24961
blocks: 190117
block size: 512
hidden: false
partition code: 0x0
partition name: `Toast 3.0.2 PPC HFS Optimizer'
partition type: `Apple_HFS'
FS short name: `hfs'
FS long name: `Mac HFS'
volume name: `PNYC (MAC)'
mounted at: `'
session 1 (none)
offset: 2147483647
virtual: 1
data: 1
partition 0 ()
offset: 0
blocks: 271001
block size: 2048
hidden: false
partition code: 0xff
partition name: `'
partition type: `'
FS short name: `cdda'
FS long name: `Audio Filesystem'
volume name: `Audio CD'
mounted at: `'
The offset of session 1 is obviously nonsense, but session 0 is located
at the same offset as our session 1 (just in blocks), but it shows an
Apple style partitioning, while we recognize an ISO9660 FS. I'm sure
both is correct. I wonder, how to deal with such a case.
Even more things to discover: Our implementation implicitly assumes,
that the (logical) block size of the device is also that of the session
and the partitions. Shall the session and the partition modules return
their block size? I mean, there is a field in both of the structures,
so that wouldn't be a problem.
Shall the block size in the extended_partition_module then be the one
from the partition module or from the FS module? Or shall another field
for the latter one be added?
CU, Ingo
Other related posts:
