Add os_type and os_version keys to erlang:system_info/1 #1117

UncleGrumpy · 2024-03-10T21:50:14Z

Adds support for erlang:system_info/1 keys os_type and os_version for obtaining a conveniently parse-able semantic version of the operating system (or runtime environment) the VM is running on.

These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

bettio

I don't agree about this change, os module is used for this purpose.
e.g.

os:version().
{6,5,0}

os:type().
{unix,linux}

UncleGrumpy · 2024-04-02T20:48:17Z

That makes perfect sense. For some reason it did not occur to me that there was already an appropriate OTP function to get this information.

Just curious what the os:type() return for various MCUs should be? It seems like stm32 should be: {generic, libopencm3} and for esp32 maybe: {rtos, esp-idf} or {generic, esp-idf}? Since the intention is to know which version of an SDK is used, to help determine supported API functions.

bettio · 2024-04-05T21:09:23Z

That makes perfect sense. For some reason it did not occur to me that there was already an appropriate OTP function to get this information.

Just curious what the os:type() return for various MCUs should be? It seems like stm32 should be: {generic, libopencm3} and for esp32 maybe: {rtos, esp-idf} or {generic, esp-idf}? Since the intention is to know which version of an SDK is used, to help determine supported API functions.

Good question.

My 2 cents: both macOS and Linux have {unix, Something} as os type, as they are both implemented using generic_unix, hence every different platform kind should be mentioned as first tuple member, and the specific type should be the second tuple member. But I'm not really sure.

UncleGrumpy · 2024-04-14T15:33:47Z

So I have looked into how os:type and os:version are implemented in OTP. They both are wrappers for erlang:system_info, using the keys os_type and os_version. I am undecided if I should add a minimal os module with wrapper function's, or just implement the system_info keys. The only advantage I see in adding the module is that we can have documentation for the os functions, since they may be returning values that differ from the OTP returns, specifically the os family has more options than just unix | win32. I already have the basic functionality implemented for esp32, stm32 and rp2040, and am currently working on implementation for generic_unix.

bettio · 2024-04-14T22:02:20Z

Let's keep this PR small and let's just add erlang:system_info(os_type) and erlang:system_info(os_version).

So, let's recap:

we are not going to introduce os module with this PR
no esp_idf_* specific options, we are going to rely on default options
it will be possible to use os_version for retrieving esp-idf version as a tuple (so no need for esp_idf_major/minor/patch options)
I think that the first tuple component should be the platform name, similar to the ones we use in 'src/platforms' (they don't need to be exactly the same).

UncleGrumpy · 2024-04-16T00:50:31Z

Support for erlang:system_info/1 keys os_type and os_version is added for all platforms except WASM, I am not familiar enough with the port to be able to determine the node version, or detect the browser and version depending on how it's deployed, but that might be interesting for someone to add in a future PR.

bettio · 2024-04-20T20:36:37Z

src/platforms/stm32/cmake/version_from_git.cmake

+  set( IDE_VERSION_MINOR ${ide_version_minor} PARENT_SCOPE)
+  set( IDE_VERSION_PATCH ${ide_version_patch} PARENT_SCOPE)
+
+endfunction( version_from_git )


Missing new line at the end of file.

bettio · 2024-04-20T20:41:46Z

src/platforms/stm32/cmake/version_from_git.cmake

+  # Find Git
+  find_package(Git)
+  if(!Git_FOUND)
+    message( FATAL_ERROR "Git not found" )


This would make unsupported source only releases (without a .git directory). Am I right?

I did not consider that specific possibility, but there is no way exposed from libopencm3 to determine the version used for the build. If a source code release of libopencm3 was used, then the version returned would be {undefined,undefined,undefined}.

bettio · 2024-04-20T20:51:44Z

CHANGELOG.md

@@ -10,6 +10,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0

 - Added experimental optimized GC mode that makes use of C realloc instead of copying data around,
 it can be enabled with `-DENABLE_REALLOC_GC=On`.
+- Added support for `erlang:system_info/1` keys `os_type` and `os_version`.


Let's change this since v0.6.1 has been released.

bettio · 2024-04-20T20:57:40Z

doc/src/programmers-guide.md

+* `esp_idf_semantic` Returns a tuple containing `{Major :: integer(), Minor :: integer(), Patch :: integer()}`.
+* `esp_idf_major` Returns the major version number as an integer.
+* `esp_idf_minor` Returns the minor version number as an integer.
+* `esp_idf_patch` Returns the patch version number as an integer.


I think they have been removed, let's remove them also from the doc.

bettio · 2024-04-20T21:02:22Z

src/platforms/rp2040/src/lib/CMakeLists.txt

+add_compile_definitions(OS_VERSION_MAJOR=${PICO_SDK_VERSION_MAJOR})
+add_compile_definitions(OS_VERSION_MINOR=${PICO_SDK_VERSION_MINOR})
+add_compile_definitions(OS_VERSION_PATCH=${PICO_SDK_VERSION_REVISION})
+


let's double-check. @pguyot are you aware of a cleaner approach?

I couldn't find anything better, it looks like the usual approach.

Also, we may want an additional avm_ or atomvm_* key for the chip versions. Pico SDK has functions to query chip and rom versions. This could be in another PR.

Also, we may want an additional avm_ or atomvm_* key for the chip versions. Pico SDK has functions to query chip and rom versions. This could be in another PR.

This would be good. Perhaps at the same time the ESP32 key esp_chip_info should be renamed, so that both (and eventually other) platforms can use the same key?

But maybe that kind of breakage needs to be based on main (0.7.0)? Or add a deprecation warning and support both versions of the key on esp32 for a cycle...

bettio · 2024-04-20T21:16:38Z

src/platforms/generic_unix/lib/sys.c

+        const char *freebsd_os = "FreeBSD";
+        const char *openbsd_os = "OpenBSD";
+
+        if (strcmp(buf.sysname, linux_os) == 0) {


Let's rather write if (strcmp(buf.sysname, "Linux") == 0) {, I think it is more readable.

bettio · 2024-04-20T21:28:09Z

src/platforms/generic_unix/lib/sys.c

+            return ERROR_ATOM;
+        }
+        p = buf.release;
+        while (*p) {


If for any reason any operating system has something like 1.2.3.4 as version number we get a stack corruption, that might be super hard to find (int ver[3];).

I fixed this. I wanted to stick to OTP compliance here which is specific about returning {Major, Minor, Patch}, so for your example OS that has a version 1.2.3.4 the return will be {1.2.3}.

pguyot · 2024-04-25T05:51:58Z

doc/src/programmers-guide.md

@@ -612,6 +612,9 @@ For more information about Erlang external term format, consult the [Erlang Docu

 You can obtain system information about the AtomVM virtual machine via the [`erlang:system_info/1`](./apidocs/erlang/estdlib/erlang.md#system_info1) function, which takes an atom parameter designating the desired datum.  Allowable parameters include

+* `os_type` The operating system or runtime environment.
+* `os_version` The sematic version of the currently running operating system or runtime environment.
+* `system_architecture` The processor architecture and OS release (as a binary string).


This didn't make it :-)

Right, I didn't add that for Pico, I just noticed it was completely missing from the docs and didn't want to forget to add it, but Pico support for this key would be good to add.

I realized this is currently only implemented on generic_unix, so I removed the entry (It should probably have been added in a separate PR anyway). The edocs incorrectly state it is supported on all systems, I will put in a separate PR to correct that to list it as only supported on generic_unix, until support has been added for other platforms.

Adds support for `erlang:system_info/1` keys `os_type` and `os_version` for obtaining a conveniently parse-able semantic version of esp-idf the VM is built with. Adding `os_type`, which currently will return `{esp32, esp-idf}` is mainly for completeness, but could be helpful to differentiate, if future ports end up supporting esp32, such as zephyr or nuttx. Signed-off-by: Winford <winford@object.stream>

Adds support for `erlang:system_info/1` keys `os_type` and `os_version` for obtaining a conveniently parse-able semantic version of libopencm3 the VM is built with. Adding `os_type`, which currently will return `{stm32, opencm3}` is mainly for completeness, but could be helpful to differentiate, if future ports end up supporting stm32, such as zephyr or nuttx. Signed-off-by: Winford <winford@object.stream>

Adds support for `erlang:system_info/1` keys `os_type` and `os_version` for obtaining a conveniently parse-able semantic version of pico-sdk the VM is built with. Adding `os_type`, which currently will return `{rp2040, pico-sdk}` is mainly for completeness, but could be helpful to differentiate, if future ports end up supporting the rp2040 platform, such as zephyr or nuttx. Signed-off-by: Winford <winford@object.stream>

Adds support for `erlang:system_info/1` keys `os_type` and `os_version` for obtaining a conveniently parse-able semantic version of the operating system the VM is running on. The `os_type` key which currently will recognize `linux`, `darwin`, `freebsd`, and `openbsd`, other sytems will return `unknown` atom as the `Osname` in `{Osfamily, Osname}`. Signed-off-by: Winford <winford@object.stream>

Adds edoc and "Programmers Guide" documentation for `os_type` and `os_version` keys that have been added to `erlang:system_info/1`, and adds entry to CHANGELOG.md Signed-off-by: Winford <winford@object.stream>

bettio requested changes Apr 2, 2024

View reviewed changes

UncleGrumpy force-pushed the get_idf_vers branch from 103dd70 to f8d1cca Compare April 15, 2024 18:35

UncleGrumpy changed the title ~~Adds new keys to erlang:system_info/1 for ESP-IDF semantic version~~ Add os_type and os_version keys to erlang:system_info/1 Apr 15, 2024

UncleGrumpy force-pushed the get_idf_vers branch 3 times, most recently from a7f0ca6 to 6c3d51d Compare April 15, 2024 19:02

UncleGrumpy mentioned this pull request Apr 20, 2024

Support DragonFly BSD #1133

Merged

bettio requested changes Apr 20, 2024

View reviewed changes

UncleGrumpy force-pushed the get_idf_vers branch 4 times, most recently from e997854 to 6c2bcdf Compare April 22, 2024 19:22

UncleGrumpy requested a review from pguyot April 25, 2024 04:53

pguyot reviewed Apr 25, 2024

View reviewed changes

UncleGrumpy force-pushed the get_idf_vers branch from 6c2bcdf to c215c13 Compare April 25, 2024 15:17

UncleGrumpy added 5 commits May 25, 2024 14:48

Update changelog and docs with new erlang:system_info keys

94b3818

Adds edoc and "Programmers Guide" documentation for `os_type` and `os_version` keys that have been added to `erlang:system_info/1`, and adds entry to CHANGELOG.md Signed-off-by: Winford <winford@object.stream>

UncleGrumpy force-pushed the get_idf_vers branch from c215c13 to 94b3818 Compare May 25, 2024 21:49

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add os_type and os_version keys to erlang:system_info/1 #1117

Add os_type and os_version keys to erlang:system_info/1 #1117

UncleGrumpy commented Mar 10, 2024 •

edited

bettio left a comment

UncleGrumpy commented Apr 2, 2024

bettio commented Apr 5, 2024 •

edited

UncleGrumpy commented Apr 14, 2024

bettio commented Apr 14, 2024

UncleGrumpy commented Apr 16, 2024

bettio Apr 20, 2024

UncleGrumpy Apr 21, 2024

bettio Apr 20, 2024 •

edited

UncleGrumpy Apr 21, 2024

bettio Apr 20, 2024

UncleGrumpy Apr 21, 2024

bettio Apr 20, 2024

UncleGrumpy Apr 21, 2024

bettio Apr 20, 2024

pguyot Apr 25, 2024

UncleGrumpy Apr 25, 2024 •

edited

UncleGrumpy Apr 25, 2024 •

edited

bettio Apr 20, 2024

UncleGrumpy Apr 21, 2024

bettio Apr 20, 2024

UncleGrumpy Apr 21, 2024

pguyot Apr 25, 2024

UncleGrumpy Apr 25, 2024

UncleGrumpy Apr 25, 2024

Add os_type and os_version keys to erlang:system_info/1 #1117

Are you sure you want to change the base?

Add os_type and os_version keys to erlang:system_info/1 #1117

Conversation

UncleGrumpy commented Mar 10, 2024 • edited

bettio left a comment

Choose a reason for hiding this comment

UncleGrumpy commented Apr 2, 2024

bettio commented Apr 5, 2024 • edited

UncleGrumpy commented Apr 14, 2024

bettio commented Apr 14, 2024

UncleGrumpy commented Apr 16, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bettio Apr 20, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

UncleGrumpy Apr 25, 2024 • edited

Choose a reason for hiding this comment

UncleGrumpy Apr 25, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

UncleGrumpy commented Mar 10, 2024 •

edited

bettio commented Apr 5, 2024 •

edited

bettio Apr 20, 2024 •

edited

UncleGrumpy Apr 25, 2024 •

edited

UncleGrumpy Apr 25, 2024 •

edited