XXFSFiler replacement

The “Filer enhancement” thread diverged into discussing the iconbar icon providing “XXFSFiler” modules. As they are totally separate from the Filer itself, I thought it’d be nice to have a different thread to discuss this topic.

Sprow said:

I believe there’s likely to be an SDFS for flash memory cards being conceived, and inevitably that’ll need an SDFSFiler to do its icon bar icon and stuff. In my analysis of the filing system roadmap one common complaint was that every vendor of every filing system has to endlessly reinvent their own ThingFSFiler.
Currently, most ROMs already contain ADFSFiler; SCSIFSFiler; RAMFSFiler; ResourceFSFiler and that’s just in ROM! No doubt SDFSFiler is also going to be needed.
Putting together a spec for one generic one so those 4 (soon 5) can be chucked away would be amazing. My random thoughts would be
• Multiplee instaniatable
• Maybe configured by a text definition like a message file, or maybe a SWI with some flags
• Or maybe scans FileSwitch for known filing systems at startup and clones itself based on a table
• Needs to have the superset of features – formatting menus, share menus, rename, quit, free – but can be selectively removed depending on the FS
• Deal with drives that come and go, like USB does

Steffen said:

And don’t forget CDFSFiler.

Sprow:

Indeed I had. So there’d be a total of 6 ThingFSFilers in ROM, all basically doing the same thing over and over again.

And I say: Yes to all of the above.

If we went down the route of having one multi-purpose xxxFiler module then it’s potentially a good candidate for writing in C++ (hello, Terje! ;-)). You could have one base class that handles all the generic filer functionality, and then one derived class for each filing system which implements all the FS-specific functionality (drive detection, extra menu items, etc.).

Third-party filing systems could be supported by an extra derived class which exports all the required functionality via a SWI interface or function pointer table.

Unfortunately, I’m not sure whether Norcroft supports modules written in C++. But since everything will have to boil down to a SWI/function pointer interface maybe it wouldn’t be too hard to write it in C (i.e. the standard filing systems would go via the function/SWI interface internally instead of being a direct subclass of the base class)

Multiplee instaniatable

Are there any advantages of having the module multiply instantiated?

Norcroft converts C++ to C, so it should be able to make C++ modules no different from C modules (#include < std_cfront_woes.here >). GCC can cope with C++ modules (things start getting more interesting if you use templates etc).

However the issues is whether the interface would be a binary one, or a C++ class. RISC OS has been traditionally written with binary interfaces (ie you don’t get the source, just the register in/out definitions), while C++ will mean that you get some of the source (the class header for the base class, at least) and it’s going to be harder to work without access to more of the source. Depends what you want, really.

Are there any advantages of having the module multiply instantiated?

Possibly not, it just felt like the right thing. If there’s not that much state per icon then a linked list and a bit of malloc from the RMA would do too.

Norcroft converts C++ to C, so it should be able to make C++ modules no different from C modules

Ah yes, I’d forgotten about that.

However the issues is whether the interface would be a binary one, or a C++ class.

I was thinking of it being a binary interface, mainly to provide some protection against everything breaking if the internal class structure changes. The builtin code to deal with the standard filing systems would be able to use the class interface directly, but all third-party filing systems would go via a class that translates from the class representation to a more standard/stable binary one.

Are there any advantages of having the module multiply instantiated?

Possibly not, it just felt like the right thing. If there’s not that much state per icon then a linked list and a bit of malloc from the RMA would do too.

The way I see it, it would be better to have just the one instance. Assuming we’re trying to put as much workspace as possible into the Wimp pool, memory wasteage should be lower with just the one instance. And for any service call/wimp message handlers it should be (slightly) quicker to have one module that processes a list of message recipients internally than to have multiple modules that only contain one recipient.

The only downside I can think of is that if it crashes you’d lose all of your filers instead of just the one.

A feature request for the new XXFSFiler – use different iconbar icons for whether a drive is mounted or not. This will help people work out whether it’s safe to eject discs, unplug USB devices, etc.

A feature request for the new XXFSFiler – use different iconbar icons for whether a drive is mounted or not. This will help people work out whether it’s safe to eject discs, unplug USB devices, etc.

That’s a good idea – if we can trust it. The example I have in mind is Fat32FS, which, despite all its good points, still sometimes needs to be dismounted twice (possibly even three times – I can’t be sure) before the drive really is dismounted. If an FS cannot be guaranteed to dismount on command, I don’t know how the XXFSFiler can extract valid information about the mount status.

The example I have in mind is Fat32FS, which, despite all its good points, still sometimes needs to be dismounted twice (possibly even three times – I can’t be sure) before the drive really is dismounted.

I find on the Iyonix, any usb device (external card reader for example) needs to be dismounted twice, even if being accessed via usb scsifs.

I find on the Iyonix, any usb device (external card reader for example) needs to be dismounted twice, even if being accessed via usb scsifs.

I’ve spotted that problem myself. I’m not sure whether it’s a general issue with USB devices or just something limited to DOSFS.

That’s odd, I’ve never noticed that. I’m using an Iyonix with latest ROM softloaded and FAT32FS to read a USB memory stick.

How would you know if a dismount has failed? The iconbar icon showing the disc name instead of “:0” ?

How would you know if a dismount has failed?

Usually when you put the same device back in, having changed it’s contents. You get a message about ambiguous disc name or something. I am so brainwashed into dismounting twice for years that I cannot remember the words in the message.

ambiguous disc name

Aha, I didn’t know that could be bypassed my multiple dismounts!

dismounted twice

FileCore has some heuristics that on first dismount it just flushes the pending data to disc but still keeps the disc in its list of known ones, the second dismount (assuming the disc hasn’t been seen inbetween) dumps it from that list.

It’s not clear what SCSIFS is doing differently to give so many ambiguous discs, maybe not using the “eject works” flag right, but there’s a useful debug switch in FileCore to help (‘debugo’) see.