Printing "null" in ps aux -o emul looks a bit odd, and is not very
helpful. This instead makes the kernel's ABI more obvious, whilst also
clearly showing that these are kernel processes.
Suggested by: rwatson
jrtc27 on Jan 2 2022, 5:00 PM.Authored by
Kernel ELF and bitness are weird there, as I explained in other review reply. Changing it to something that makes it clear that this process does not have userspace ABI might be marginally useful.
What is the use for it? This channel if to describe ABI of some process userspace. There is no userspace, and there is no ABI as defined by sysent.
If you want or need to export something about kernel binary, it is the case where sysctl original purpose matches the goal.
The use case is having a single command that shows you the ABI of every process in the system, userland or kernel. I don’t see a good reason not to include that information, it’s strictly more informative.
And there is an ABI for kernel processes, it’s called the C ABI for that architecture and -mabi=, and the current KBI.
You are making it a mess. There is a kernel ABI for all processes, it is the kernel ABI (I hope my use of articles is right, or at least clear). For some processes, there is a userspace ABI, which is reported from sysent sv_name. With your change, for processes without userspace ABI, you report kernel ABI instead of indicating that there is no userspace ABI.
I see it rather differently. Every process has a (non-empty) set of ABIs, with one ABI being the primary ABI. For userspace processes, the primary ABI is the userspace ABI, and is what gets printed. For kernel processes, the only ABI is the kernel ABI, so is also the primary ABI, and that is what this patch prints for those cases. Just because userspace processes are also kernel processes that adhere to the kernel ABI doesn't mean we shouldn't print anything useful for kernel-only processes, and anyone looking at a userspace process wanting to know what the kernel ABI is can go look at PID 0's reported ABI.
There is no per-process in-kernel ABI, and hardly there ever will be.
Not to mention that I already disagreed with renaming it to 'elf_kernel_sysvec'.