Вопрос или проблема
Насколько я понимаю, соответствие стандарту POSIX означает возможность представления уровня API, который удовлетворяет всем системным вызовам Unix.
Однако многие из этих вызовов предполагают, что пользователи, файлы, процессы, разрешения, виртуальная память и т.д. в системе структурированы и организованы определенным образом. Поэтому мне кажется, что для удовлетворения этих вызовов вам, по сути, нужно быть операционной системой Unix.
Я задаюсь вопросом, как другие операционные системы (например, определенные версии Windows) получают сертификат на соответствие стандарту POSIX, делают ли они:
a) создают совершенно отдельную подсистему (например, виртуальную машину), которая организует файлы, процессы, пользователей и т.д. так, как это делает Unix, или же
b) они сопоставляют системные вызовы Unix с нативными системными вызовами, не создавая, например, целые файловые системы, которые ведут себя как файловые системы Unix?
Или же смесь того и другого?
Насколько я понимаю, соответствие стандарту POSIX означает возможность представления уровня API, который удовлетворяет всем системным вызовам Unix.
Уровень API, требуемый стандартом POSIX, не касается системных вызовов; отсюда его название “уровень API”.
Хотя часть традиционного Unix “API стандарта C” почти 1:1 соответствует системным вызовам ядра, POSIX этого не требует (поскольку программы, как правило, не делают системные вызовы напрямую) – он только требует, чтобы вызовы библиотеки реализовывали желаемое внешнее поведение, даже если это означает, что библиотека должна выполнить некоторую работу по трансляции. (Хотя для некоторых вещей определенно полезно иметь определенные функции ядра.)
Например, Cygwin позволяет запускать программное обеспечение, соответствующее стандарту POSIX, на Windows с помощью трансляции в пространстве пользователя; например, он предоставляет функцию библиотеки C open()
, которая переводит имена путей в стиле Unix в пути Windows (где /
сопоставляется с C:\Cygwin
или подобным), реализует требуемое поведение /dev и т.д. Аналогично, Wine реализует большую часть уровня API Win32 на Linux – не как ~1:1 сопоставление с вызовами ядра Linux, а с многими трансляциями, выполненными, например, в демоне ‘wineserver’.
POSIX также довольно минимален по сравнению с другими стандартами. Например, если я нашел правильную спецификацию, в нем нет упоминания о таких вещах, как /usr/bin
– его единственные требования это /tmp
и три устройства в /dev
(то есть, он требует /dev/null, но ничего не говорит о дисковых устройствах, например).
Я задаюсь вопросом, как другие операционные системы (например, определенные версии Windows) получают сертификат на соответствие стандарту POSIX, делают ли они:
a) создают совершенно отдельную подсистему (например, виртуальную машину), которая организует файлы, процессы, пользователей и т.д. так, как это делает Unix, или же
У Windows раньше была “подсистема POSIX”, которая была более-менее слоем трансляции API на основе ядра NT – аналогично тому, как у нее уже существует подсистема “Win32”, которая также является слоем трансляции поверх настоящего интерфейса ядра NT. (C:\Windows
на самом деле не является реальным путем, который использует ядро Windows, например…)
Если у вас есть виртуальная машина под управлением Windows XP или Win7, это можно установить как “Microsoft Subsystem For Unix (SFU)”, также известную как “Interix“.
Ответ или решение
Для обеспечения совместимости с POSIX операционной системе не обязательно быть по сути UNIX. Давайте подробно рассмотрим, как это возможно и какие подходы используют различные ОС, такие как Windows, для достижения этой цели.
1. Понимание POSIX
POSIX (Portable Operating System Interface) – это стандарт, разработанный для обеспечения совместимости операционных систем с UNIX. Основная цель POSIX заключается в унификации интерфейса программирования приложений (API), чтобы программы, разработанные для одной UNIX-системы, могли работать на других с минимальными изменениями. Однако сам стандарт не требует от ОС полностью соответствовать архитектуре UNIX.
2. Разные подходы к совместимости
a) Трансляция системных вызовов
Одним из самых распространённых подходов является трансляция системных вызовов. ОС, желающие быть сертифицированными как POSIX-соответствующие, могут реализовать библиотеку, которая будет подменять POSIX-системные вызовы на свои нативные вызовы.
Пример: Cygwin — это среда, которая позволяет запускать POSIX-программы на платформе Windows. Она реализует POSIX API через трансляцию. Например, функция open()
в Cygwin переводит пути UNIX-формата (как /home/user/file.txt
) в форматы, подходящие для Windows (например, C:\Cygwin\home\user\file.txt
).
b) Виртуальные подсистемы
Другим вариантом является внедрение виртуальной подсистемы, которая эмулирует поведение UNIX-системы. Это позволяет создавать такую среду, где программы могут работать, как если бы они находились на UNIX-системе, даже если под ними работает совершенно другая ОС.
Пример: Microsoft Windows имеет подсистему POSIX, известную как SFU (Services for UNIX). Эта подсистема предоставляет интерфейс, который позволяет приложениям UNIX работать непосредственно на Windows, обрабатывая их вызовы и взаимодействие с файловой системой. Это позволяет реализовать необходимые функции управления файлами, пользователями и процессами.
c) Смешанный подход
Некоторые ОС используют смешанный подход. Они могут комбинировать отдельные компоненты, которые специально реализованы для обеспечения POSIX-соответствия, и трансляцию системных вызовов. Это может быть полезно для достижения более полного соответствия стандарту, при этом не нарушая работу основной системы.
3. Минимизмы POSIX
Важно отметить, что стандарт POSIX не так громоздок, как может показаться на первый взгляд. Он включает только минимальные требования к интерфейсу, такие как:
- Наличие некоторых стандартных каталогов (
/tmp
, например). - Минимальные требования к устройствам в
/dev
.
Это значит, что можно достичь совместимости с POSIX, не создавая полную файловую структуру UNIX. Некоторые современные ОС могут ограничиваться предоставлением только необходимых возможностей API без глубокого вмешательства в структуру самой ОС.
Заключение
Таким образом, стать POSIX-совместимым можно, реализуя необходимые функциональные возможности через трансляцию, создание специализированной подсистемы или сочетание этих методов. Это открывает двери для множества приложений, которые могут работать вместе, несмотря на различия в архитектуре операционных систем. Данный процесс требует тщательной реализации API, но при этом не обязывает систему быть "по сути" UNIX.