The context is the following:
Additionally, the following rule is required in systems supporting the 32-bit syscall table (such as i686 and x86_64).
I'm trying to figure out what this means, and how I can check whether my system needs this rule. They reference the
chown32 commands/(syscalls, maybe), and continue to discuss system architecture around it. I only care about Linux but I don't only care about x86.
In the output of
lscpu, you have the field for
CPU op-mode which looks like:
CPU op-mode(s): 32-bit, 64-bit
x86_64 processor with dual architecture support. I presume that would show 32 or 64 only on systems not capable of interpreting the other's instructions.
My dilemma is figuring this out programmatically (I'll eventually write it as Python) on a legacy system without
lscpu on it. I've examined this question where they talk about finding 64-bit compatibility, but I'm struggling to make use of these in the opposite use case.
So to summarize why this is a problem so far:
lscpuis not the machine
- I've ran
sudo find / -iregex .*lscpu.*to make sure
- I've ran
/proc/cpuinfoexplains 64-bit compatibility through flags ending in
_lm(not 32-bit compatibility, as far as I'm aware)
unameis insufficient: it displays the primary architecture, and while it's safe to assume
x86_64undoubtedly supports 32-bit too, mapping known architectures to compatibility doesn't seem the most reliant or efficient way of solving this particular problem
hwinfois not on the machine
getconf LONG_BITchecks 64-bit compatibility
lshwis not on the machine
It's possible I've overlooked something and equally possible I don't understand enough about the subject as a programmer. Could someone please help me understand how to programmatically—meaning some method of obtaining an exact or parsable output—check if my system has 32-bit compatibility?