Re: R5 Pro CD vs. partition/intel

> > If it were just some random, obscure CD, I might be tempted to say
> > "screw it", but being the R5 Pro CD, we really ought to get the 
> > thing
> > working properly. Since I believe the updated cdrom module is
> > actually working correctly, I've gone ahead and checked it in so
> > everyone can play with it. :-)
> 
> Unfortunately, it doesn't seem to work for me. I just updated to the
> latest CVS and the session module doesn't like the TOC or whatever.
> BTW, I'm have a version distributed by Gobe. Don't know if it is the
> same one distributed in the USA. Debug output is attached.

I have the Gobe one as well, but it appears to be ever so slightly 
different: the toc entry 0xA0, which tells what the track # of the 
first track in the session is, is marked as belonging to an audio 
track; all other entries are correctly labeled as being data tracks. 
I've updated the module to ignore such deviations now.

> > So, if Ingo can't come up with a way to invalidate the second 
> > session
> > of the R5 CD as an intel style partition set while still properly
> > recognizing real partition sets :-), I guess we may need to handle
> > partitions differently for CDs.
> 
> At least the DriveSetup intel partition add-on manages to deny the
> sessions, so it is obviously possible. Currently I only test for the
> signature in identify(). I could parse at least the primary partition
> map, if not the whole partition structure.
> BTW, I really tend to switch to C++ in that module. I believe, that
> would make it a lot more elegant and less error prone -- I think, I
> found another error concerning extended partitions on sessions with
> offset > 0.

Fine by me. I'd just as soon use moderated C++ pretty much everywhere, 
honestly.

> > Has anyone ever heard of burning a CD
> > session with multiple partitions, anyway?
> 
> Yes (don't know, if their is an easy solution for home users though).
> Some BeNewsletter (or BMessage?) discusses the matter of CDs with
> multiple sessions vs. multiple partitions. And obviously the 
> DriveSetup
> add-ons support it.

I'll have to hunt that down.

> I don't have a CD burner at hand right now, but if you have, you can
> try to create a multi-partition image using the virtualdrive driver 
> and
> burn it on CD. (The driver is a quite unflexible right now, but before
> we start testing our API, I will add driver_settings support.)

Don't have the time at the moment, but I'll have to try that sometime.

> > Theoretically it could be
> > done, I guess, but you can do everything partitions can do (and 
> > more)
> > with sessions. Following that argument, we could then just have a
> > cdrom partition module (or special case, a la
> > disk_scanner_get_nth_session_info() in disk_scanner.c, but I don't
> > think I like that route; see next paragraph) that returns one
> > partition encompassing the whole session if the device is a CD.
> > Thoughts?
> 
> I don't like that idea either. In particular, because multiple
> partitions per session are possible.

Fair enough.

> > And while I'm thinking of it, that special case to handle CDs in
> > disk_scanner_get_nth_session_info() kind of bugs me. Oughtn't we 
> > have
> > a non-cdrom session module to handle the virtual session case, and
> > then allow developers to have a higher priority custom module in the
> > odd case that they want to support a special kind of session for
> > their device? As it currently stands, only CD devices ever get a
> > chance to publish sessions to the system.
> 
> That's true. If the session add-ons are robust enough, we can drop the
> check for CD devices and return a virtual session, in case no session
> add-on recognizes the format -- similarly as done on the partition
> module level. We don't need to introduce a dummy session add-on to do
> this -- otherwise we would indeed need priorities (not that I have
> arguments against priorities, but we don't need to introduce something
> we won't quite likely ever use).

Sounds much better to me.

-Tyler