Interaction of modules

Hello!
I would like to understand at a conceptual level, how is it in modular systems: may a module to rely on the presence of other modules in the system, or it have to do its job independently, as if it would be the only module in the system (without resorting to any programs assistance [maybe, apart of kernel])?
Thanks.

The ROM is made up of a number of modules and so is a special case: as it is assembled each module within it can link statically to any other module it knows to be part of the ROM build. They do not have to be statically linked though: for example if one particular module is GPL then the other modules in the ROM that require it could use the standard call procedure, e.g. a SWI, to avoid becoming subject to GPL themselves. Or the necessary functionality could be provided in a module supplied on disc and soft-loaded.

The programmes on disc, whether part of the boot process or not, have to use the documented call process for a facility provided by a module (this may be a SWI or a ‘*’ command for example) and may demand a version number to ensure that the module already loaded is (just) sufficiently advanced to provide the facilities it needs, and, if not, to attempt to load a newer module from the path modules$path (or modules:) which points to !Boot.Resources.!System.xxx which would be used henceforth.

Some modules operate by providing a memory address like a ‘jump table’ – the Shared C Library does this – it is provided in ROM (and so cannot move) but a later soft-loaded version may be used. Once this has been soft-loaded (and is therefore now in RAM) a further demand to soft-load it (the same or a newer version, but into RAM at a new address) should not be made as pointers into its first instantiation will then fail.

Hence modules in the ROM can be soft-loaded as later versions for disc-based software but the ROM functions will continue to use the ROM-based versions (where statically linked). Hope this helps!

Thank you Chris.
In bare outlines I understand the answer as such.
 Firstly, a module can use another one (this was my question).
Secondly, the use is possible in two ways.
1.Directly use some code snippets that are in another module. This is possible if:
- The modules are present together in a ROM
  &
- The license allows such use.
2. Through documented calls (SWIs or *Commands). This way is possible without these restrictions.
Is anything misunderstood?… In bare outlines, simplified…

The code snippets as you call them are accessed via SWI calls. It is bad to directly call code – consider what happens if a module is reloaded and its location changes and lots of programs are pointing to the old location… [CLib is a special case, and once a replacement is loaded, you can’t reload it again, for exactly that reason]
In the world of RISC OS, we aren’t usually so anal about licences. If something is documented, it can usually be used. If it is private, it doesn’t get documented…

In the world of RISC OS, we aren’t usually so anal about licences. If something is documented, it can usually be used

In the case of the GPL the anal aspect appears to be sourced elsewhere.
History shows that it’s a bad idea to willy-nilly use GPL code without considering the consequences.

In the world of RISC OS, we aren’t usually so anal about licences. If something is documented, it can usually be used.

Ahem. Wasn’t it that assumption, made by someone near here, which caused a few headaches for the ROOL team when it was applied to the compilation of the RPi disc image last year?

Wasn’t it that assumption, made by someone near here, which caused a few headaches for the ROOL team

I think by the time I handed the image over to the ROOL team, I also handed over a documented trail of permissions for what was included [which had to allow free redistribution to meet Raspberry Pi Foundation needs], other items by then had been removed.

Ahem. Wasn’t it that assumption, made by someone near here, which caused a few headaches for the ROOL team when it was applied to the compilation of the RPi disc image last year?

I was talking specifically about the interaction of modules and calling code in modules. Think – would we accept into the RISC OS world a module that stipulated that it was only to be called/used with other GPL code?

When it comes to linking GPL code in the ROM, and distributing GPL (or other licence) software, it is imperative to verify the ability to distribute and where/when/how. Not just for fulfilling the licence, but basic respect for the author (although, in return, it would be nice if authors specified their terms – this is one of the complications of carrying on work with DeskLib, what exactly is the licence? I would like my branch of 2.30 to be specified as EUPL but I suspect this will mean contacting everybody whose names I can find in the source code…..hmmm…..).

it is a ROM, isn’t it?

It’s a ROM, but you can load into RAM a newer version of the module and the ROM version becomes dormant. Or you can take the ROM module and re-initialise it – the code is still in ROM, but it makes new data structures in RAM. Or the module might have been RAM-loaded (from disc) in which case you can delete it and load a new copy, or simply re-initialise it.

Back in the old days it was a physical ROM that was executed from directly (often more slowly than DRAM). This is still possible (eg with NOR flash) but many boards have their ROM in a non-executable memory section (eg on SD card), so the ‘ROM’ file is copied to RAM before running. But that section of RAM is marked as non-writable.

The static linking that binds together some modules (notably the SharedCLibrary) at ROM build time still works because the ROM is always loaded as one big lump and is never changed¹, while RAM-based code can use newer versions of RAM-based modules. Static linking does not apply to the SWI or vector interfaces, which always indirect via RAM where they can be intercepted and changed. SWIs are the predominant OS API.

¹ There’s a ‘ROMpatch’ mechanism of replacing parts of the ROM with RAM to fix major bugs, but this is pretty much hex-editing the binary. It’s only really important on machines with physical ROMs where changing them is expensive. These days a new ROM image would be issued instead.

Licensing is something of a red herring here. Building ROM images is taken to be static linking, irrespective of how things actually communicate. The GPL indicates that the source of all code statically linked with GPL code must also be made available under the GPL. Therefore putting a GPL component in a ROM image requires that the rest of the image also be GPL, which isn’t possible. So a GPL component can’t go in a ROM image.

A ROM image could be seem as a ‘filesystem of code’ as it was in BBC Micro RFS days, but it generally isn’t. This area is rather poorly understood and influenced by looking at things from a Unix perspective on the part of the FSF.

So the license has no bearing on how things call each other in the ROM, it’s just that code with an incompatible licence doesn’t get in the ROM in the first place.

may a module rely on the presence of other modules in the system

Modules certainly do rely on other modules. This is standard practice. The direct linking of code in ROM ‘modules’ is a regrettable optimisation which should always be avoided by third-party developers.

The primary interfaces between modules are SWIs (semi-direct), Vectors and Service Calls (indirect) and the always problematic jump table (eg ShareCLibrary). Jump tables are bad because modules are defined to be relocatable and replaceable, and jump tables are sufficiently difficult to make relocatable or replaceable that people tend not to bother (eg SharedCLibrary). SharedCLibrary could have been engineered to be better behaved (ie, to be relocated or softloaded) but wasn’t. It is not a good model to follow.

The reason SharedCLibrary uses a jump table is to avoid the overhead of the SWI interface – the triviality of most of the C Library’s calls would be swamped by the SWI interface handling.

All clear. I did not expect such a volume and informative responses. Thank you very much.