Extra OS_ReadSysInfo 9 subreason
Sprow (202) 1155 posts |
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 then as soon as another machine comes along with SD cards it all falls on its face. 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. |
Colin (478) 2433 posts |
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
Or even
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. |
Sprow (202) 1155 posts |
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 only for a 26 bit version of RISC OS 6 to be made. 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. |
Colin (478) 2433 posts |
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. |
Rick Murray (539) 13806 posts |
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.
Yeah, that’s pretty stupid. It should always be preferable to query what is available instead of making assumptions1, 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. 1 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. |
Jeffrey Lee (213) 6048 posts |
Sounds good to me.
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. |