Unplug by name, not number

I see a few people have been having problems with different modules unplugged when they upgraded from 5.16 to 1.58. Therefore…

Now that we have much more space available in “CMOS” in all BeagleBoard-family computers, let’s unplug modules by their names instead of their numbers. Then the correct modules should be unplugged regardless of their positions in ROM.

Or what about by SWI chunk number? Should be unique per module (with the exception of things like WimpSWIVe, but such modules surely wouldn’t be in ROM), and is probably a bit easier to code for than variable-length module name strings? On the other hand, a human-readable representation would be nice. No doubt there’s a good reason why this isn’t a good idea. I’ll wait for someone to point it out! ;)

Or what about by SWI chunk number?

The main problem with that idea is that modules do not have to provide SWIs and do not have to have a SWI chunk allocated.

Good point; well made! ;)

Is there a good reason to want to unplug modules? Should we instead consider deprecating this feature?

Unplugging has its uses:
A lot of people use ShareFS (Access) but quite a few configure it off using !Configure this ‘Unplugs’ the module. Maybe this could be changed to being a the setting of a dedicated CMOS bit?
There are other modules that need unplugging in certain circumstances: EtherK on an Iyonix when the motherboard ethernet interface needs to be replaced by a PCI Ethernet card.
I suspect there are other settings as well that need to be set before $.!Boot is run.
But yes an alternative system not relying on module position or name could be implemented.

To be honest, I’m not convinced that the time needed to alter this is worth it over other, more pressing things (willing to be over-ridden by the likes of Jeffrey, however!). It might actually be worth protecting the core modules from being unplugged, but it does open the door for unexpected ramifications.

The Iyo problems could probably have been prevented by a “clear cmos” operation during the update. Is it possible to clear cmos (ie. del-power-on) via a simple swi or two? If so, a suitable BASIC program could be placed on the ROOL site which people could use when updating the OS. This would solve the problem, and ensure a “clean” update.

It might actually be worth protecting the core modules from being unplugged

It is already forbidden to unplug the first 10 or so modules so that even if you do something silly you at least get a command prompt (which you might not be able to type at if you unplugged the keyboard driver, but then delete-power-on would get that back).

unplug modules by their names instead of their numbers

If I’m following the thought process right

• This would abstract the desire unplug a module against its absolute module number (which may change from release to release).
• The module name to number mapping is fixed for a given release.

The conclusion I draw from this is that the name mapping is only important when going from one release to another (or back again), in which case a simple installer could prompt the user which to keep unplugged or not.

In fact such an installer was proposed some time ago, but there are always bigger fish to fry in a time constrained situation.

When we unplug modules from the command line, we do it by name. Exclusively.

One corollary of this is that the code to do so already exists.

The only reason that the record of unplugged modules was kept in CMOS RAM by number was that there simply was not anywhere near enough space to do it by name. That restriction no longer applies.

“not anywhere near enough space to do it by name. That restriction no longer applies.” yes in 2K there is quite a lot of spare space. But modern RTC chips often have no non time related CMOS ram. Our board for the Raspberry Pi does have room for another chip[use embargoed] which just happens to have 256 bytes of CMOS RAM! I’m not convinced fitting an extra 2K EEPROM is worthwhile, when softload CMOS is zero cost, available
and with no downside that I can see.
On balance I’m with Andrew and feel it is a low priority.

I’m suggesting unplug by name for all machines that use a CMOS file as functional equivalent of CMOS RAM.

I too am not convinced of the value of a hardware EEPROM. I think it’s just a commercial opportunity exploited by sellers of RISC OS related stuff.

Dave – I can assure you there’s no commercial gain from my perspective – quite the opposite!