[openbeosstorage] Re: ISO9660/cdrom progress
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sun, 29 Dec 2002 01:05:45 CET (+0100)
>
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > We should also have priorities for the file system modules (i.e.
> > > a
> > > UDF
> > > file system should always get the disk, not the ISO-9660 file
> > > system,
> > > if possible).
> > That shouldn't be hard. We can add a function returning the
> > priority
> > to
> > the FS module interface.
>
> A function is okay, although I think that "ints" scale better for
> priorities than a float=3F
Do they? Be happened to use floats for priorities in the instances I
know (MIME sniffer rules, translators), and the nice thing about floats
is, that you always can find a number between two given ones (as long
as the precision is not exhausted, of course).
> > > Also, how does the system deal with multi-session CDs (and the
> > > like)=3D
> > > 3F
> > As it does right now, via the session modules.
>
> But that's not enough - we don't support them correctly, we always
> have
> to export all sessions, but there should be a way to differentiate
> multi-session sessions from others, so that Tracker only shows the
> last
> sessions, without having to care about it.
> But you should always be able to mount every single session from the
> shell as it was (perhaps even from within Tracker, perhaps with a
> submenu for a session=3F - although that would require extra coding,
> it
> might be a nice solution for power-users).
But isn't that a feature that should be into the Tracker rather than
into some API? I mean, the device API provides all information
available. If the user wishes -- or let it be the default behavior --
that only the last sessions of a multi-session CD should be available,
than this is something the Tracker can provide easily. Or do I miss
something?
> > If you mean, initializing a FS and writing partition tables, then
> > that's what the original DriveSetup add-ons were doing. The only
> > problem is, that both tasks need add-on-specific parameters, that
> > in
> > the case of the DS add-ons is retrieved from the user by popping up
> > a
> > dialog. The only way, I see, is to create a separate DS add-on API
> > for
> > this.
>
> Yes and no - I think the fs initialization belongs to the "real" file
> system add-on, not the disk=5Fscanner fs module.
I agree. What I originally had in mind was, that the disk_scanner
module simply gets hold of the FS add-on and tells it to do the
initialization.
But actually we should be able to get completely rid of the
disk_scanner FS modules and extend the FS add-on a bit to provide the
required functionionality. Now that I think about it, I find it the
preferrable solution. No code duplication at all...
> So if there is a DS add-on for a specific file system, it can provide
> a
> special GUI, but if not, DS will just ask for a name and pass that
> one.
Sounds good.
> I want to have mount/initialize use the driver=5Fsettings so that you
> can
> have sticky mount settings, etc.
Yes, that's nice.
> So the (void *) parameter will always be a string in the future,
> initialize=5Fvolume() can reflect that, while mount should probably
> stay
> compatible with the current version=3F (we would only lose source
> code
> compatibility)
I dislike using a string a bit, since that requires code to parse that
string, when one could as well pass a nice structure. But I see that
structures don't work very well with driver_settings.
CU, Ingo
Other related posts:
