OS_Module 8 / RMTidy

Should we consider removing this from the OS? It’s never really worked and has a high risk of trashing the machine.

For example:

1. If you have two modules softloaded that claim processor vectors, they can’t release them to allow reinstantiation if they’re called in the wrong order
2. What happens to RMA space that’s claimed but not in a modules’ workspace pointer? There’s correctly no way to notify a module (or app) it’s been moved
3. WIMP Templates in RMA can be a issue
4. Most modules simply aren’t coded to handle being moved, some may reset or fail.

A simple option is to make OS_Memory 8 do nothing and fail silently.

A simple option is to make OS_Memory 8 do nothing and fail silently.

See kernel switch “RmTidyDoesNowt”. It’s been set {TRUE} since RISC OS 3 I think, and definitely RISC OS 4 onwards.

Yeah, *RMTidy has definitely been disabled since at least RISC OS 3.5.

Welcome to 20 years ago!

Would be more useful if RMTidy was changed to be able to remove zombie modules, with a -force option to force kill modules that refuse to die (like DDT after a crash when it still thinks a debugging session is in progress).

I’ll get my coat!

I’ve updated the wiki to say it now does nothing ;)

Would be more useful if RMTidy was changed to be able to remove zombie modules, with a -force option to force kill modules that refuse to die (like DDT after a crash when it still thinks a debugging session is in progress).

Wouldn’t that make more sense as a switch on RMKill? Anyway, there is the DebugTools module in CVS, which has various “kill, no really kill, this module” commands.

I do hope it goes through all the Likely Lists removing anything pointing into the module before doing so (vectors, callafters, voices, etc).

I do hope it goes through all the Likely Lists removing anything pointing into the module

There are a couple of “kill”-type commands, one simply renames the module but leaves it in place so you can let it do whatever it’s doing but still load a new version of it. Another blats the finalisation code offset in the module header with zero before killing it. It’d certainly be a sensible extension of that to do as you suggest – these sorts of commands really are for debug only; you should know what they do and when you’re better off just rebooting! After all, if you don’t remove the stuff off the Likely Lists in the correct order (and you can only guess) then you’ll probably have a crash anyway.

After re-reading my spec from all those years ago, I also realised I’d missed a trick by not replacing the module finalisation offset for the ‘rename module’ command to call a shim that frees the little RMA block it’d allocated before branching to the real module finalisation routine. That’d sort out the little RMA leak it’d cause – but it’s hardly worth the effort, given the circumstances under which you’d be doing this.

given the circumstances under which you’d be doing this

I think you underestimate the number of times I can get a module wrong. :→