[openbeosstorage] Re: session module
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 19 Feb 2003 00:27:22 -0800
On 2003-02-17 at 15:14:16 [-0800], Ingo Weinhold wrote:
>
> > 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.
As long as the R5 CD isn't misrecognized, I say relax away within
reason :-)
> > 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.
Okay, I understand now, thanks.
> 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.
I have to admit, I'm not sure I see much use in keeping it all in
userland. Basically no one but the registrar will use the libroot
functions otherwise, so why bother with the overhead imposed by keeping
them out of the kernel?
> > 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.
Yes, I see no reason not to do otherwise (I do like BeOS' cdda
filesystem :-).
> Then it seems the flags for session 1 are not set correctly. They
> should indicate a data session.
Oops, I'll fix that, thanks.
> 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.
See my next email for my take on the matter. :-)
> 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.
Hmmm, they could... Are they likely to ever differ, thoguh?
> 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?
I'd say fs.
-Tyler
Other related posts:
