hardcoded version and date in uname

[andrewdavidmackenzie]

My first exploration was running uname -a and having a look at the source for it.

I noticed that the version number reported ("4.2.3") and the date are both hardcoded in the function:

pub async fn sys_uname(uts_ptr: TUA<OldUtsname>) -> Result<usize> {
    let mut uts = unsafe { mem::zeroed::<OldUtsname>() };

    let sysname = c"Moss".to_bytes_with_nul();
    copy_str_to_c_char_arr(&mut uts.sysname, sysname);

    let nodename = CString::from_str(&hostname().lock_save_irq()).unwrap();
    copy_str_to_c_char_arr(&mut uts.nodename, nodename.as_c_str().to_bytes_with_nul());

    let release = c"4.2.3".to_bytes_with_nul();
    copy_str_to_c_char_arr(&mut uts.release, release);

    #[cfg(feature = "smp")]
    let version = c"#1 Moss SMP Tue Feb 20 12:34:56 UTC 2024".to_bytes_with_nul();
    #[cfg(not(feature = "smp"))]
    let version = c"#1 Moss Tue Feb 20 12:34:56 UTC 2024".to_bytes_with_nul();
    copy_str_to_c_char_arr(&mut uts.version, version);

    let machine = CString::new(ArchImpl::name()).unwrap();
    let machine = machine.to_bytes_with_nul();
    copy_str_to_c_char_arr(&mut uts.machine, machine);

    copy_to_user(uts_ptr, uts).await?;

    Ok(0)
}

So, I wondered:

• How does the version numbering work?
• The number doesn't seem to match that in any of the Cargo.toml, and it looks like they are not modified.
• Do you plan to do releases using GitHub?
• Would you appreciate some contribution in this area:
  • Using one of the Cargo.toml version numbers in the code from Cargo variables, not hardcoded
  • Similar with date
  • Maybe require a simple build.rs to generate the date (not sure)
  • Some work on automation of releases in GH via GH Actions
• Will require a bit of guidance on how you'd like releases done and numbered...

[arihant2math]

• The version field is used by systemd to determine compatibility, in fact Systemd fixups #200 bumps it to avoid a warning. I'd assume that other userspace applications depend on it as well, so we probably should keep that set to a (preferably old) linux LTS version.
• I don't think anyone uses the date for anything important, so we can set it to the compile time. That'd probably require a build.rs setup.
• I'm not sure as to how the versioning and distribution of the kernel would work, presumably we'd distribute some sort of image file that qemu can boot.

[andrewdavidmackenzie]

Understood, thanks for the explanation.
I'll send a PR for the date maybe just to "cut my teeth" on moss.

[andrewdavidmackenzie]

I wanted to create a test before making any serious changes, but then realized no_std doesn't allow #[test]

Asking, I see these options:

1. Put tests in libkernel, which appears to support std for testing.
   You could move testable logic there.

2. Use #[cfg(test)] with a feature flag - Some kernel projects conditionally enable std during testing:
   [features]
   test = ["std"]

3. Custom test framework - Use #![feature(custom_test_frameworks)] with a no_std-compatible test
   runner (like what the kernel likely uses for other tests).

4. Separate test crate - Create a standalone test crate that depends on the kernel's library
   components and runs with std.

If I wanted to add a unit test for sys_uname, which approach would you suggest (if any, or another one?)

[arihant2math]

So we currently have libkernel unit tests and userspace tests in usertest/ (basically E2E testing). I'd recommend using the userspace testing because this is a syscall.

I do realize there is a gap because there is no testing for non-syscall no_std stuff. We'd need something similar to kunit to do this kind of testing.

[hexagonal-sun]

Just a small note on the uname version. Not only do we need a higher version number for systemd but it's also needed for any libc programs; otherwise they exit with an error Kernel too old.

[andrewdavidmackenzie]

I have pushed here, what I would have liked to have done:
andrewdavidmackenzie#1

This tests the internal logic as a unit test, not from user space a syscall, just as a function call from the test.

An additional userspace test of the syscall could complement this, to make sure the transfer to userspace works as expected.

But the unit test (#[test]) cannot exist like that.

WDYT would be a good idea here?

[arihant2math]

In the linux kernel, that would be covered by KUnit, unfortunately, we don't have anything like that. I'll file a PR with an initial unit-testing framework.

[arihant2math]

Working on a fix in #223. That should cover your unit testing needs, but I likely will need to do some tricks to get async working first.

[andrewdavidmackenzie]

Thanks for the efforts, hopefully that will be of general usefulness.

I'll wait to see when you can merge it, and then will rebase and try to complete this PR as an example of using it.

[andrewdavidmackenzie]

Working on this now using the new test framework!

Is "#1" intended to be a build number?

[arihant2math]

Yeah it is.

[arihant2math]

Fixed by #227.