[systemd-devel] Add ARCH parameter to /etc/os-release

Askar Safin safinaskar at mail.ru
Fri Apr 5 17:50:58 PDT 2013


 Please standardize and recommend new /etc/os-release parameter: ARCH. It will content architecture of this distro (i. e. i386, x86_64, ...). There are some cases when this value differs from current kernel architecture (as typically reported by uname -m). For example, when you are in chroot environment or when you just mounted some other OS and want to know what is architecture of this OS.

I. e. I suggest this parameter to contain architecture of the distro, i. e. userspace, not kernel. So, you can even name it USERSPACE_ARCH or DISTRO_ARCH, but I think this is too long.

I think this should be GNU architecture (i386, x86_64) and not Debian architecture (i386, amd64). Because GNU architecture is (as far as I know) more widely used. Also, this enables you to compare it with "uname -m" output. And this allow you to use "setarch" (see below)

This parameter will be very useful if you want to chroot to some distro. First, you can read this parameter to determine whenever you can chroot to this OS. Second, you can read this parameter and then set arch (which you just read) via the setarch (8) util from util-linux-ng. This useful trick will let programs in chroot think they are on native arch. I. e. this will make the following code possible:

source /target/etc/os-release
setarch "$ARCH" chroot /target

Also, I recommend to add similar trick to systemd-nspawn!

Also, maybe this is good idea to set this parameter to particular CPU instruction set (i386, i486, ...). Or even to add two options: one for widely used architecture name (for example, i386) and another more specific name (for example, i486). Of course, this parameters will not refer to kernel arch nor to arch of current machine. They will refer to arch this distro compiled for.

Probably this is good idea to add parameter even for GNU triplet. Of course, you can determine it via "gcc -v", but this raises two issues:
1. gcc may be not installed on the system
2. this will not work if you cannot even chroot to target system

Askar Safin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20130406/5648efd0/attachment.html>


More information about the systemd-devel mailing list