doc: FATAL: kernel too old failure in userland simulation improve a bit

Author: cirosantilli

README.adoc

@@ -4178,7 +4178,7 @@ At 125d14805f769104f93c510bedaa685a52ec025d we <<libc-choice,moved Buildroot fro
 
 glibc has a check for kernel version, likely obtained from the `uname` syscall, and if the kernel is not new enough, it quits.
 
-Both gem5 and QEMU however allow setting the reported `uname` version from the command line, which we do to always match our toolchain.
+Both gem5 and QEMU however allow setting the reported `uname` version from the command line for <<user-mode-simulation>>, which we do to always match our toolchain.
 
 QEMU by default copies the host `uname` value, but we always override it in our scripts.
 
@@ -4190,16 +4190,14 @@ Determining the right number to use for the kernel version is of course highly n
 
 Source: link:userland/posix/uname.c[].
 
-The QEMU source that does this is at: https://github.com/qemu/qemu/blob/v3.1.0/linux-user/syscall.c#L8931
+The QEMU source that does this is at: https://github.com/qemu/qemu/blob/v3.1.0/linux-user/syscall.c#L8931 The default ID is just hardcoded on the source.
 
 Bibliography:
 
 * https://stackoverflow.com/questions/48959349/how-to-solve-fatal-kernel-too-old-when-running-gem5-in-syscall-emulation-se-m
 * https://stackoverflow.com/questions/53085048/how-to-compile-and-run-an-executable-in-gem5-syscall-emulation-mode-with-se-py/53085049#53085049
 * https://gem5-review.googlesource.com/c/public/gem5/+/15855
 
-The ID is just hardcoded on the source:
-
 ==== stack smashing detected when using glibc
 
 For some reason QEMU / glibc x86_64 picks up the host libc, which breaks things.