On Sat, 06.04.13 04:50, Askar Safin (safinas...@mail.ru) wrote: > 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
Hmm, so reading though this thread it appears that: a) uname()'s machine field doesn't actually indicate what mode the kernel is running in. b) there appears to be no sane way to figure out which ELF binary architectures the current cpu+kernel+ld.so support? c) you can convert a 32bit debian userspace into a 64bit debian userspace with just a bit of apt package installation? Which essential makes the primary userspace arch a changeble user setting rather than a fixed property of the distribution? (Which is different from Fedora, where we support multilib too, but where one arch is always the clear primary, and all others just secodnary...) So, the desire is to somehow expose a list of arch specifiers that are supported by all three of the current CPU, the current kernel and the installed ld.sos. Now, on Fedora at least the package containing /etc/os-release is arch-independent. It installs the exact same file on all archs, and I figure that might actually be a good thing. Which makes it a bit unsuitable for configuring the arch... I wonder if it wouldn't be a better idea to somehow provide a sane API for this functionality rather than defining a configuration file format for it? Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
