OLD_1002_ATTRIBUTE and VM_TARGET_OS

[dcstes]

The function getAttributeString() in sqUnixMain.c has, since end of March 2025, a C preprocessor (cpp) variable OLD_1002_ATTRIBUTE.

When set, the old code that returns VM_TARGET_OS is used.

If not set, the function will do a malloc() and allocate space from the heap to store the platform dependent results from uname() as defined by the operating system in <sys/utsname.h>.

This is in commit e6108a0 .

[dcstes]

VM_TARGET_OS is set by the configure script from $ac_cv_target
I think $target_os is from the GNU autoconf target=$ac_cv_target

[eliotmiranda]

The function getAttributeString() in sqUnixMain.c has, since end of March 2025, a C preprocessor (cpp) variable OLD_1002_ATTRIBUTE.

When set, the old code that returns VM_TARGET_OS is used.

If not set, the function will do a malloc() and allocate space from the heap to store the platform dependent results from uname() as defined by the operating system in <sys/utsname.h>.

This is in commit e6108a0 .

Thank you David. I must have made some mistake in that new code. I think it is the right idea but I must have implemented it incorrectly. If you ca review it please do. I'll see what I can find.

[eliotmiranda]

I think this is fixed with 28712a3.
Please review.

[dcstes]

Why do you prefer an implementation based on uname() at runtime, please ? The code in the past was using a GNU configure implementation at build time (compile time) when VM_TARGET_OS was computed by the GNU configure script, and not by the sqUnixMain.c file at runtime. Anyway this issue is not urgent for me, as you provided a OLD_1002_ATTRIBUTE workaround so the GNU configure based implementation can be selected by setting OLD_1002_ATTRIBUTE . However the name "OLD_1002_ATTRIBUTE " suggests you'd like to migrate to a new approach by using uname() and a runtime computation ... I'll close this issue for now as I'm fine with whatever you prefer, it's just that I was surprised by the change.

[eliotmiranda]

Why do you prefer an implementation based on uname() at runtime, please ? The code in the past was using a GNU configure implementation at build time (compile time) when VM_TARGET_OS was computed by the GNU configure script, and not by the sqUnixMain.c file at runtime.

For consistency with the other major platforms, macOS and Windows. On those platforms vm attribute 2002 answers the version of the current OS, /not/ the OS on which the VM was built. Having information on the underlying OS is much more important (e.g. selecting the correct name of the libc library file when using qsort) than info on where the VM was built (which can be inferred from other info).

[dcstes]

But initially in #713 I thought you said that there was no change related to UNIX, which is contradicted by the modification of sqUnixMain.c. If you have clear ideas about why you want to make such a change, you can always please clearly indicate this in the git history. I am reopening this issue, because perhaps the "configure" script could be modified to automatically set OLD_1002_ATTRIBUTE. Or perhaps the code could be written in such a way that there is a DO_NOT_USE_AUTOCONF_FOR_1002_ATTRIBUTE which can be set to not use the GNU autoconfigure code for VM_TARGET_OS ?

[eliotmiranda]

I was wrong to say it didn't touch unix. I didn't see that what I thought was a trivial change was in fact capable of crashing the VM. However, I do think it is a needed change. Can we just accept that and move on? The fixed code is good right?

[dcstes]

the new code is not equivalent to the code that is enabled by setting OLD_1002_ATTRIBUTE

on the squeak wiki the getSystemAttribute is documented at

https://wiki.squeak.org/squeak/314

"1002 - specific OS type: "linux-gnu" or whatever 'configure' provides as host_os on unix"

the GNU autoconf configure helps to support various Unix and Linux operating systems and distributions with slight differences; the VM_TARGET_OS reports what configure defined.

[eliotmiranda]

the new code is not equivalent to the code that is enabled by setting OLD_1002_ATTRIBUTE

I know and that’s by design. As I said before the old way doesn’t agree with the other platforms and isn’t useful.

on the squeak wiki the getSystemAttribute is documented at

https://wiki.squeak.org/squeak/314

"1002 - specific OS type: "linux-gnu" or whatever 'configure' provides as host_os on unix"

That says that 1002 should reflect the host is not the build os, which is what the new code does. Right?

the GNU autoconf configure helps to support various Unix and Linux operating systems and distributions with slight differences; the VM_TARGET_OS reports what configure defined.

[dcstes]

tested on openSUSE Linux Leap 15.4 and Leap 15.6 on AMD Ryzen 7 cpu :
if OLD_1002_ATTRIBUTE=1 you get something like linux-gnu as defined by configure
if OLD_1002_ATTRIBUTE is not set, then "Linux 5.14.21 ..." for openSUSE 15.4 and "Linux 6.4.0 ..." for openSUSE 15.6
It depends on whether users of the osVersion message want to have both system identified as "linux-gnu" or whether they need a specific kernel version.
Perhaps the getSystemAttribute mechanism can it be extended please for new attributes like 1010,1011,1012 for the various individual fields of uname utsname structure ?
The utsname structure may have additional info and fields such as domainname.

[dcstes]

I am not convinced this change is an improvement.

If I test on Linux OpenSUSE Tumbleweed (Linux on AMD64), I changed the code to break down the uname() structure utsname in individual system attributes so that:

Smalltalk getSystemAttribute:1010

could return the value 'Linux' and

Smalltalk getSystemAttribute:1011

could return the value '6.14.2-1-default' (the field release in the struct utsname).

Smalltalk getSystemAttribute:1002

would still return 'linux-gnu' as it was before and as provided by the GNU configure script at build time.

In any case, the strcat() concatenation can be done in the Smalltalk image using Smalltalk code where two system attributes can be used to create a new object by manipulating other system attributes objects in Smalltalk code.

Also looking at the C code, it seems that in the case of uname() returning a negative value, it currently returns VM_TARGET_OS while a failure of uname() is some sort of exception or error where it is not possible to determine the running operating system.