Пост 9351

2. Двоичные компиляторы – транслятор приложений rtc-5.0: 2.1. Для процессоров Эльбрус V6 включен режим расположения вторичного пространства (x86-memory) в начале виртуального пространства компилятора приложений. Для этого пришлось rtc сделать 64-битным (но только для e2c3 и e16c). Такой подход убирает часть лишних преобразований адресных аргументов системных вызовов.Для более старых архитектур (<= V5) по-прежнему вторичное пространство расположено высоко. Аппаратура автоматически при использовании сегментных операций обращения в память прибавляет к указанному в команде адресу смещение 0x100000000000. Из-за этого все аргументы системных вызовов, которые содержат адреса (x86-адреса), приходится преобразовывать - за аппаратуру прибавлять смещение, а в случае 32-битных x86-приложений использовать 64-битные системные вызовы. 2.2. В ядре ОС реализована специальная файловая система на базе proc, позволяющая скрыть служебные процессы и потоки компилятора приложений от x86-приложений. Также обработка стандартных файлов файловой системы proc (например, ссылки /proc/self/exe или содержимого /proc/self/maps) производится в ядре. x86-приложение не должно заметить ни одного следа присутствия компилятора приложений через подмененную файловую систему proc.2.3. Поддержан системный вызов unshare, необходимый для запуска docker. Теперь докер-контейнеры в кодах х86/х86-64 можно запускать целиком через компилятор приложений. 2.4. После установки компилятора приложений появилась возможность непосредственного запуска x86-приложений из нативной командной строки. По умолчанию так можно запускать лишь статические x86-приложения, но при желании можно легко настроить и запуск динамических приложений (через конфигурационный файл default.conf), но как и прежде придется развернуть подходящую гостевую файловую систему.2.5. В ядро добавлены специальные скрытые файловые дескрипторы, которые не видны в файловой системе proc (даже нативной), они используются для логирования, общения со служебными процессами/потоками, запуска x86-приложения. Опять же для возможности запуска docker'а потребовалось загружать в память x86-приложение не по пути (по которому открытый и удаленный файл оказывался недоступным), а через файловый дескриптор (который по-прежнему существовал в ядре).2.6. За счет использования mnt namespace'ов в компиляторе приложений более не требуется следить за x86-путями, это автоматически делает ядро. Старт бинарного компилятора реализует полноценный chroot, из которого в нативный корень больше уже не выбраться. Это потребовало на стороне ядра реализовать дополнительные структуры данных, в которых хранится информация о компиляторах приложений, ведь они расположены вне x86-мира, но по-прежнему должны быть доступны для использования при выполнении x86-execve.2.7. В ядро добавлены специфические ресурсные лимиты. Так ulimit -s при запуске под бинарным компилятором повлияет только на ограничение по размеру x86-стека, а не нативного (то есть не на стек компилятора приложений). Помимо стека учтен и лимит на размер виртуальной памяти.2.8. Добавлена возможность сброса x86-dump'ов памяти при падении x86-приложений из-за соответствующих сигналов. Также пользователям будет доступен более широкий диапазон средств, позволяющий проводить предварительную отладку по обнаруженным проблемам (в документации про это будет новый раздел)Один из главных эффектов для пользователей: в новом rtc-5.0 поддержана работа гостевых Яндекс-Браузера и Chromium.