Книга известных профессионалов в области разработки коммерческих приложений в Linux представляет собой отличный справочник для широкого круга программистов в Linux, а также тех разработчиков на языке С, которые перешли в среду Linux из других операционных систем. Подробно рассматриваются концепции, лежащие в основе процесса создания системных приложений, а также разнообразные доступные инструменты и библиотеки. Среди рассматриваемых в книге вопросов можно выделить анализ особенностей применения лицензий GNU, использование свободно распространяемых компиляторов и библиотек, системное программирование для Linux, а также написание и отладка собственных переносимых библиотек. Изобилие хорошо документированных примеров кода помогает лучше усвоить особенности программирования в Linux.
Книга рассчитана на разработчиков разной квалификации, а также может быть полезна для студентов и преподавателей соответствующих специальностей.
Введение
Данная книга предназначена для опытных (или не столь опытных, но желающих обучаться) программистов, которые намереваются разрабатывать программное обеспечение для Linux или переносить его в Linux с других платформ. Эта книга понадобиться во время обучения программированию в Linux, потом же она станет настольным справочником. После написания первых трех глав первого издания мы использовали черновики как справочный материал во время повседневной работы.
Второе издание книги было существенно обновлено. Кроме того, был открыт сайт, посвященный книге, — http://ladweb.net/.
Операционная система Linux разработана так, чтобы быть максимально похожей на Unix. Книга даст вам хорошие основы программирования в Unix-стиле. Linux существенно ничем не отличается от Unix; впрочем, некоторые различия есть, но они не более значительны, чем типичные отличия между двумя версиями Unix. Эта книга представляет собой руководство по программированию Unix, написанное с точки зрения Linux, с информацией, специфической для Linux.
Linux также имеет уникальные расширения, например, возможности прямого доступа к экрану (см. главу 21), а также средства, используемые в нем более часто, чем в других системах вроде библиотеки
popt
(см. главу 26). Материал этой книги охватывает многие такие средства и возможности, поэтому вы сможете создавать программы, по- настоящему пользующиеся преимуществами Linux.
• Если вы являетесь программистом на языке С, но не знакомы ни с Unix, ни с Linux, то внимательное чтение этой книги и работа с примерами окажет серьезную помощь на пути вашего становления квалифицированным программистом для Linux. Воспользовавшись дополнительно системной документацией, вы легко сможете перейти в любую версию Unix.
Часть I
Начало работы
Глава 1
История создания Linux
Термин
Linux
используется для обозначения разных понятий. Технически точным определением является следующее.
Однако многие подразумевают под термином
Linux
всю операционную систему, основанную на ядре Linux.
В этой книге используется второе определение, поскольку вы будете программировать не только для ядра, а для всей операционной системы.
1.1. Краткая история свободного программного обеспечения Unix
Предлагаемая история упрощена и основана на самых важных элементах системы Linux. Более длинную и равномерную историю можно прочесть в книге
A Quarter Century of UNIX
[29].
Во времена появления вычислительной техники программное обеспечение (ПО) рассматривалось лишь как свойство оборудования. При продаже внимание уделялось именно аппаратуре, поэтому компании отдавали ПО вместе со своими системами. Улучшения, новые алгоритмы и идеи свободно распространялись среди студентов, профессоров и корпоративных исследователей.
Вскоре компании обратили внимание на ценность ПО как интеллектуальной собственности. Они начали придавать законную силу авторским правам на свои технологии ПО и ограничивать распространение исходных и двоичных кодов. Инновации, ранее рассматривавшиеся как общественная собственность, стали яростно защищаемым корпоративным имуществом, что изменило культуру разработки компьютерного ПО.
Ричард Столлман (Richard Stallman) из Массачусетсского технологического института (MIT) не хотел, чтобы инновации ПО во всем мире контролировались корпоративными амбициями, поэтому он основал Фонд свободного программного обеспечения (Free Software Foundation — FSF). Целью FSF стало поощрение разработки и использования ПО без ограничений на свободное распространение.
Однако слово "free" в этом контексте вызвало недоразумения. Под словом "free" Ричард Столлман подразумевал свободу, а не нулевую цену. Он твердо убежден, что ПО и связанная с ним документация должны быть доступны с исходным кодом, без ограничений на дополнительное распространение. Не так давно появился термин
Open Source
(открытый исходный код) для описания тех же целей (без слова "free", вызывающего недоразумения). Термины
Open Source
и
Free Software
(свободное ПО) обычно рассматриваются как синонимы.
1.2. Разработка Linux
В 1991 году Линус Торвальдс (Linus Torvalds), в то время студент Хельсинкского университета, начал проект, целью которого было обучение низкоуровневому программированию для процессора Intel 80386. В то время он работал с операционной системой Minix, созданной Эндрю Таненбаумом (Andrew Tanenbaum), поэтому изначально совмещал свой проект с системными вызовами Minix и структурой дисковой файловой системы. Реализовав первую версию ядра Linux в Internet под довольно ограничивающей лицензией, вскоре он, однако, сменил эту лицензию на GPL.
Сочетание GPL и первоначального набора функций ядра Linux убедило других разработчиков предложить свою помощь при разработке ядра. Реализация библиотеки С, производная от потенциального в то время проекта библиотеки GNU С, позволила разработчикам создавать "родные" пользовательские приложения. Затем последовали собственные версии
gcc
, Emacs и
bash
. В 1992 году разработчик со средней квалификацией мог установить и загрузить версию Linux 0.95 на большинстве машин с процессором Intel 80386.
Проект Linux с самого начала был тесно связан с проектом GNU. Исходная база проекта GNU стала очень важным ресурсом сообщества Linux для создания завершенной системы. Хотя значительное количество систем, основанных на Linux, произведены из источников, которые включают свободно доступный код Unix Калифорнийского университета в Беркли и консорциума X Consortium, многие важные части функциональной системы Linux напрямую связаны с проектом GNU.
По мере развития Linux некоторые лица, а позже и компании, сосредоточились на облегчении инсталляции и практичности систем Linux для новых пользователей, создав пакеты ядра Linux, называемые
дистрибутивами
, а также логически полный набор утилит. Все это образовало завершенную операционную систему.
Кроме ядра Linux, дистрибутив Linux содержит библиотеки разработки, компиляторы, интерпретаторы, оболочки, приложения, утилиты, графические операционные среды, конфигурационные инструменты и многие другие компоненты. При построении системы Linux разработчики дистрибутива собирают компоненты из разных мест с целью создания полной коллекции всех компонентов ПО, необходимых для нормального функционирования. Большинство дистрибутивов также содержат пользовательские компоненты, облегчающие инсталляцию и эксплуатацию системы Linux.
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.
1.4. Происхождение Linux
"Широта выбора — самое лучшее качество, присущее стандартам".
[1]
К услугам разработчиков Linux была двадцатилетняя история Unix, но более важным является то, что справочными материалами им служили высококачественные стандарты. Изначально Linux разрабатывался в соответствии с POSIX; там, где не было POSIX, Linux следовала практике System V, за исключением организации сетей, где и системные вызовы, и организация сетей придерживались намного более популярной модели BSD. Теперь, когда существует объединенный стандарт SUS/POSIX, дальнейшее развитие обычно совместимо с более новым стандартом POSIX, а прошлые отклонения от него по возможности откорректированы.
Самым существенным отличием между SVR4 и Linux с точки зрения программирования является то, что Linux не предоставляет столько же дублированных программных интерфейсов. Например, даже программисты, занимавшиеся написанием кода исключительно для систем SVR4, предпочитали сокеты Беркли интерфейсу транспортного уровня (TLI) из SysV; Linux избегает накладных расходов TLI и предоставляет только сокеты.
Когда доступных стандартов (официальных,
де-юре
, и неофициальных,
де-факто
) недостаточно для реализации, Linux иногда предлагает свои собственные расширения, не учитывающие POSIX. Например, асинхронная POSIX-спецификация асинхронного ввода-вывода в большинстве случаев рассматривается как неадекватная для многих реальных приложений, поэтому в Linux реализован стандарт POSIX как оболочка для более общей и полезной реализации. Также не существует общей спецификации для высоко масштабируемого интерфейса опроса ввода-вывода, поэтому был разработан и добавлен совершенно новый интерфейс
epoll
. Мы обратимся к этим нестандартным интерфейсам, как только они будут документированы.
Глава 2
Лицензии и авторские права
Новички в мире свободного ПО часто смущены большим количеством лицензий, с ним связанных. Некоторые приверженцы свободного ПО превращают нормальные слова в жаргон и ожидают понимания всех нюансов, связанных с каждым элементом жаргона.
Для написания и распространения ПО, работающего на свободной платформе, такой как Linux, необходимо ориентироваться в лицензиях и авторском праве. Эти понятия часто путаются интеллигентными и образованными людьми, среди которых находятся и приверженцы свободного ПО. Если вы намереваетесь написать свободное или коммерческое ПО, вы будете работать с инструментами, сопровождаемыми множеством лицензионных условий. Общее понимание сферы авторского права и лицензирования поможет избежать распространенных ошибок.
В эти спорные времена крайне необходимо предупредить вас о том, что
мы не являемся юристами
. Глава отражает наше понимание обсуждаемых проблем, но не предлагает юридических советов. Перед тем, как принимать решения относительно вашей или чьей-либо интеллектуальной собственности, следует более глубоко изучить проблему и в случае необходимости проконсультироваться с юристом.
2.1. Авторское право
Сначала рассмотрим более простую проблему.
Авторское право
(copyright) — это простая защита владения определенными видами интеллектуальной собственности. В соответствии с новейшими соглашениями об авторском праве вам даже не понадобится требовать авторских прав на создаваемый вами материал. Пока вы явно не откажетесь от права собственности, другим лицам будет разрешено использовать вашу интеллектуальную собственность только в строго определенном порядке, называемом
законным использованием
, пока вы явно не предоставите им разрешение, называемое
лицензией
, на другие действия. Так что если вы напишете книгу или элемент ПО, вам не нужно помещать на них фразу типа "copyright ©
год
", чтобы получить право собственности на них. Однако если вы не поместите эту фразу в свою работу, вам будет намного сложнее требовать защиты права собственности в суде, если кто-то нарушит либо ваши авторские права (заявляя о том или действуя так, как будто вам не принадлежат авторские права), либо ваши лицензионные условия.
Бернское соглашение об авторском праве (http://www.wipo.org), международный договор о соглашениях об авторском праве и смежных правах, требует от стран-участниц придавать авторским правам законную силу только в случае:
Последовательность
(с)
обычно используется в качестве замены "с" нижнего регистра внутри круга, но суды этого не поддерживают. Всегда используйте слова
Copyright
(в дополнение к последовательности
(с)
, если вы решили ее применять) при упоминании своих авторских прав. Если вам доступен символ ©, лучше воспользоваться им, но все-таки не игнорировать слово
Copyright
.
Авторские права не вечны. Вся интеллектуальная собственность со временем становится
всеобщим достоянием
; это означает, что общество со временем присваивает авторские права на собственность, и любой человек может сделать с этой собственностью все, что угодно. Лицензионные условия утрачивают свою обязательность, как только собственность становится всеобщим достоянием. Существует следующая уловка: если вы создаете
2.2. Лицензирование
Владельцы авторских прав могут открыто ставить условия лицензии. Наиболее распространенные области ограничения (или разрешения) включают использование, копирование, распространение и изменение. Конкретным примером является общедоступная лицензия GNU (GPL, часто называемая
законной левой копией
), явно не ограничивающая использование. Она ограничивает только "копирование, распространение и изменение".
Приведем пример жаргона сферы свободного ПО, с которым вы наверняка намереваетесь ознакомиться. В сфере свободного ПО фраза
общее достояние
используется исключительно касательно права собственности. Ссылки в журнальных статьях на GPL как на "авторское право общественного достояния" неверны, поскольку GPL не предоставляет общественному достоянию владение авторским правом; ссылки же на нее как на "лицензию общественного достояния" верны, поскольку GPL явно не помещает лицензионных ограничений на использование. Однако фанатики свободного ПО считают такое использование
общественного достояния
полностью некорректным.
Определенные лицензионные ограничения могут быть незаконными в некоторых местностях. Большинство государственных органов предотвращают ограничение того, что считается ими
законным использованием
в лицензионном соглашении. Например, многие европейские страны явно разрешают реконструирование ПО и оборудования в определенных целях, несмотря на лицензионные ограничения подобной деятельности. Поэтому большинство лицензионных соглашений включают
статью о разделимости
вроде приведенной ниже статьи из GPL.
В большинстве лицензионных соглашений для выражения этой же мысли используется менее понятный язык.
2.3. Лицензии на свободное ПО
Как описывалось в главе 1, термин
открытый исходный код
(Open Source) был создан как результат попытки разрешить споры вокруг слов "свободный" и "открытый" (free) в словосочетании "свободное ПО" ("free software"). Для управления понятием "открытый исходный код" была создана
Инициатива открытого исходного кода
(Open source Initiative — OSI) и, несмотря на то, что ее попытки зарегистрировать торговую марку термина (для защиты его значения) были отклонены Службой патентов и торговых знаков США (US Patent and Trademark Office), OSI получила в свое распоряжение знак сертификации "
свободное ПО, сертифицированное OSI
". (Законных ограничений на использование термина
открытый исходный код
не существует, но они существуют относительно знака сертификации "
свободное ПО, сертифицированное OSI
".)
OSI поддерживает
определение открытого исходного кода
(Open Source Definition — OSD) — описание прав, предоставляемое лицензиями открытого исходного кода; она также поддерживает полный список сертифицированных ею лицензий, чтобы удовлетворить запросы OSD, среди которых — доступность исходного кода, отсутствие ограничений на свободное распространение продукта, разрешение производных работ, а также запрет дискриминации лиц, групп или областей для попыток. Полное OSD вместе со списком лицензий, сертифицированных как "свободное ПО, сертифицированное OSI", доступно на сайте http://opensource.org/.
2.3.1. Общедоступная лицензия GNU
GPL является одной из самых ограничивающих лицензий свободного ПО. Если вы включаете исходный код, лицензированный GPL в другой программе, к этой программе при лицензировании также должны быть применены условия GPL
[2]
. В Фонде свободного программного обеспечения (FSF, автор GPL) считают, что выполнение связывания с помощью библиотеки "создает производную работу"; другие трактуют ее как "работу простого агрегирования". Поэтому в FSF утверждают, что вам нельзя выполнять компоновку с библиотекой, к которой применены условия GPL, если к компонуемой программе не применяется лицензия GPL. Однако некоторые лица придерживаются мнения, что связывание — это "простое агрегирование", тогда как GPL утверждает следующее.
Если вы рассматриваете исполняемый файл как "том внешней памяти", можете прибегнуть к полному агрегированию.
Насколько нам известно, это определение еще не было проверено в суде. В маловероятном случае возникновения желания связать с библиотекой программу, к которой не применены условия GPL, обратитесь к авторам библиотеки за их интерпретацией.
2.3.2. Общедоступная лицензия библиотеки GNU
Общедоступная библиотечная лицензия GNU (GNU Library General Public Licence — LGPL) предназначена для увеличения общей полезности библиотек. Цель LGPL — разрешить пользователям обновлять или улучшать свои библиотеки без необходимости получения новых версий программ, компонуемых с этими библиотеками. С этой целью LGPL не пытается установить какие-то лицензионные ограничения на программы, компонуемые с библиотекой, до тех пор, пока эти программы скомпонованы с совместно используемыми версиями библиотек, к которым применены условия LGPL, или которые снабжены объектными файлами для приложения, позволяя пользователю заново связывать приложение с новыми либо усовершенствованными версиями библиотеки.
На практике это ограничение незначительно; будет неразумно не применять для компоновки совместно используемые библиотеки, если они доступны.
К очень немногим библиотекам применены условия GPL; большинство из них подпадает под действие LGPL. Библиотеки, подчиняющиеся GPL, обычно трактуются в соответствие с LGPL, поскольку авторы библиотек не были в курсе либо не приняли во внимание существование LGPL. В ответ на вежливую просьбу многие авторы обновляют лицензию своих библиотек, применяя к ним условия LGPL.
2.3.3. Лицензии стиля MIT/X/BSD
Лицензии стиля MIT/X намного проще, чем GPL или LGPL; их единственным ограничением является (если по простому) поддержка всех существующих уведомлений об авторских правах и лицензионных условий в исходном либо двоичном распространении, и запрет использования имени любого автора без его письменного соглашения в целях подтверждения либо продвижения производных работ.
2.3.4. Лицензии старого стиля BSD
Лицензии старого стиля BSD добавляют к условиям лицензий MIT/X существенное ограничение, которое состоит в том, что рекламные материалы, упоминающие свойства ПО, включают подтверждение. Сама лицензия BSD была изменена с целью устранения этого ограничения, но некоторое ПО продолжает пользоваться лицензиями, смоделированными по старой лицензии BSD.
Глава 3
Онлайновая системная документация
Web-сайт, посвященный этой книге и доступный по адресу http://ladweb.net, содержит дополнения к тексту книги, детальную информацию по темам, выходящим за рамки книги, и ссылки на дополнительные сведения в Internet.
3.1. Оперативные страницы руководства
Доступ к оперативным страницам руководства (man-страницам), дающим справку о системе, можно получить с помощью команды
man
. Чтобы прочитать справочную страницу самой команды
man
, введите в командной строке
man man
. Оперативные страницы руководства обычно содержат справочную документацию, а не консультативную информацию, и славятся своей краткостью, из-за чего иногда возникают трудности в их понимании. Однако если вам понадобится справочный материал, они могут оказаться именно тем, что вам нужно.
Доступ к оперативным страницам руководства предоставляется тремя программами. Программа
man
отображает отдельные оперативные страницы руководства, а команды
apropos
и
whatis
ищут ключевые слова в наборе оперативных страниц руководства. Команды
apropos
и
whatis
производят поиск в одной и той же базе данных; различие состоит в том, что
whatis
отображает только строки, в точности соответствующие слову, которое вы ищете, a
apropos
отображает любую строку, содержащую слово, которое вы ищете. К примеру, если вы ищете
man
,
apropos
отобразит
manager
и
manipulation
, в то время как
whatis
отобразит лишь слово
man
, отделенное от других букв пробелом либо знаком пунктуации, например,
man.config
. Попробуйте запустить команды
whatis man
и
apropos man
, чтобы увидеть разницу.
Многие оперативные страницы руководства в Linux являются частью большого пакета, собранного процессором лингвистической информации (language data processor — LDP). А именно, страницы разделов 2 (системные вызовы), 3 (библиотеки), 4 (специальные файлы или файлы устройств) и 5 (форматы файлов) принадлежат в основном к коллекции оперативных страниц руководства LDP и являются наиболее полезными в программировании. Если необходимо выяснить, какой раздел следует просмотреть, укажите номер этого раздела перед названием оперативной страницы руководства, которую вы намереваетесь просмотреть.
Например,
man man
предоставляет оперативную страницу руководства для команды
man
из раздела 1; если вы хотите просмотреть спецификацию о написании оперативных страниц руководства, укажите раздел 7 —
Во время просмотра оперативных страниц руководства помните, что многие системные вызовы и библиотечные функции имеют одинаковые имена. В большинстве случаев вам требуются сведения о библиотечных функциях, с которыми вы будете осуществлять компоновку, а не о системных вызовах, к которым периодически обращаются эти библиотечные функции. Для доступа к описанию библиотечных функций применяйте
3.2. Информационные страницы
В проекте GNU для представления документации был принят формат Texinfo. Документацию Texinfo можно распечатать (используя преобразование в ТЕХ) либо прочитать в онлайне (в формате "info", очень раннем гипертекстовом формате, предшествующем World Wide Web). В Linux существует множество программ для чтения информационной документации. Ниже приведен небольшой перечень.
• В редакторе Emacs есть режим чтения информации; наберите
<ESC> X info
для входа в этот режим.
• Программы
info
и
pinfо
являются небольшими программами текстового режима для быстрого просмотра информационных страниц.
• Большинство программ системной документации (например, программы
yelp
от GNOME и
khelpcenter
от KDE) могут отображать информационные страницы. Мы рекомендуем эти инструменты, поскольку они предоставляют гипертекстовый интерфейс к информационным страницам, более знакомый всем, кто умеет использовать Web-браузер, чем интерфейс, предоставляемый Emacs,
info
или
pinfо
. (Эти инструменты также предлагают другую системную документацию, например, оперативные страницы руководства и документацию по системе, частью которой они являются.)
3.3. Прочая документация
Каталог
/usr/share/doc
представляет собой всеохватывающее место для несобранной иными способами документации. Большинство пакетов, установленных в вашей системе, инсталлируют внутри каталога
/usr/share/doc
файлы "README", документацию в разных форматах (включая простой текст, PostScript, PDF и HTML) и примеры. У каждого пакета имеется свой собственный каталог, носящий имя этого пакета и номер его версии.
