Reporting information for the OS

Hiya,

I’ve recently added an extra command to RISC OS Pyromaniac to give information, in system, about the system itself. This is largely to include a place to describe RISC OS Pyromaniac, and the version of Unicorn in use, but it occurred to me that this would be useful to have a standard system command to find out what you’re actually running on.

My simple help command gives me:

Supervisor

*help pyromaniac
==> Help on keyword 'Pyromaniac' (Pyromaniac)
RISC OS Pyromaniac is an alternative implementation of RISC OS. It is focused 
on testing and debugging RISC OS applications and providing an easy way of 
experimenting with interfaces. 

License: RISC OS Pyromaniac is under development, and may be demonstrated to 
individuals in private presentations. It should not be distributed without 
explicit permission being given. 

Copyright © 2019-2023 Gerph.

More information about the project can be found at 
<a href="https://pyromaniac.riscos.online/">https://pyromaniac.riscos.online/</a>
Features of the system are summarised in *PyromaniacFeatures.

System information:
  Host platform:    Darwin/x86_64
  System emulation: Unicorn 2.0
  Python version:   2.7.16 (default, Jun 19 2019, 07:40:37) 

Which reports the host system, and the emulation environment. It doesn’t currently include the CPU type, but this is trivial to include.
I’m already reporting the host system as a part of the OS_Byte 0 response:

*fx0

Error: RISC OS 7.52 (01 Oct 2023) [Pyromaniac 0.52 on Darwin/x86_64] (Error number &f7)

And this is reflected in the values returned by OS_ReadSysInfo 9 (as reported by a short BASIC program):

*readsysinfo
         0 : RISC OS Pyromaniac
         1 : <unset>
         2 : Sun,01 Oct 2023.14:00:00
         3 : Gerph
         4 : <unset>
         5 : <unset>
         6 : RISC OS Pyromaniac
         7 : Darwin/x86_64
         8 : <unset>
         9 : <unset>
        10 : <unset>

http://www.riscos.com/support/developers/riscos6/core/osreadsysyinfo.html with extensions from RISC OS 5 with the hardware platform name in field 7.

With there being multiple variants of RISC OS made (as is expected from an open-source system), it’s important to know things like the supplier and the variant of the OS. This is even more significant with RISC OS Pyromaniac which shares none of the code lineage of RISC OS Classic. So some of the information is available, but not as much as you might wish for many variants.

In particular, with multiple implementations of RISC OS, being clear about what system the user is using is important – RISC OS Pyromaniac, I’ve mentioned, but there’s also Simon Wilcocks’ implementation of some parts of RISC OS and Timothy Baldwin’s version of RISC OS on Linux. Both these latter two variants are still using the bulk of RISC OS Classic, but knowing your environment is important programmatically and for humans.

I believe it’s important to know what your hardware is – or at the very least what the system you’re running is. To a regular user, using *FX 0 won’t be entirely obvious. The same information is available in the Info box in TaskManager, although that isn’t helpful if you don’t have a desktop.

I’d like to propose either a standard *Help command, or just a plain * command which reports the information about the system. I’d like this information to be in a programmatic form, so that it’s easy to extract – the OS_ReadSysInfo 9 ROM information seems kinda appropriate, although it’s a bit of an abuse of the original intent.

I used *Help Pyromaniac because that seemed to be appropriate at the time, but it’s not generic enough for someone to say ‘to get information on the system, use …’ and expect it to work on any modern system.

*Help System might be sensible.

*Help Hardware is probably a little away from what I’m looking for – because the supplier of the OS may not be the supplier of the hardware.

*Help OS might also be choice.

I don’t have any particular thoughts on what I prefer, other than that Hardware is differentiating things in the wrong way. Of course, this could well be implemented by a service for components to declare themselves programmatically, in a similar way to the *Help services, or TaskManager acknowledgements service (to which the system information is orthogonal) – that would then allow a desktop interface to report this information.

Whatever is chosen, I think the form should be relatively standardised, so that it’s easy for users to understand the output. This could be done by using a set of colon-separated fields to make it clear what the definition is and what it means. For example, we might have:

System:       RISC OS 5.40
Supplier:     RISC OS Open
Hardware:     Raspberry Pi 4
CPU:          Cortex-A72
Architecture: AArch32

… on a RISC OS Classic system.

On a RISC OS Pyromaniac system that might be:

System:       RISC OS 7.52
Supplier:     RISC OS Pyromaniac
Hardware:     Darwin/x86_64
CPU:          Generic ARM
Architecture: AArch32

And similarly, a RISCOS-on-Linux system might report…

System:       RISC OS 5.40
Supplier:     RISC OS Open+TBaldwin
Hardware:     Linux 6.3.13
CPU:          Cortex-A72
Architecture: AArch32

Those are just suggestions; I’ve got nothing solid in mind, but would like to open a discussion about how to report this information.

Thoughts and comments?

would be useful to have a standard system command to find out what you’re actually running on.

Good luck with that.

The thinking around here is you shouldn’t need to know what the hardware is and instead just prod gently to see if what you need is available.

Of course, one rule for us and….

RISC OS 7.52

Really? RISC OS Seven?

The thinking around here is you ‘shouldn’t need to know what the hardware is’ and instead just prod gently to see if what you need is available.

That thinking is correct for people writing software, to be able to cope with whatever it thrown at them. But when any software meets the wild, you’re going to see differences. You’re going to see differences when you run a 64bit RISC OS. Some of them, even between different OS versions will matter. As I stated, it is important to be able to communicate what is being used – if a distribution produced by RISC OS Developments or Cloverleaf, or the version running with Simon’s Kernel is used – or RISC OS Pyromaniac, which is obviously my starting point here… you need to be able to say /what/ it is that you’re running. And making a clear way to communicate that to the user is important.

Good luck with that.

And that’s what I’m asking… if people like yourself don’t wish to be involved with that, that’s fine. But yes, that’s what I’m asking.

Really? RISC OS Seven?

Really? You’d not noticed in all the posts that I’ve made, discussions, documentation, etc? I mean it’s only been 3 years since it was made available in the cloud, many presentations, many examples of the system startup :-)

https://asciinema.org/a/275922 – or just go to https://shell.riscos.online/ – it’s right there.

But seriously, it’s not RISC OS 2, 3, 4, 5 or 6. It needs to have a number there. It’s an entirely distinct version of RISC OS, distinct from any other. And this is month 52 of development.

if people like yourself don’t wish to be involved with that, that’s fine.

I guess the sarcasm didn’t make it.

So let me clarify – I think that it is important to have a call to say what the system is. Application writers shouldn’t use it 99.9% of the time, but every once in a while there will be a case where differences do matter; and given that RISC OS is specific to each platform, it makes a hell of a lot more sense for the OS to just bloody well say rather than having people come up with all sorts of horrible hacks like making assumptions based upon the CPUID and/or probing for specific modules (like “BCMVideo” for a Pi), because none of that is particularly future-proof.

Some of them, even between different OS versions will matter.

Certainly. There are various dialects of BASIC. Like GCOL r,g,b or COLOUR OF x ON y and so on. Little things, but BASIC will choke nonetheless. And that’s just the built in language, never mind the entire rest of the OS.
Some of the more technical bits have been stuffed into OS_PlatformFeatures, but that’s more concerned with the low level processor behaviour.

You’d not noticed in all the posts that I’ve made, discussions, documentation, etc?

Nope. ;)

I guess the sarcasm didn’t make it.

I assumed it was sarcasm, and that your lack of any further input meant that you weren’t interested in being involved. Sorry if I misunderstood your intent.

RISC OS is specific to each platform

This should not be true. I know that people consider that it is, but it shouldn’t. Drivers might be, and for the authors of drivers and things that talk to hardware that clearly matters, but the interfaces that you talk to should be abstracted so that – as you say – application writers should not care.
But it does matter, so we should know. It should never be relied on when there is an interface to read it, and there are as you say, many.

Probing for a specific module makes sense only for the RISC OS feature you want to get to.

There are various dialects of BASIC.

Of course, and for BASIC you can at least check the module version. It’d be nice if BASIC offered an introspection to find out what version it was itself, but alas… On the other hand, the probing for the feature is possibly the way to go there.

But I’d like to come up with a way to provide the system information, in a structured manner. At the very least through a user-accessible command, but ideally programmatically. I can propose an interface if people would prefer, but I wanted to raise the question first so that if there’s already something, or someone has better ideas, they can say.

RISC OS is specific to each platform

This should not be true. I know that people consider that it is, but it shouldn’t.

Unlike the x86 world, the ARM boards don’t have any standardised entry points. The video system, the memory handler, the basic I/O (like serial) is god only knows where on each device. It’s only recently that bootloaders have started dealing with device trees on ARM. So for the older sorts of machines (as RISC OS supports), yes, there tend to be different OS images for things like the Pi and OMAP and so on, as poking around random memory locations to see what’s actually there could go wrong.

It’s not good, but the x86 world has some four decades of development and a long history of running OSes not supplied by the computer makers.
ARM, on the other hand, has for most of its life been aimed at embedded style devices with a fixed OS installed by the manufacturer, from the Archimedes to your mobile. So where things are mapped in memory and how to talk to them was not seen as relevant as you’d be running the supplied OS, end of story.
It’s only fairly recently that these little ARM boards have gained enough grunt to take on serious tasks, and people want to choose what OS they put on them. Often the manufacturer either has an official Linux and/or Android which makes things simpler. But, still, the Pi build of Linux isn’t going to boot on my Beagleboard because nothing is in the same place.

So, for now, we have over a half dozen builds of RISC OS and…

but would like to open a discussion about how to report this information.

On RISC OS 5 on my Pi, a quick poke returns:

0 RISC OS 5.29
2 Fri,11 Aug 2023.04:32:45
6 RISC OS 5.29
7 Raspberry Pi 2 Model B

Seems to me that, as you say, it would be useful to have the processor listed there as well. I’m writing this on a Pi 2. It had two processors (spanning two architectures).

Something else that would be useful is to have a return of the platform type/subtype as a number, like one used to be able to obtain from the GPIO module. Knowing a Pi is “2” (for example) and a 2B is, what, about the 4th incarnation?… would be far simpler to deal with programatically than parsing the ID string.

Granted, 99.9% of the time knowing this shouldn’t be necessary. But that’s not really a good reason for not providing the details.

For the user, *Help OS seems good to me. Could alias *Help System to do the same thing, in case a user tries that.

The video system, the memory handler, the basic I/O (like serial) is god only knows where on each device. It’s only recently that bootloaders have started dealing with device trees on ARM. So for the older sorts of machines (as RISC OS supports), yes, there tend to be different OS images for things like the Pi and OMAP and so on, as poking around random memory locations to see what’s actually there could go wrong.

Basically, you need a layer of software to hide all that and present a standardised environment to the OS. Something to hide the hardware.

gerph wrote:

Python version:   2.7.16 (default, Jun 19 2019, 07:40:37)

Come on, really got to sort that out! 4 years since the since Python 2 was abandoned. No excuse now Python 3.11 has eliminated the performance hit.

Come on, really got to sort that out! 4 years since the since Python 2 was abandoned. No excuse now Python 3.11 has eliminated the performance hit.

The excuse is that it’s working, and replacing all the accesses in the system is a non-trivial job. And it’s far more functionally useful to introduce features and fix bugs that exist, than to focus on updating the system to Python 3. I’ll get around to it eventually.

If you’re interested, feel free to have a look and see what you can do. The python3-experiment branch is where I began doing work on moving some of the structures over. It’s very outdated, but the principles are largely the same.

Implementation of the Pyromaniac system aside, I was trying to bring some commonality in the way that the reporting of different systems can be performed.

it’s far more functionally useful to introduce features and fix bugs that exist, than to focus on updating the system to Python 3.

You know, of course, that there are probably legacy bugs lurking.

I’ll get around to it eventually.

An idea that seems to have passed into common use in certain medical equipment circles.
I spent 2 1/2 days last week proving the source of a non-working setup to be what I said it was, about an hour in.
Today I read the email sent by the in-house maintainers and the suppliers that documents the two bugs in the software that is two major and 5 minor revisions out of date.

I could convert a few hundred thousand lines of code, and leave you with some more bugs!

You know, of course, that there are probably legacy bugs lurking.

I could convert a few hundred thousand lines of code, and leave you with some more bugs!

Almost certainly there are, and will continue to be, many many bugs… but this is why having unit and integration tests is so important. Adding tests for things that are discovered is essential as well. Currently, I have 3233 integration tests, which – as I’ve said – is never enough. However, it increases the confidence that any given change produces a consistent result.

So… anyone got any other thoughts on how I should provide this sort of information ? Or should I just implement something and declare it?