[openbeosstorage] Re: session module

> 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: