- PVSM.RU - https://www.pvsm.ru -
Если вы несколько лет вообще не следили за Windows 10 и не знаете, что происходит, то пропустили одну вещь — очень горячей темой для разработчиков стала подсистема Windows для Linux, она же WSL. Среди программистов очень часто её обсуждают. Действительно, потрясающе интересная штука.
Наконец-то у нас появилась возможность запустить свой инструментарий Linux на Windows наравне с виндовыми программами. А это значит, что больше не нужно изучать странный PowerShell или пользоваться архаичной консолью CMD.EXE
.
К сожалению, не всё так радужно. WSL по-прежнему является неким инородным элементом, который отделён от родной среды Windows. В частности, не может взаимодействовать с «родными» инструментами Windows.
А ведь изначально всё задумывалось совсем иначе, пишет [1] Джулио Мерино (Julio Merino), автор блога для разработчиков jmmv.dev. Подсистема должна была стать совсем другой, но фактически вышел провал, в каком-то смысле.
Чтобы понять причины этого провала, нужно сначала понять различия между WSL 1 и WSL 2 и как переход на WSL 2 закрыл некоторые интересные перспективы.
Давайте сначала взглянем на WSL 1, и первым делом — на её странное название. Почему эта функция называется подсистемой Windows… для Linux? Разве не наоборот? Это же не подсистема в Linux, которая делает что-то связанное с Windows, а именно наоборот! То есть грамотно она должна называться «Подсистема с функциональностью Linux для Windows» или «Подсистема Linux для Windows» или LSW. Откуда путаница?
Есть мнение [2], что Microsoft была вынуждена выбрать название «наоборот», чтобы избежать упоминания чужих торговых марок. Вот слова Рича Тёрнера (Rich Turner), проект-менеджера WSL:
Что ж… с другой стороны, такое странное название технически можно считать корректным, если внимательно изучить архитектуру ядра Windows NT. На странице «Архитектура Windows NT» [3] в Википедии мы находим следующее:
«Пользовательский режим Windows NT состоит из подсистем, передающих запросы ввода-вывода соответствующему драйверу режима ядра посредством менеджера ввода-вывода. Есть две подсистемы на уровне пользователя: подсистемы окружения (запускают приложения, написанные для разных операционных систем) и интегрированные или внутренние подсистемы (управляет особыми системными функциями от имени подсистемы окружения). Режим ядра имеет полный доступ к аппаратной части и системным ресурсам компьютера».
Windows NT разработана с нуля для поддержки процессов, запущенных из множества операционных систем, а Win32 был «просто» одной из этих подсистем окружения. На такой платформе WSL 1 предоставляет новую подсистему окружения, подсистему Linux, для запуска бинарников Linux поверх ядра Windows NT. У подсистем окружения Win32 и Linux должна быть одна общая интегральная подсистема.
Что всё это на самом деле значит?
Разные системы называют «фронтендами» — вот что это значит. Процесс пользовательского пространства — это набор двоичных команд, которые процессор выполняет непрерывно (оставим в стороне прерывания). Ядро операционной системы не знает о том, что делает процесс, пока процесс не выдаст системный вызов: в этот момент ядро восстанавливает контроль для выполнения операции от имени пользователя, которая может быть чем-то вроде чтения файла или паузы на несколько секунд.
Способ, которым процесс выполняет системные вызовы, и семантика этих системных вызовов специфичны для операционной системы. Например, на старых х86 это выглядит так: открытие файла в системе Win32 — системный вызов 17h
, который инициируется через прерывание INT 2EH
, а при открытии файла в системе Linux — это системный вызов 5h
, который инициируется через прерывание INT 80х
.
Но… концептуально открытие файла — это открытие файла, верно? Нам особенно не интересно, что номера системных вызовов или номера прерываний отличаются друг от друга. И в этом заключается ключевой аспект дизайна WSL 1: подсистема Linux в ядре NT — это, проще говоря, реализация уровня системных вызовов Linux перед ядром NT. Эти системные вызовы позже делегируются примитивам NT, а не вызовам Win32. Самое главное: нет никакого перевода с системных вызовов Linux на системные вызовы Win32.
В каком-то смысле это подвиг архитектурной мысли и реальной программной разработки, учитывая в целом хорошую поддержку Linux-приложений под WSL 1 и помня о множестве реальных внутренних отличий NT от Unix, когда Windows вообще нативно не воспринимает стандартную юниксовую логику fork–exec [4].
Истинная красота этой конструкции заключается в том, что на машине работает одно ядро, и это ядро имеет целостное представление обо всех процессах под ним. Ядро знает всё о процессах Win32 и Linux. И все эти процессы взаимодействуют с общими ресурсами, такими как единый сетевой стек, единый менеджер памяти и единый планировщик процессов.
Если WSL 1 так крут, то зачем нужен WSL 2? Здесь две причины:
Уровни и интерфейсы между ними: API и ABI. Высокоуровневое сравнение
WSL 2 «выбрасывает» всю часть подсистемы Linux и заменяет её полноценной (но очень хорошо скрытой и быстрой) виртуальной машиной. Затем виртуальная машина внутри себя запускает обычное ядро Linux, правильную файловую систему Linux и стандартный сетевой стек Linux. Всё это работает внутри VM.
Это означает, что красота дизайна WSL 1 исчезла: ядро Windows NT больше не видит ничего в мире Linux. Просто большой чёрный ящик, который делает что-то неизвестное внутри себя. Ядро Windows NT видит только точки подключения VMENTER
и VMEXIT
для виртуальной машины и запросы чтения/записи на уровне блоков на виртуальном диске. Это самое ядро NT теперь ничего не знает о процессах Linux и доступе к файлам. Точно так же работающее ядро Linux ничего не знает об NT.
О некоторых других различиях можно прочитать в официальной документации [5].
С точки зрения пользователя, подсистема WSL 2 выглядит лучше: действительно, приложения Linux теперь работают намного быстрее, потому что не проходят через неудобную «эмуляцию» системных вызовов Linux в ядре NT. Если NTFS трудно использовать с семантикой Linux, то теперь такой проблемы нет, потому что теперь окружение Linux использует ext4 на своём виртуальном диске. И поддержка приложений Linux может быть гораздо более полной, потому что… ну, потому что WSL 2 — это и есть полноценный Linux.
Но подумайте, за счёт чего достигнуто это удобство? Чего мы лишились?
Какой должна была стать WSL, если бы всё работало так, как задумано:
ps
или top
в сеансе WSL и увидеть рядом процессы Linux и Windows, причём любой из них можно убить командой kill
?
ifconfig
(аналог ipconfig из Windows, хотя есть ещё ip
) в рамках сеанса WSL для проверки и изменения сетевых интерфейсов компьютера?
Хотя такого никогда не существовало, такой мир вполне можно себе представить… и это могла обеспечить только архитектура WSL 1. И это вовсе не фантазии, потому что именно такую модель использует macOS (хотя это немного читерство, ведь macOS, по сути, является Unix).
Вот что бесит сильнее всего, пишет [1] Джулио Мерино: «Хотя я могу установить WSL на свою машину разработки для Azure, но никак не могу его использовать вообще ни для чего. По-прежнему приходится работать в CMD.EXE, поскольку здесь происходит взаимодействие с нативными процессами и ресурсами Windows, а инструменты, с которыми я имею дело, предназначены только для Windows».
На странице вопросов и ответов [6] написано, что WSL 1 не будет заброшен, то есть можно запускать дистрибутивы WSL 1 и WSL 2 вместе, проапгрейдить любой дистрибутив на WSL 2 в любое время или вернуться на WSL 1. И если посмотреть на строгую приверженность к обратной совместимости Microsoft, из-за которой мы до сих пор вынуждены пользоваться архаичными инструментами и протоколами, это может быть правдой. Но поддержка WSL 1 — колоссальное усилие, потому что придётся отслеживать и соответствовать всем изменениям Linux. Как бы то ни было, будем надеяться, что WSL 1 продолжит своё существование. И кто знает, вдруг когда-нибудь всё-таки воплотится в жизнь тот волшебный мир, который мы представляем?
Интересно, что семейство операционных систем BSD ( FreeBSD, OpenBSD, NetBSD, MidnightBSD, GhostBSD, Darwin, DragonFly BSD) всегда отставали от Linux и других коммерческих операционных систем. Но у них очень давно была реализована эта совместимость на бинарном уровне, о которой мы говорим. Джулио Мерино говорит, что совместимость с Linux в ядре NetBSD была реализована ещё в 1995 году, то есть четверть века назад и за 21 год до рождения WSL 1.
И самое замечательное, эта совместимость не ограничивается только Linux. На протяжении многих лет NetBSD поддерживала эмуляцию различных операционных систем. Поддержка SVR4 появилась в 1994 году, и в течение короткого периода времени NetBSD даже поддерживала… бинарные файлы PE/COFF [7] — да, правильно, это бинарные файлы Win32! Таким образом, в некотором смысле NetBSD реализовала модель WSL 1 наоборот: она позволяла запускать бинарные файлы Win32 поверх ядра NetBSD ещё в 2002 году. Вот так вот.
VDSina предлагает VDS в аренду [8] под любые задачи, огромный выбор операционных систем для автоматической установки, есть возможность установить любую ОС с собственного ISO [9], удобная панель управления [10] собственной разработки и посуточная оплата тарифа, который вы можете создать индивидуально под свои задачи.
Автор: Mikhail
Источник [11]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/unix-2/360411
Ссылки в тексте:
[1] пишет: https://jmmv.dev/2020/11/wsl-lost-potential.html
[2] мнение: https://twitter.com/richturn_ms/status/1245481405947076610
[3] «Архитектура Windows NT»: https://en.wikipedia.org/wiki/Architecture_of_Windows_NT
[4] fork–exec: https://en.wikipedia.org/wiki/Fork%E2%80%93exec
[5] официальной документации: https://docs.microsoft.com/en-us/windows/wsl/compare-versions
[6] странице вопросов и ответов: https://docs.microsoft.com/en-us/windows/wsl/wsl2-faq#what-will-happen-to-wsl-1-will-it-be-abandoned
[7] поддерживала… бинарные файлы PE/COFF: https://man.netbsd.org/NetBSD-5.0/compat_pecoff.8
[8] VDS в аренду: https://vdsina.ru/cloud-servers?partner=habr216
[9] ISO: https://vdsina.ru/qa/q/kak-ispolzovat-svoy-obraz-iso-v-vds?partner=habr216
[10] панель управления: https://habr.com/ru/company/vdsina/blog/460107/
[11] Источник: https://habr.com/ru/post/535214/?utm_source=habrahabr&utm_medium=rss&utm_campaign=535214
Нажмите здесь для печати.