posix: implement uname

[ycsin]

Implementation for posix api: uname

*** Booting Zephyr OS build zephyr-v3.4.0-633-gc38dd60da451 ***

Printing everything in utsname...
sysname[7]: Zephyr
nodename[7]: zephyr
release[9]: 3.4.99
version[61]: zephyr-v3.4.0-633-gc38dd60da451 Jul  6 2023 10:29:50
machine[8]: riscv64


uart:~$ uname -a
Zephyr zephyr 3.4.99 zephyr-v3.4.0-633-gc38dd60da451 Jul  6 2023 10:29:50 riscv64 qemu_riscv64

MacOS as a reference:

(.venv) ycsin-mba:zephyrproject ycsin$ uname -a
Darwin ycsin-mba 22.5.0 Darwin Kernel Version 22.5.0: Mon Apr 24 20:53:44 PDT 2023; root:xnu-8796.121.2~5/RELEASE_ARM64_T8103 arm64

fixes #59924

• update doc/services/portability/posix.rst
• add to the testsuite
• size_t

[cfriedt]

LGTM - just a couple of nits and suggestions.

The sample is good, but it would also be good to add to the testsuite.

One tricky area in particular is the version string.

We actually do want to be fairly consistent here with e.g. the boot banner.

So it would make sense to detect and modify the string such that we can display

• a tagged release (e.g. v3.5.0)
• something commit-ish (IIRC git short ref plus epoch time? I can't remember)
• whether the build is dirty (Linux uses a +, not sure how Zephyr does it)

Of possible, can you please also update doc/services/portability/posix.rst?

Great work! Thanks @ycsin 🚀🪁👍🍍

[cfriedt]

Some compliance fixes..

[cfriedt]

IIRC, we cannot yet build for native_posix. I would suggest filtering CONFIG_ARCH_POSIX in your sample

[ycsin]

We actually do want to be fairly consistent here with e.g. the boot banner.

The version string is the same as the boot banner (I just copied & renamed)

• a tagged release (e.g. v3.5.0)
• something commit-ish (IIRC git short ref plus epoch time? I can't remember)

Should be covered by:

3.4.99 zephyr-v3.4.0-632-gfed4ab1928ba Jul  4 2023 19:01:24

Not epoch time though..

whether the build is dirty (Linux uses a +, not sure how Zephyr does it)

Looks like something to be done in the build system, not sure if @tejlmand has any idea?
I vaguely rmb that we used to have this somewhere..?

[tejlmand]

whether the build is dirty (Linux uses a +, not sure how Zephyr does it)

Looks like something to be done in the build system, not sure if @tejlmand has any idea? I vaguely rmb that we used to have this somewhere..?

Adding -dirty (or anything indicating a dirty build) has been rejected in the past, ref: #13608 (review)

But the use-case / reason for not having -dirty can be handled manually by those who has special needs, as described here:
#39503 (comment)

As people has various ways of working / verifying patches, then I think a wider audience should be invited to discuss if we want to have -dirty (or similar) appended to short sha.
The implementation itself is very trivial, so just a matter of making a decision.

[keith-packard]

the strncpy usage needs to be fixed, otherwise my comments are just suggestions.

[keith-packard]

I think the size of this field can also be computed -- just need to insert the computation of the version string into this header. One less config value to deal with seems like a nice thing.

[ycsin]

We can actually compute everything using preprocessor defines here, at the expense of including 2 more headers & some macro magic then looks a bit complicated

[cfriedt]

The version field can be fixed size as well, technically, too, if we omit the date and time, and it's compatible with the banner version as well.

char version[sizeof("zephyr-v99.99.99-9999-g0123456789ab")];

Ideally we could just include <version.h>, which is generated at build time and use the exact #defines that appear there.

I'm hesitant to do that, just because it really isn't referenced outside of banner.c, which gives me the impression that it's private somehow.

If that makes life easier though, by all means, just

struct utsname {
	char sysname[sizeof("Zephyr")];
	char nodename[CONFIG_POSIX_UNAME_NODENAME_LEN + 1];
	char release[sizeof(KERNEL_VERSION_STRING)];
	char version[sizeof(STRINGIFY(BUILD_VERSION))];
	char machine[sizeof(CONFIG_ARCH)];
};

And honestly, the __DATE__ and __TIME__ macros are probably not super critical.

I would be less hesitant to include <version.h> if it were namespaced properly (e.g. <zephyr/kernel/build_version.h>).

At the same time, there is plenty of time to improve things before v3.5.0, so no need to stall here.

[marc-hb]

__DATE__ and __TIME__ break build reproducibility and should not be enabled by default (not sure what is the current situation)

[ycsin]

Adding -dirty (or anything indicating a dirty build) has been rejected in the past

how about having a separate define to indicate this in "version.h", rather than appending to the hash directly?

[tejlmand]

how about having a separate define to indicate this in "version.h", rather than appending to the hash directly?

Did you read the links ?
Especially: #13608 (review) .

Even if placing this info in a separate define to use in version.h then it will impact the hex file when the repo goes from clean --> dirty (or other way around).

So if this is to be changed, then please open a dedicated issue for discussing, and not in this PR.

[cfriedt]

One minor change request

[cfriedt]

So if this is to be changed, then please open a dedicated issue for discussing, and not in this PR.

@tejlmand - I believe @ycsin's changes have addressed your concerns, and with a couple of small changes, I'm ready to approve. Can you take a look again to ensure that your concerns were addressed?

[cfriedt]

@keith-packard - does this one look OK to you now?

[cfriedt]

@ycsin - I'm OK getting 1 more approval for this and merging if you wouldn't mind a follow-up PR for namespacing <version.h> as <zephyr/kernel/banner_version.h> or something along those lines.

[keith-packard]

Yeah, given the concerns about mixing too many bits into the application namespace, having compile-time checks that make sure the sizes are big enough seems good enough here.