Эльбрус/rtc
Бинарный транслятор
Для решения задачи совместимости с унаследованным ПО для платформы x86 в МЦСТ разработали проприетарный бинарный транслятор, работающий в двух режимах, чем-то напоминающих гипервизор (когда можно установить и запустить целую ОС) и нечто, имеющее черты wine и контейнера (когда требуется запустить отдельное приложение)[1].
Первый режим реализован в lintel[2]; второй -- в rtc и работает под управлением уже запущенной операционной системы.
В этой статье мы рассмотрим второй вариант.
Здесь:
- хост (хостовая операционная система)
- -- ОС, под которой мы запускаем транслятор, в которую кладём образ гостевой системы и т.п. Имеет архитектуру e2k, в файловой системе лежат бинарники под e2k.
- гость (гостевой образ, гостевой chroot)
- -- операционное окружение, файловую систему которого (в виде подкаталога в файловой системе хоста) мы подсовываем транслятору и в которую rtc "делает chroot" при запуске. Имеет архитектуру x86 или x86_64, в файловой системе лежат бинарники такой же архитектуры. Ядро не требуется.
Всё то, что мы запускаем из-под транслятора, должно лежать внутри гостевого образа (из-под транслятора, как и из-под chroot-а, получить доступ без дополнительных усилий к файловой системе хоста в общем случае нельзя).
Применение
Требуется установленный пакет rtc.
Как правило, также требуется архив x86-корня, полученный тем или иным образом -- исключением является случай запуска статических бинарников (типично для golang).
При наличии, например, в /opt/x86/ развёрнутого окружения для x86_64[3] можно запустить (на машинах на базе процессоров "Эльбрус-8С" или "Эльбрус-1С+") командную оболочку такой командой:
/usr/bin/rtc_opt_rel_p1_x64_ob --path_prefix /opt/x86 -- /bin/bash
То же самое, но для окружения i386 (x86, i686, ia32):
/usr/bin/rtc_opt_rel_p1_ob --path_prefix /opt/x86 -- /bin/bash
При успешном запуске под бинарной трансляцией отданная в полученном приглашении команда arch сообщит не "e2k", а "x86_64".
Разумеется, путь /opt/x86 не фиксирован, ничто не мешает иметь на машине множество гостевых окружений в разных каталогах.
Вместо /bin/bash можно подставить любую другую команду, которую нужно будет запустить под бинарным транслятором. Путь к бинарнику необходимо указывать полный относительно места расположения образа. Например, если образ расположен в /opt/x86 и мы хотим запустить /opt/x86/usr/bin/mc, можно отдать команду вида:
/usr/bin/rtc_opt_rel_p1_ob --path_prefix /opt/x86 -- /usr/bin/mc
На машинах на базе процессоров "Эльбрус-4С" следует запускать /opt/mcst/rtc/rtc_opt_rel_e2s_ob[4] или /opt/mcst/rtc/rtc_opt_rel_e2s_x64_ob в зависимости от разрядности образа.
Иногда есть необходимость прокинуть какой-нибудь каталог или файл внутрь chroot-а гостевого образа. Например, рассмотрим это на примере прокидывания каталога /run/pulse (это применяется для того, чтобы в гостевых приложениях работало PulseAudio) внутрь образа /opt/x86. Нужно:
- создать пустой каталог /opt/x86/run/pulse (если его ещё нет);
- запустить бинарный транслятор с параметром -b <имя каталога или файла для прокидывания>, например:
/usr/bin/rtc_opt_rel_p1_ob --path_prefix /opt/x86 -b /run/pulse -- /bin/bash
После запуска транслятора каталог /run/pulse внутри гостевого chroot-а будет отражать содержимое /run/pulse на хостовой системе.
В случае работы не под рутом стоит прокидывать файлы /etc/passwd, /etc/group, возможно также /etc/shadow, а также свой каталог $HOME. Очевидно, uid и gid файлов, к котором должен иметь доступ пользователь в хосте и госте должны совпадать.
Если в качестве хостовой системы используется альт, а в качестве гостя - другая, где не поддерживается TCB (или наоборот), то в альте его также стоит отключить (командой control passwd traditional).
Примечание: RTC может работать с гостевыми системами на других разделах ext4. Необязательно располагать гостевой образ на том же разделе ext4, с которого загружена и хостовая операционная система. Однако нужно иметь в виду, что монтирование раздела, на котором расположено гостевое окружение, необходимо выполнять без параметра user. Например, если в /etc/fstab у вас настроено автоматическое монтирование раздела следующим образом, может возникнуть ошибка apl_ElfMmap: memory mapping failed!
UUID=64f077ca-f530-4e05-a966-79806bc73d87 /mnt/shared/ ext4 defaults,nofail,user,errors=remount-ro,auto,x-systemd.mount-timeout=30 1 2
Если же производить подключение/монтирование раздела без опции "user", как показано ниже, такой ошибки не будет:
UUID=64f077ca-f530-4e05-a966-79806bc73d87 /mnt/shared/ ext4 defaults,nofail,errors=remount-ro,auto,x-systemd.mount-timeout=30 1 2
Соответственно если вы производите монтирование вручную через терминал, в команде также должна отсутствовать опция user:
mount -t ext4 -o defaults,nofail,errors=remount-ro,auto /dev/sda7 /mnt/shared/
Работая из терминала, можете не указывать дополнительные параметры, т.к. по умолчанию опция user при монтировании не используется:
mount -t ext4 /dev/sda7 /mnt/shared/
Запуск графических приложений и приложений, работающих с оборудованием
Для доступа к $DISPLAY может потребоваться либо предварительно отключить авторизацию командой xhost localhost или xhost +, либо обеспечить наличие у пользователя в домашнем каталоге под path_prefix такого же ~/.Xauthority, как на основной системе.
Работа с RAID-контроллерами megaraid (например, с помощью утилиты storcli) поддерживается в rtc 3.1 или более новой версии.
Работа с OpenGL поддерживается в rtc 3.1 или более новой версии; требуется наличие соответствующего видеокарте DRI-драйвера в чруте (например, xorg-dri-radeon)[5].
Работа с OpenCL должна поддерживаться в rtc 3.4 или более новой версии.
Работа с ALSA поддерживается в rtc 3.3 или более новой версии.
Работа с pulseaudio поддерживается в rtc 3.1 или более новой версии, при этом нужно пробросить в гостевой chroot каталог /run/user/`id -u`/pulse.
Можно запускать Windows-приложения с помощью wine и rtc 3.1 или более нового. Следует иметь в виду, что 32-битные приложения можно запускать только 32-битным wine из-под 32-битного гостевого образа и 32-битного исполняемого файла rtc, работающего с ним, а 64-битные -- соответственно 64-битным wine из-под 64-битного образа и 64-битного rtc. К сожалению, многие win64-программы имеют win32-инсталляторы, что делает их установку под wine64 нереальной без специальных усилий.
Создание окружений
Получаем искомый имя-архива.tar.
Можно установить любой линукс в нужный вид в любой виртуальной машине и сделать архив файловой системы (изнутри VM при помощи rescue-загрузки или экспортировав образ диска, подключив и сделав архив снаружи). Если предполагаете использовать связку rtc+wine[6], установить wine и нужное лучше на этой стадии.
Можно взять готовую виртуальную машину VMWare и распаковать содержимое основного файла виртуального диска .vmdk с помощью команды 7z e (необходим установленный p7zip), предварительно просмотрев содержимое 7z l. Распакованный файл .img смонтировать mount -o loop file.img path_to_mount и скопировать содержимое корня в папку /opt/x86 или любую другую, которую укажите в --path_prefix.
Также можно взять подходящий шаблон контейнера OpenVZ -- например, из starterkits: x86_64, i586.
По состоянию на rtc 4.0 в таком окружении стоит отдать от имени root команду sed -i 's,\[p9\] ,,' /etc/apt/sources.list.d/yandex.list[7], после чего заработает apt; во избежание проблем с переменными TMP и TMPDIR, выставленными[8] в существующий на хосте, но не в чруте, каталог следует либо их сбросить командой unset TMP TMPDIR, либо при вызове rtc указать подключение хостового каталога: -b /tmp.
На альте под x86 можно задействовать предварительно настроенный hasher:
hsh --init hsh-install нужное возможно-также-нужное
где в возможно-также-нужное в случае графических приложений обычно попадают xauth и шрифты (например, fonts-otf-mozilla-fira); проверить функционирование приложения "не отходя от кассы" на той же машине, где собран чрут, можно так:
hsh-run -Y команда
Заархивировать полученное содержимое можно так:
hsh-run --rooter -- tar --numeric-owner --exclude .in --exclude .out --exclude .host --exclude /dev/log -cf - / > имя-архива.tar
Ссылки
- mcst.ru/rtc
- mcst.ru/lintel
- МЦСТ > Тэги > Двоичный транслятор
- Аппаратная поддержка двоичной трансляции x86 вещественной арифметики в процессорах "Эльбрус" (PDF)
- Dynamic binary translation
Примечания
- ↑ кстати, сам wine под rtc тоже работает
- ↑ в старых версиях требовал для своей установки и хранения внутренних данных -- кэша откомпилированного кода -- установленную CF-карточку; в более новых версиях мог устанавливаться на отдельный SATA-диск; в современных версиях может устанавливаться на тот же диск, что и гостевая ОС, в последние 16-64 гигабайт, если их оставить неразмеченными
- ↑ например, распакованного командой rm -rf /opt/x86; mkdir /opt/x86; tar -C /opt/x86 -xf имя-архива.tar
- ↑ здесь "e2s" -- внутреннее обозначение процессора "Эльбрус-4С";
"p1" -- одно из внутренних обозначений процессора "Эльбрус-8С";
"x64" -- синоним x86_64/amd64 (то бишь 64-битная x86-совместимая архитектура) - ↑ ср.: WINE#32-битные видеодрайверы
- ↑ обратите внимание: в версии rtc 3.4 известна регрессия (#4825), приводящая к неработоспособности wine; предыдущая известно пригодная для такой задачи версия -- 3.1; после 3.4 было исправлено.
- ↑ это отключит сверку подписи репозитория; см. баг #5364
- ↑ см. тж. pam_mktemp; характерная диагностика: cannot create temp file for here-document: No such file or directory