Linux: Fix kmsg f-strings

[ikelos]

Closes #1496

[gcmoreira]

the int() is redundant here

[gcmoreira]

hm this bug was introduced in this commit, in the context of use ruff for linting #1364.

@ikelos If you want to use an f-string, your changes look good. However, I'd recommend removing the unnecessary int() call for simplicity.
If you decide not to use an f-string, I recommend reverting these changes to the original version, which was carefully tested and verified.

[gcmoreira]

@c0rydoras I wonder if this bug was a ruff suggestion or you included this later?

[ikelos]

Thanks for checking this! The unnecessary int cast was exactly my thought about the PR (essentially made by the initial report, #1496). I would like to keep the use of f-strings over %, I believe it's recommended (for reasons as put forward in the PEP rationale), I just couldn't find an example to try it out on. I only have a few linux samples and several are from AOMF...

[gcmoreira]

@ikelos sorry, hold on. I double-checked this using the example I used in that method comment, and it turns out this doesn't work as expected. Unfortunately, we introduced another bug here.

    def nsec_to_sec_str(self, nsec: int) -> str:
        # See kernel/printk/printk.c:print_time()
        #   Here, we could simply do:
        #       "%.6f" % (nsec / 1000000000.0)
        #   However, that will cause a roundoff error. For instance, using
        #   17110365556 as input, the above will result in 17.110366.
        #   While the kernel print_time function will result in 17.110365.
        #   This might seem insignificant but it could cause some issues
        #   when compared with userland tool results or when used in
        #   timelines.

>>> nsec=17110365556; "%lu.%06lu" % (nsec / 1000000000, (nsec % 1000000000) / 1000)
'17.110365'

>>> nsec=17110365556; f"{nsec / 1000000000}.{(nsec % 1000000000) / 1000:06}"
'17.110365556.110365.556'

Using // should get the same results and fix this issue:

>>> nsec=17110365556; f"{nsec // 1000000000}.{(nsec % 1000000000) // 1000:06}"
'17.110365'

Another test:

>>> nsec=17000365556; "%lu.%06lu" % (nsec / 1000000000, (nsec % 1000000000) / 1000)
'17.000365'

>>> nsec=17000365556; f"{nsec // 1000000000}.{(nsec % 1000000000) // 1000:06}"
'17.000365'

The only potential issue would be if nsec were not an int. However, this is not possible as it is always sourced from ts_nsec in log, printk_log, or printk_info, which is defined as a u64.

>>> nsec=17000365556.3; "%lu.%06lu" % (nsec / 1000000000, (nsec % 1000000000) / 1000)
'17.000365'

>>> nsec=17000365556.3; f"{nsec // 1000000000}.{(nsec % 1000000000) // 1000:06}"
'17.0.0365.0'