SDFS module

I haven’t searched deeply, but on the face of it, asking for the SDFS private word with osmodule_lookup, then filecore_describe_disc gets the RAM disc record. My routine seems to be OK with the other filecore private words, ADFS, SCSI, RAM.

Is the private word returned different from RAM’s?

Is the FileCore private word the same as the module private word? I thought FileCore handed out its own private words, but I’ve not checked that.

You’re going about this the hard way. SWIs like FileCore_DescribeDisc are intended as an interface to individual FileCore clients (i.e. filing systems) which have already negotiated the exchange of private words between themselves and FileCore. (It so happens that FileCore uses the private words to get direct pointers to the workspace for the relevant instantiation of FileCore, but the API would work just fine if FileCore needed to change that for eany reason, without requiring any incompatible changes to client filing sytems – at least it would do, as long as no application software goes around poking APIs that aren’t any of their business).

The thing you’re missing is that there’s another SWI, SDFS_DescribeDisc, which does what you want but without needing any lookup of handles. Directly equivalent to ADFS_DescribeDisc, SCSIFS_DescribeDisc etc. That’s the one that application software should be using.

@Jon sorry I mislead you, this later routine actually just crashes. The “RAM” result was from an earlier version I think.It doesn’t update the filecore_disc struct after a fail.
Perhaps if I master using the oslib error versions of the ADFS_DescribeDisc family I could avoid that.

@Ben My first version did use the SWI’s you describe,
and I was sure the SDFS one failed. However now I know
there is such an SWI I will try again.
The one thing I /could/ see was the Filecore%SDFS was
present (*modules) so thought my later attempt might
get around there being no working SDFS_DescribeDisc.
I will try it again though and report back.
I’m using RC11 on RasPi BTW.

Edit: actually there is no sdfs.h in oslib 7.0 to support
sdfs_describe_disc

If you’re happy to use _swi/_swix/_kernel_swi, then the name SDFS_DescribeDisc is defined in recent versions of swis.h in the DDE. I’d hope it wouldn’t be too hard for the OSLib maintainers to add support for SDFS though – it’s surely mostly just a search-and-replace on the ADFS support? There’s an API specification for SDFS – as much as it needs one – available here

I have found that I shouldn’t have singled out SDFS as it appears that

sprintf(module_title, “FileCore%%%s”, fstype);
osmodule_lookup(module_title,NULL,NULL,private_word, NULL);
filecore_describe_disc(name,p,private_word);

works fine on Iyonix, but not at all on RasPi.
It can error properly for a non-filecore name though.

Edit: After removing tab characters from my c file I’d brought across with a block copy, this version now runs happily on the RasPi.
I dont know why the rasPi should be singularly intolerant, but thats what happened.
However the previous behaviour where the routine doesn’t effectively put the required FS in the hot seat is apparent again. I think the Filecore module that is in the highest memory (first in the *modules list) takes precedance, so If RAM is unmounted, SDFS is working but prompts to insert a disc when trying for SCSI::4.

SYS&59045,“:0”,buf% (SDFS_DescribeDisc)
is OK and I have found in GCC’s swis.h
extern int _swi (int __swi_no, unsigned int __mask, …);
The first parameter is easy enough, but how do I deal with the second?
I assume the extern int type is to return a fail or success.
Thanks for any help.

I think you’re probably well into the realms of undefined behaviour if you pass invalid values into R8 in the FileCore SWIs.

_swi and _swix are variadic functions – designed that way so that they can support SWIs with all sorts of combinations of input and output registers without their implementation having to know the makeup of each individual SWI. It also means that they can support SWIs that hadn’t yet been defined when _swi and _swix were invented. Instead, the caller has to indicate how many variadic arguments there are in the input and output categories, and it does so via the __mask parameter. Normally for the sake of readability, you’d OR together the _IN(), _OUT(), _INR() and _OUTR() macros to construct the value for __mask. The single parameter to _IN() and _OUT() is a register number, the two parameters to _INR() and _OUTR() are the minimum and maximum (inclusive) numbers of a range of consecutive registers – think of the R as standing for range.

Ben, you are right about me not getting the R8 values correct, I was using private_word as the parameter to suit a compiler error I had earlier on, but I have changed it back to
&private_word and all is well on Raspi now also.
The Iyonix is obviously less sensitive to a range of things, and I’ll always have to test on the Raspi in the future.

I am very keen on getting into the swis.h method though, as a ported source may only need a few swi calls and it can be done without linking oslib.
Your explanation is helping tremendously, thank you.