I suppose it is true we no longer support a.out kernels and all kernels for the foreseeable future will be ELF.

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.

Well, it is an ELF file, it is 32 or 64-bit, and I would like the ABI to be communicated to userspace as it is for userspace processes.

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.

In D33723#762757, @jrtc27 wrote:

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.

In D33723#762790, @jrtc27 wrote:

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.
The field you change has currently well defined and simple semantic: it is userspace ABI of the process. Now read your own description of what the result is, and not be surprised that people do not see any reason to do the change:

• there is no per-process kernel ABI
• the simple and clear meaning is replaced by something that requires non-trivial and seemingly useless interpretation.

Not to mention that I already disagreed with renaming it to 'elf_kernel_sysvec'.