FreeLists / openbeosstorage / [openbeosstorage] Re: ISO9660/cdrom progress

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

"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

> > 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).

> 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.
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. 
I want to have mount/initialize use the driver=5Fsettings so that you can 
have sticky mount settings, etc.
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)

> RAID=3F Then this should be done on a lower level, I think. Like a 
> driver 
> that publishes a respective device.

Right, yes, I think that was a bad example from me :-)

> > At least we should think about every possible extension we might 
> > want 
> > to add to that piece of code.
> Well, yes, but there aren't that many coming to my mind. :-P

True enough :)

> I should find some hours time today for analyzing and, hopefully, 
> fixing the problem. I was wondering anyway, why this code, that I 
> wrote 
> from the the scratch, was working that quickly without much 
> debugging. 
> ;-)

Yes, that's a nice feeling ;-)

Adios...
   Axel.