Разработка приложений в среде Linux. Второе издание

Проект Linux с самого начала был тесно связан с проектом GNU. Исходная база проекта GNU стала очень важным ресурсом сообщества Linux для создания завершенной системы. Хотя значительное количество систем, основанных на Linux, произведены из источников, которые включают свободно доступный код Unix Калифорнийского университета в Беркли и консорциума X Consortium, многие важные части функциональной системы Linux напрямую связаны с проектом GNU.

По мере развития Linux некоторые лица, а позже и компании, сосредоточились на облегчении инсталляции и практичности систем Linux для новых пользователей, создав пакеты ядра Linux, называемые дистрибутивами, а также логически полный набор утилит. Все это образовало завершенную операционную систему.

Кроме ядра Linux, дистрибутив Linux содержит библиотеки разработки, компиляторы, интерпретаторы, оболочки, приложения, утилиты, графические операционные среды, конфигурационные инструменты и многие другие компоненты. При построении системы Linux разработчики дистрибутива собирают компоненты из разных мест с целью создания полной коллекции всех компонентов ПО, необходимых для нормального функционирования. Большинство дистрибутивов также содержат пользовательские компоненты, облегчающие инсталляцию и эксплуатацию системы Linux.

Доступно множество дистрибутивов Linux. У каждого есть свои преимущества и недостатки, однако все они имеют общее ядро и библиотеки разработки, которые отличают Linux от других операционных систем. Эта книга предназначена для помощи разработчикам в написании программ для любой системы Linux. Поскольку все дистрибутивы Linux используют один и тот же код для системных служб, двоичный и исходный код во всех дистрибутивах совместимы.

Одним из проектов, повлиявших на эту совместимость, является стандарт иерархии файловых систем (Filesystem Hierarchy Standard — FHS), ранее называемый стандартом файловых систем Linux (Linux Filesystem Standard — FSSTND), определяющий, где следует хранить множество файлов, и объясняющий в общих чертах, каким образом должна быть организована оставшаяся часть файловой системы. Позднее проект под названием стандартная база Linux (Linux Standard Base — LSB) был расширен без учета структуры файловой системы, определяя программные интерфейсы приложений (Application Programming Interface — API) и двоичные интерфейсы приложений (Application Binary Interface — ABI). Эти интерфейсы предназначены для возможности компиляции приложения один раз и развертывания его на любой системе, подчиняющейся определению LSB для данной архитектуры процессора. Эти и другие документы доступны на Web-сайте по адресу http://freestandards.org.

1.3. Важные факты в создании систем Unix

Хотя большая часть общего кода Linux разрабатывалась независимо от традиционных исходных баз Unix, на интерфейсы, предоставляемые Linux, сильно влияли существующие системы Unix.

На заре восьмидесятых годов прошлого столетия разработчики Unix были разделены на два "лагеря": первый — Калифорнийский университет в Беркли, а второй — компания AT&T Bell Laboratories. Оба учреждения разрабатывали и поддерживали операционные системы Unix, которые происходили от исходной реализации Unix, созданной в Bell Laboratories.

Версия Unix от Беркли стала известной как программный дистрибутив Беркли (Berkeley Software Distribution — BSD) и приобрела популярность в научном сообществе. Система BSD впервые включила организацию сетей TCP/IP, что повлияло на ее успех и помогло убедить компанию Sun Microsystems основать на BSD первую операционную систему Sun — SunOS.

В компании Bell Laboratories также трудились над совершенствованием Unix, но, к сожалению, несколько другими способами, чем в Беркли. Разнообразные выпуски Bell Laboratories обозначались словом "System", сопровождаемым римским числом. Окончательным выпуском Unix от Bell Laboratories была System V (или SysV); UNIX System У Release 4 (SVR4) сегодня предоставляет кодовую базу для большинства коммерческих операционных систем Unix. Стандартным документом, описывающим System V, является System V Interface Definition (SVID).

Эта разветвленная разработка Unix значительно разнообразила системные вызовы, системные библиотеки и основные команды систем Unix. Одним из лучших примеров такого расщепления являются сетевые интерфейсы, сопровождающие приложения каждой операционной системы. Системы BSD использовали интерфейс под названием сокетов, позволяющий программам сообщаться друг с другом по сети. С другой стороны, System V предоставила интерфейс транспортного уровня (Transport Layer Interface — TLI), полностью несовместимый с сокетами, и официально определенный транспортный интерфейс X/Open (X/Open Transport Interface — XTI). Такая разнородная разработка значительно снизила переносимость программ между версиями Unix, увеличивая стоимость и уменьшая доступность сторонних продуктов для всех версий Unix.

Еще одним примером несовместимости систем Unix является команда ps, позволяющая запрашивать информацию о процессах операционной системы. В системах BSD команда ps aux выдает полный листинг всех процессов, работающих на машине; в System V эта команда недопустима, вместо нее необходимо использовать ps -ef. Форматы вывода так же несовместимы, как и аргументы командной строки. (Команда ps в Linux пытается поддерживать оба стиля.)

Пытаясь стандартизовать все аспекты Unix, которые разошлись из-за разных подходов к разработке в этот период (это еще известно как "войны Unix"), индустрия Unix спонсировала создание набора стандартов, которые определяют предоставляемые Unix интерфейсы. Часть стандартов, имеющая дело с интерфейсами программных и системных инструментов, была названа POSIX (технически это серия IEEE Std 1003, составленная из многих отдельных и черновых стандартов) и выпущена Институтом инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers — IEEE).

Однако исходные серии стандартов POSIX были не полностью завершены. Например, основные концепции UNIX вроде процессов считались необязательными. Более полный стандарт прошел через несколько версий и названий (например, серия стандартов руководства по переносимости X/Open (X/Open Portability Guide — XPG)) перед тем, как был переименован в одиночную спецификацию Unix (Single Unix Specification — SUS), выпущенную The Open Group (владельцем торговой марки UNIX). SUS после нескольких пересмотров была принята IEEE как самая новая версия стандарта POSIX, в настоящее время это IEEE Std 1003.1-2004 [25], и время от времени обновлялась несколькими поправками. IEEE Std 1003.1-2003 был также принят в качестве стандарта ISO/IEC 9945-2003. Самую новую онлайновую версию этого стандарта можно найти по адресу http://www.unixsystems.org/.

Более ранние стандарты, на основе которых был создан этот обновленный унифицированный стандарт, включают все ранние стандарты IEEE Std 1003.1 (POSIX.1 — программный интерфейс С), IEEE Std 1003.2 (POSIX.2 — интерфейс оболочки), а также все связанные стандарты POSIX наподобие расширений реального времени, определенных как POSIX.4, которые позже были переименованы в POSIX.1b, и несколько черновых стандартов.

Поскольку "POSIX" и "SUS" теперь являются синонимами, на комбинированную работу в этой книге мы будем ссылаться как на POSIX.

1.4. Происхождение Linux

"Широта выбора — самое лучшее качество, присущее стандартам". [1] К услугам разработчиков Linux была двадцатилетняя история Unix, но более важным является то, что справочными материалами им служили высококачественные стандарты. Изначально Linux разрабатывался в соответствии с POSIX; там, где не было POSIX, Linux следовала практике System V, за исключением организации сетей, где и системные вызовы, и организация сетей придерживались намного более популярной модели BSD. Теперь, когда существует объединенный стандарт SUS/POSIX, дальнейшее развитие обычно совместимо с более новым стандартом POSIX, а прошлые отклонения от него по возможности откорректированы.

1

Andrew Tanenbaum, Computer Networks, Prentice Hall, 1981, стр. 168.

Самым существенным отличием между SVR4 и Linux с точки зрения программирования является то, что Linux не предоставляет столько же дублированных программных интерфейсов. Например, даже программисты, занимавшиеся написанием кода исключительно для систем SVR4, предпочитали сокеты Беркли интерфейсу транспортного уровня (TLI) из SysV; Linux избегает накладных расходов TLI и предоставляет только сокеты.

Когда доступных стандартов (официальных, де-юре, и неофициальных, де-факто) недостаточно для реализации, Linux иногда предлагает свои собственные расширения, не учитывающие POSIX. Например, асинхронная POSIX-спецификация асинхронного ввода-вывода в большинстве случаев рассматривается как неадекватная для многих реальных приложений, поэтому в Linux реализован стандарт POSIX как оболочка для более общей и полезной реализации. Также не существует общей спецификации для высоко масштабируемого интерфейса опроса ввода-вывода, поэтому был разработан и добавлен совершенно новый интерфейс epoll. Мы обратимся к этим нестандартным интерфейсам, как только они будут документированы.