Эльбрус/rtc: различия между версиями

Материал из ALT Linux Wiki
м (→‎Создание окружений: добавил раздел)
м (упс, сломал вёрстку. Починил)
(не показано 5 промежуточных версий этого же участника)
Строка 2: Строка 2:
= Бинарный транслятор =
= Бинарный транслятор =


Для решения проблемы совместимости с унаследованным ПО для платформы x86 в МЦСТ разработали бинарный транслятор, работающий в двух режимах, чем-то напоминающих гипервизор (когда можно установить и запустить целую ОС) и [[wine]] (когда требуется запустить отдельное приложение)<ref>кстати, сам wine под rtc тоже работает</ref>.
Для решения проблемы совместимости с унаследованным ПО для платформы x86 в МЦСТ разработали бинарный транслятор, работающий в двух режимах, чем-то напоминающих гипервизор (когда можно установить и запустить целую ОС) и нечто, имеющее черты [[wine]] и chroot (когда требуется запустить отдельное приложение)<ref>кстати, сам wine под rtc тоже работает</ref>.


Первый режим реализован в lintel и требует для работы установленную CF-карточку в машинах 401/801-РС<ref>в пятой ревизии материнской платы MBE8C-PC CF-слот отсутствует</ref>; второй -- в rtc и работает под управлением уже запущенной операционной системы.
Первый режим реализован в lintel (в старых версиях требовал для своей установки и хранения внутренних данных - кэша откомпилированного кода - установленную CF-карточку; в более новых версиях мог устанавливаться на отдельный SATA-диск; в современных версиях может устанавливаться на тот же диск, что и гостевая ОС в последние 16-64 гигабайт, если их оставить неразмеченными); второй -- в rtc и работает под управлением уже запущенной операционной системы.
 
В этой статье мы рассмотрим второй вариант.
 
Здесь:
* хост (хостовая операционная система) - ОС, под которой мы запускаем транслятор, в которую кладём образ гостевой системы и т.п. Имеет архитектуру e2k, в файловой системе лежат бинарники под e2k.
* гость (гостевой образ, гостевой chroot) - ОС, образ которой (в виде подкаталога в файловой системе хоста) мы подсовываем транслятору, и в которую rtc делает chroot при запуске. Имеет архитектуру x86 или x86_64, в файловой системе лежат бинарники такой же архитектуры.
 
Всё то, что мы запускаем из-под транслятора, должно лежать внутри гостевого образа (из-под транслятора, как и из-под chroot-а, получить доступ без дополнительных усилий к файловой системе хоста в общем случае нельзя).


== Применение ==
== Применение ==
Строка 10: Строка 18:
Требуется установленный пакет {{pkg|rtc}}.
Требуется установленный пакет {{pkg|rtc}}.


При наличии в {{path|/opt/x86/}} развёрнутого окружения для x86_64<ref>например, распакованного командой {{cmd|rm -rf /opt/x86; mkdir /opt/x86; tar -C /opt/x86 -xf имя-архива.tar}}</ref> можно запустить командную оболочку такой командой:
При наличии, например, в {{path|/opt/x86/}} развёрнутого окружения для x86_64<ref>например, распакованного командой {{cmd|rm -rf /opt/x86; mkdir /opt/x86; tar -C /opt/x86 -xf имя-архива.tar}}</ref> можно запустить (на машинах на базе процессоров "Эльбрус-1С+" или "Эльбрус-8С") командную оболочку такой командой:


  /usr/bin/rtc_opt_rel_p1_x64_ob --path_prefix /opt/x86 -- /bin/bash
  /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


При успешном запуске под бинарной трансляцией отданная в полученном приглашении команда {{cmd|arch}} сообщит не "e2k", а "x86_64".
При успешном запуске под бинарной трансляцией отданная в полученном приглашении команда {{cmd|arch}} сообщит не "e2k", а "x86_64".


На ОС Эльбрус под "Эльбрус 401-РС" для эмуляции IA32 следует запускать {{cmd|/opt/mcst/rtc/rtc_opt_rel_e2s_ob}}<ref>здесь "e2s" -- обозначение процессора "Эльбрус-4С";<br/>"p1" -- менее известный синоним названия процессора "Эльбрус-8С";<br />"x64" -- синоним x86_64/amd64 (бишь 64-битная x86-совместимая архитектура)</ref>.
Разумеется, путь <tt>/opt/x86</tt> не фиксирован, ничто не мешает иметь на машине множество гостевых образов в разных каталогах.


== Запуск графических приложений ==
Вместо {{cmd|/bin/bash}} можно подставить любую другую команду, которую нужно будет запустить под бинарным транслятором. Путь к бинарнику необходимо указывать полный относительно места расположения образа. Например, если образ расположен в <tt>/opt/x86</tt>, и мы хотим запустить <tt>/opt/x86/usr/bin/mc</tt>, то нужно давать команду типа:
 
/usr/bin/rtc_opt_rel_p1_ob --path_prefix /opt/x86 -- /usr/bin/mc
 
На машинах на базе процессоров "Эльбрус-4С" следует запускать {{cmd|/opt/mcst/rtc/rtc_opt_rel_e2s_ob}}<ref>здесь "e2s" -- внутреннее обозначение процессора "Эльбрус-4С";<br/>"p1" -- одно из внутренних обозначений процессора "Эльбрус-8С";<br />"x64" -- синоним x86_64/amd64 (то бишь 64-битная x86-совместимая архитектура)</ref> или {{cmd|/opt/mcst/rtc/rtc_opt_rel_e2s_x64_ob}} в зависимости от разрядности образа.
 
Иногда требуется необходимость прокинуть какой-нибудь каталог внутрь chroot-а гостевого образа. Например, рассмотрим это на примере прокидывания каталога <tt>/run/pulse</tt> (это применяется для того, чтобы в гостевых приложениях работало Pulseaudio) внутрь образа <tt>/opt/x86</tt>. Нужно:
 
* Создать пустой каталог <tt>/opt/x86/run/pulse</tt> (если его ещё нет);
* Запустить бинарный транслятор с параметром <tt>-b <имя каталога для прокидывания></tt>, например:
 
/usr/bin/rtc_opt_rel_p1_ob --path_prefix /opt/x86 -b /run/pulse -- /bin/bash
 
После запуска транслятора каталог <tt>/run/pulse</tt> внутри гостевого chroot-а будет отражать содержимое <tt>/run/pulse</tt> на хостовой системе.
 
== Запуск графических приложений и приложений, работающих с оборудованием ==


Для доступа к <tt>$DISPLAY</tt> может потребоваться либо предварительно отключить авторизацию командой {{cmd|xhost localhost}} или {{cmd|xhost&nbsp;+}}, либо обеспечить наличие у пользователя в домашнем каталоге под <tt>path_prefix</tt> такого же {{path|~/.Xauthority}}, как на основной системе.
Для доступа к <tt>$DISPLAY</tt> может потребоваться либо предварительно отключить авторизацию командой {{cmd|xhost localhost}} или {{cmd|xhost&nbsp;+}}, либо обеспечить наличие у пользователя в домашнем каталоге под <tt>path_prefix</tt> такого же {{path|~/.Xauthority}}, как на основной системе.


Для работы с OpenGL может потребоваться {{pkg|rtc 3.3}} или более новая версия.
Работа с RAID-контроллерами megaraid (например, с помощью утилиты <tt>storcli</tt>) поддерживается в {{pkg|rtc 3.1}} или более новой версии.
 
Работа с OpenGL поддерживается в {{pkg|rtc 3.1}} или более новой версии.
 
Работа с OpenCL должна поддерживаться в {{pkg|rtc 3.4}} или более новой версии.
 
Работа с ALSA поддерживается в {{pkg|rtc 3.3}} или более новой версии.
 
Работа с Pulseaudio поддерживается в {{pkg|rtc 3.1}} или более новой версии, при этом нужно пробросить в гостевой chroot каталог <tt>/run/pulse</tt>.
 
Можно запускать Windows-приложения с помощью wine и {{pkg|rtc 3.1}} или более нового. Следует иметь в виду, что 32-битные приложения можно запускать только 32-битным wine из-под 32-битного гостевого образа и 32-битного rtc, работающего с ним, а 64-битные - соответственно 64-битным wine из-под 64-битного образа и 64-битного rtc. К сожалению, многие 64-битные программы имеют 32-битные инсталляторы, что делает их установку под wine64 нереальной без специальных усилий.


= Ссылки =
= Ссылки =

Версия от 17:21, 13 ноября 2019

Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Бинарный транслятор

Для решения проблемы совместимости с унаследованным ПО для платформы x86 в МЦСТ разработали бинарный транслятор, работающий в двух режимах, чем-то напоминающих гипервизор (когда можно установить и запустить целую ОС) и нечто, имеющее черты wine и chroot (когда требуется запустить отдельное приложение)[1].

Первый режим реализован в lintel (в старых версиях требовал для своей установки и хранения внутренних данных - кэша откомпилированного кода - установленную CF-карточку; в более новых версиях мог устанавливаться на отдельный SATA-диск; в современных версиях может устанавливаться на тот же диск, что и гостевая ОС в последние 16-64 гигабайт, если их оставить неразмеченными); второй -- в rtc и работает под управлением уже запущенной операционной системы.

В этой статье мы рассмотрим второй вариант.

Здесь:

  • хост (хостовая операционная система) - ОС, под которой мы запускаем транслятор, в которую кладём образ гостевой системы и т.п. Имеет архитектуру e2k, в файловой системе лежат бинарники под e2k.
  • гость (гостевой образ, гостевой chroot) - ОС, образ которой (в виде подкаталога в файловой системе хоста) мы подсовываем транслятору, и в которую rtc делает chroot при запуске. Имеет архитектуру x86 или x86_64, в файловой системе лежат бинарники такой же архитектуры.

Всё то, что мы запускаем из-под транслятора, должно лежать внутри гостевого образа (из-под транслятора, как и из-под chroot-а, получить доступ без дополнительных усилий к файловой системе хоста в общем случае нельзя).

Применение

Требуется установленный пакет rtc.

При наличии, например, в /opt/x86/ развёрнутого окружения для x86_64[2] можно запустить (на машинах на базе процессоров "Эльбрус-1С+" или "Эльбрус-8С") командную оболочку такой командой:

/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[3] или /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 на хостовой системе.

Запуск графических приложений и приложений, работающих с оборудованием

Для доступа к $DISPLAY может потребоваться либо предварительно отключить авторизацию командой xhost localhost или xhost +, либо обеспечить наличие у пользователя в домашнем каталоге под path_prefix такого же ~/.Xauthority, как на основной системе.

Работа с RAID-контроллерами megaraid (например, с помощью утилиты storcli) поддерживается в rtc 3.1 или более новой версии.

Работа с OpenGL поддерживается в rtc 3.1 или более новой версии.

Работа с OpenCL должна поддерживаться в rtc 3.4 или более новой версии.

Работа с ALSA поддерживается в rtc 3.3 или более новой версии.

Работа с Pulseaudio поддерживается в rtc 3.1 или более новой версии, при этом нужно пробросить в гостевой chroot каталог /run/pulse.

Можно запускать Windows-приложения с помощью wine и rtc 3.1 или более нового. Следует иметь в виду, что 32-битные приложения можно запускать только 32-битным wine из-под 32-битного гостевого образа и 32-битного rtc, работающего с ним, а 64-битные - соответственно 64-битным wine из-под 64-битного образа и 64-битного rtc. К сожалению, многие 64-битные программы имеют 32-битные инсталляторы, что делает их установку под wine64 нереальной без специальных усилий.

Ссылки

Создание окружений

Можно установить любой линукс в нужный вид в любой виртуальной машине и сделать архив файловой системы (изнутри VM или экспортировав образ диска, подключив и сделав архив снаружи).

На альте можно задействовать предварительно настроенный 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

Примечания

  1. кстати, сам wine под rtc тоже работает
  2. например, распакованного командой rm -rf /opt/x86; mkdir /opt/x86; tar -C /opt/x86 -xf имя-архива.tar
  3. здесь "e2s" -- внутреннее обозначение процессора "Эльбрус-4С";
    "p1" -- одно из внутренних обозначений процессора "Эльбрус-8С";
    "x64" -- синоним x86_64/amd64 (то бишь 64-битная x86-совместимая архитектура)