Extra OS_ReadSysInfo 9 subreason

A while ago there was a query about reporting specifically which hardware platform you were running on but the proposal suffered from the problem that if you enumerate platforms (in the sense of monotonically allocating one number per platform) then authors inevitably end up writing things like

if (platform == 3) then
  // It’s a BeagleBoard
  load_from_sd_card()
else
  // It’s an Iyonix or Risc PC
  load_from_ide_drive()
endif

So I can understand the reservation ROOL had about exposing this, especially when there’s a more appropriate way to detect the feature (as in this contrived example).

Via the backdoor though that’s started to happen anyway, as I know of at least 1 application which looks for the private GPIO HAL device and infers the platform from the (enumerated) values in the GPIO device. Then new HALs like ARMX6 habitually get allocated GPIO types even though the owner of the GPIO device (the GPIO module) doesn’t support them.

However, for things like submitting fault reports and benchmarking programs it is useful to at least be able to programmatically report the platform.

To that end I’m proposing OS_ReadSysInfo 9, subreason 7 (looks like ROL used subreason 6 for an OS descriptor string, which I suppose could be added and set to “RISC OS” for compatibility) which returns a null terminated string passed through untranslated from the HAL, and since it would be free-form there’s no danger of authors trying to parse the string. For example the Pi might return “BCM2835-B” for a model B, the Risc PC might return “Medusa” – that sort of irregular text.

Obviously anything predating this proposed addition would return an error, so a fallback in the application would need to suggest something generic like “HAL” for platform class 5 and do some other nefarious deductions for everything else. As it’s an OS SWI if that was a major problem it could be added to CallASWI, but I think the number of customers for this subreason can probably be counted on one hand.

In terms of the HAL side, I suggest to recycle private entry point 97 since we know the corresponding kernel would always match up. Converting 97/98/99 into a parallal ATA HAL device, with half an eye that that’ll be needed at some point in future anyway to migrate the parallel ATA platforms (A9Home/Iyonix/Risc PC) towards the new ADFS.

If the reservation against exposing the machine name last time is that you can use it as you illustrate. How does your proposal change things? You could just do

if (platform$ == "BCM2835-B" || platform$ == "BCM2835-A") then
  // It’s a Pi
  load_from_sd_card()
else
  // It’s an Iyonix or Risc PC
  load_from_ide_drive()
endif

Or even

if (platform$ == "BCM2835*") then
  // It’s a Pi
  load_from_sd_card()
else
  // It’s an Iyonix or Risc PC
  load_from_ide_drive()
endif

if I wanted to parse it.

If on the other hand you’re saying people do this anyway so lets do it in a standard way then it’s a good idea.

You could just do [string comparison]

Well yes, my example was rather contrived, perhaps one with “>=” would have been more succinct. It’s the equivalent of doing

RMEnsure UtilityModule 5.00 Echo Must be a 26 bit OS

Providing a string should hopefully hammer home that it’s an arbitrary bit of text not for code to inspect. Querying a private GPIO device (which isn’t even present on all HAL machines we current have) is pretty loopy from an API design perspective.

Providing a string should hopefully hammer home that it’s an arbitrary bit of text not for code to inspect.

People who believe that they can future proof their code by guessing that riscos versions > 5.00 will be 32 bit are also likely to use LEFT$(platform$,7) = “BCM2835” once they discover a pattern in naming pi’s in an attempt to keep their code working on future pi’s without having to change it. In the absence of a feature list from the hal people will use whatever tools are available in any way they see fit.

I do agree however that the bodges caused by the lack of a feature list are irrelevant and if it is useful for programs to know the device that they are on – which it is – then your proposal is a good idea as unlike the numbering system (a) you don’t have to match a number to a name and (b) the same name is always used.

Querying a private GPIO device (which isn’t even present on all HAL machines we current have) is pretty loopy from an API design perspective.

Yes, it is a bodge, but that is down to the even greater loopiness of the API knowing (by necessity) what machine it is running on, but not exposing that to the end user.

then as soon as another machine comes along with SD cards it all falls on its face.

Yeah, that’s pretty stupid. It should always be preferable to query what is available instead of making assumptions¹, however there are valid reasons for wanting to differentiate one machine from another. ROOL itself probably does something like this for the NutPi; also minor API differences can change things in subtle ways. As a vaguely related example, if you cast your mind back to earlier in the year a problem with CallEvery was uncovered and fixed. My server queries the build date string. If later than the fix (or later OS version) then it knows that it can rely upon CallEvery working. If earlier, it will claim TickerV and do the periodic event dispatch itself. Another closer example? I have whinged (a lot) about the annoyance of running IIC transfers with IRQs disabled. This seems to be a Pi thing if I recall, so might necessitate slightly different handling.

¹ You know, like how SDCMOS just assumes what the ROM image is called… Not so helpful to developers that may have several to pick from at any given time.

To that end I’m proposing OS_ReadSysInfo 9, subreason 7 which returns a null terminated string passed through untranslated from the HAL

Sounds good to me.

In terms of the HAL side, I suggest to recycle private entry point 97 since we know the corresponding kernel would always match up. Converting 97/98/99 into a parallal ATA HAL device, with half an eye that that’ll be needed at some point in future anyway to migrate the parallel ATA platforms (A9Home/Iyonix/Risc PC) towards the new ADFS.

HAL_ATAControllerInfo is currently used by the Tungsten and IOMD HALs, so you’d probably need to make sure that the ATA HAL device + new ADFS is rolled out to those platforms before (or at the same time) as the switch over to the platform name string.