Image filesystems and C

I want to write an image filesystem in C for future inclusion in the OS. Is it safe to base it off DOSFS for the core Image FS functionality?

I ask because Image FS requires jump table entry points and I note DOSFS implements them with embedded assembler. Is that acceptable in a modern C Module, when we’re trying to get away from assembler in the OS?

That’s no more than a table of function addresses. That can be done in C, can’t it?

I think the question revolves around how and when the C environment is set up, and what that messes with.

how and when the C environment is set up

Quite. Parts of the OS do not call C Modules appropriately – something that I feel needs correcting before the OS can migrate to C without nasty hacks in Modules that have entry points outside of the main ones.

If Dave is correct, what is the C way of setting up a jump table and how do you handle the registers to allow switching in/out of C? Are there a CLib functions for it?

Take a look at DOSFSctl in DOSFS to see what I’m referring to about embedded assembler.

I think the preferred way of doing things is to try and use CMHG generic veneers for any low-level entry points. For file systems, I guess you’d end up with 8 different CMHG veneers – one for each of the entry points required in the FS information block.

In some cases you might need to wrap the veneer in a small bit of assembler, e.g. to shuffle registers around into the ones that the CMHG will capture in the _kernel_swi_regs. E.g. it’s not an image filing system, but CDFSSoftSCSI has a tiny bit of assembler to map calls from CDFS to the CMHG veneer: https://gitlab.riscosopen.org/RiscOS/Sources/HWSupport/CD/CDFSSoftSCSI/-/blob/master/s/handler#L35

Here’s how to create a filesystem in C.

cmhg:

generic-veneers: fsentry_open fsentry_getbytes fsentry_close fsentry_file fsentry_func

c:

#include "AsmUtils/rminfo.h" /* Image_RO_Base */

  uint32_t info[] =
  {
    (uint32_t) (FILING_SYSTEM_NAME - Image_RO_Base),
    (uint32_t) (Module_Title - Image_RO_Base),
    (uint32_t) ((const char *)fsentry_open - Image_RO_Base),
    (uint32_t) ((const char *)fsentry_getbytes - Image_RO_Base),
    0, /* putbytes */
    0, /* args */
    (uint32_t) ((const char *)fsentry_close - Image_RO_Base),
    (uint32_t) ((const char *)fsentry_file - Image_RO_Base),
    FILING_SYSTEM_NUMBER | fsinfo_readonly,
    (uint32_t) ((const char *)fsentry_func - Image_RO_Base),
    0
  };
  e = _swix(OS_FSControl, _INR(0,3), FSControl_AddFS, Image_RO_Base,
      ((char *)&info) - Image_RO_Base, pw);

That’s for Norcroft. If you’re using gcc, then Image__RO_Base is provided by the cmunge header.

Obviously you’ll need to use slightly different entry points in the table for an image filing system.

You could do worse than to have a look at the source code of three FS implementations that are mostly non-assembler: Fat32FS, LayerFS and Memphis. I think LayerFS is C++ with a minimal ASM wrapper because of CMHG shortcomings.

Didn’t CMunge have some interesting feature that CMHG lacked?

To be clear, I’m not asking how to write a filesystem.

I was asking how to handle entry/exit from the OS into C without nasty assembler hacks – I have a distinct aversion to hacks. If the way DOSFS implements it in DOSFSctl is the only way, something is very wrong with the way C Modules are handled by the OS.

DOSFS has more assembler in the form of wrappers than I’d actually need to implement the whole Image FS in assembler, that seems counter intuitive.

DOSFS dates from ~1990 which is roughly the bronze age in terms of RISC OS toolchain, so I wouldn’t use it as an example of anything really. Something more modern is probably better, although I can’t recommend anything.

Didn’t CMunge have some interesting feature that CMHG lacked?

cmunge has support for vector traps and printer driver entry points and various other things, but I’m not seeing support for filing system entry points. Perhaps it needs adding (to both CMHG and CMunge)?

DOSFS dates from ~1990 which is roughly the bronze age in terms of RISC OS toolchain, so I wouldn’t use it as an example

Noted, DOSFS is not a good example to build other Image Filesystems from.

Perhaps it needs adding (to both CMHG and CMunge)?

You’ll have to excuse my ignorance, but given all the discussion around moving the OS to C, would it not be prudent to add a Module flag for C Modules and have the OS handle the translation – not the Module itself? At some point calls to C Modules will be coming from an C based OS source, at which point isn’t the current translation code in the Modules going to be potential problem?

Looking at the online CMHG documentation I note it states this for the IRQ handler entries:

* ‘r’ points to a vector of words containing the values of r0-r9 on
* entry to the veneer. Pure IRQ handlers do not require these, though
* event handlers and filing system entry points do. If r is updated,
* the updated values will be loaded into r0-r9 on return from the
* handler.

That implies Filesystem entries should be declared as IRQ handlers in CMHG?

That implies Filesystem entries should be declared as IRQ handlers in CMHG?

Now you mention it, I think that’s what’s traditionally been done. The absence of any other option meant IRQ handlers got abused for various other things that weren’t to do with IRQs.

You’ll have to excuse my ignorance, but given all the discussion around moving the OS to C, would it not be prudent to add a Module flag for C Modules and have the OS handle the translation – not the Module itself? At some point calls to C Modules will be coming from an C based OS source, at which point isn’t the current translation code in the Modules going to be potential problem?

I think that’s a bigger question, in that ABIs typically change – the ABI for an AArch64 call is going to be very different from an AArch32. I agree we shouldn’t need these shims – should just be able to call from C to C, and the registers should be set up for that. But also that these shims do provide a function in that they decouple the ABIs from each side of the interface: maybe once upon a time the C ABI was diffeent – APCS_A(rthur) springs to mind – and, by nailing down the registers in the FS API and then shimming before landing in the C, such code would still work (either way round) even if the ABI has evolved.

The absence of any other option meant IRQ handlers got abused for various other things that weren’t to do with IRQs.

These days – as Julie shows – you can use generic-veneers rather than abusing the IRQ one.

Kind of wish the source to CMHG was available so one could see what it actually does without having to disassemble and/or guess. Not to mention extend if desired.

Yes. Reading the docs for CMunge shows that it has the very useful (to me, at the moment) printer-entry: keyword. That should be in CMHG too, even if it’s only useful to very few people.