КулЛиб - Скачать fb2 - Читать онлайн - Отзывы
Всего книг - 402933 томов
Объем библиотеки - 530 Гб.
Всего авторов - 171488
Пользователей - 91546

Впечатления

Stribog73 про Ван хее: Стихи (Поэзия)

Жаль, что перевод дословный, без попытки создать рифму.
Нельзя так стихи переводить. Нельзя!
Вот так надо стихи переводить:
Олесь Бердник
МОЛИТВА ТАЙНОМУ ДУХУ ПРАОТЦА

Понад світами погляду і слуху,
Над царствами і світла, й темноти —
Прийди до нас, преславний Отче Духу,
Прийди до нас і серце освяти.

Під громи зла, в годину надзвичайну,
Коли душа не зна, куди іти,
Зійди до нас, преславний Отче Тайни,
Зійди до нас, і думу освяти.

Відкрий нам Браму, де злагода дише,
Дозволь ступить на райдужні мости!
Прийди до нас, преславний Отче Тиші,
Прийди до нас, і Дух наш освяти.

Мой перевод:

Над миром взгляда и над миром слуха,
Над царством света, царством темноты —
Приди к нам, о преславный Отче Духа,
Приди к нам и сердца нам освяти.

Под громы зла, в тот час необычайный,
Когда душа не ведает пути,
Сойди к нам, о преславный Отче Тайны,
Сойди к нам, наши мысли освяти.

Открой Врата нам, где согласье дышит,
Позволь ступить на яркие мосты!
Приди к нам, о преславный Отче Тиши,
Приди к нам, наши Души освяти.

Рейтинг: +1 ( 2 за, 1 против).
Stribog73 про Бабин: Распад (Современная проза)

Саша Бабин молодой еще человек, но рассказ очень мне понравился. Жаль, что нашел пока только один его рассказ.

Рейтинг: +2 ( 2 за, 0 против).
Stribog73 про Балтер: До свидания, мальчики! (Советская классическая проза)

Почитайте, ребята. Очень хорошая и грустная история!

P.S. Грустная для тех, кому уже за сорок.

Рейтинг: +2 ( 2 за, 0 против).
Любопытная про Быкова: Любовь попаданки (Любовная фантастика)

Вот и хорошо , что книга заблокирована.
Ранее уже была под названием Маша и любовь.
Какие то скучные розовые «сопли». То, хочу, люблю одного, то любовь закончилась, люблю пришельца, но не дам ему.. Долго, очень уныло и тоскливо , совершенно не интересно.. Как будто ГГ лет 13-14..Глупые герои, глупые ситуации.

Рейтинг: 0 ( 0 за, 0 против).
ZYRA про Сидоров: Проводник (СИ) (Альтернативная история)

Книга понравилась. Стиль изложения, тонкий юмор, всё на высоте. Можно было бы сюжет развить в сериал, всяческих точек бифуркации в истории великое множество. С удовольствием почитал бы возможное продолжение. Автору респект.

Рейтинг: -1 ( 1 за, 2 против).
Шляпсен про Бельский: Могущество Правителя (СИ) (Боевая фантастика)

Хз чё за книжка, но тёлка на обложке секс

Рейтинг: -2 ( 0 за, 2 против).
Шляпсен про Силоч: Союз нерушимый… (Боевая фантастика)

Правообладателю наш пламенный привет

Рейтинг: 0 ( 0 за, 0 против).

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

- Разработка приложений в среде Linux. Второе издание (пер. Н. А. Мухин, ...) 1.77 Мб, 639с. (скачать fb2) - Майкл К. Джонсон - Эрик В. Троан

Настройки текста:



Разработка приложений в среде 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.

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

• Если вы являетесь программистом в Linux, в данной книге раскрыты "проблемные" темы и облегчены многие задачи программирования. Почти каждая глава покажется вам знакомой, поскольку вы уже обладаете необходимыми знаниями Linux. Тем не менее, несмотря на имеющийся опыт, материал этой книги вы сочтете полезным.

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

Данная книга не охватывает всех подробностей программирования в Linux. В ней не рассказывается о базовом интерфейсе, определенном ANSI/ISO С — об этом можно прочитать в других книгах. В ней не рассматриваются другие языки программирования, доступные в Linux, а также графические библиотеки, являющиеся идентичными независимо от используемой системы — это рассматривается в книгах, ориентированных на упомянутые области. Мы предоставляем информацию, необходимую для прохождения пути от программиста на С для систем, подобных Windows, Macintosh или даже DOS, до программиста на С для Linux.

Структурно книга состоит из четырех частей.

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

• Во второй части рассматриваются наиболее важные аспекты среды разработки — компиляторы, компоновщик и загрузчик, а также некоторые отладочные инструменты, не столь широко применяемые на других платформах.

• В третьей, основной, части рассматривается интерфейс ядра и системных библиотек, в первую очередь задуманных в качестве интерфейса ядра. В этой части только главы 19, 20 и 21 обладают ярко выраженной спецификой Linux; внимание в основном уделяется общему программированию в Unix с точки зрения Linux. В новой во втором издании главе 22 описаны основы разработки защищенных программ.

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

Если вы уже знакомы с программированием в Linux или Unix, можете читать главы этой книги в любом порядке, пропуская то, что вас не интересует. Если вы не знакомы с Linux или Unix, большинство глав будут полезны, но для начала рекомендуется чтение глав 1, 2, 4, 5, 9, 10, 11 и 14, поскольку они предоставляют большинство информации, знание которой необходимо для чтения других глав. В частности, в главах 10, 11 и 14 формируется основа модели программирования в Unix и Linux.

Следующие книги, несмотря на то, что некоторые темы в них совпадают, в основном дополняют данную книгу, будучи проще, сложнее, либо рассматривая сходные темы.

• The С Programming Language, second edition (Язык программирования С (Си), Брайан У. Керниган, Деннис М. Ритчи, ИД "Вильямс", 2005 год) [15]. Кратко обучает стандартному программированию на ANSI С с небольшой ссылкой на операционную систему. Она предназначена для читателей, имеющих навыки программирования.

• Practical С Programming [27]. Обучает программированию и стилю С шаг за шагом. Это пособие для начинающих, предназначенное для тех, кто не имеет никакого опыта программирования.

• Programming with GNU Software [19]. Представляет собой введение в среду программирования GNU, включающее главы, посвященные запуску компилятора С, отладчика, утилиты make и системы управления исходным кодом RCS.

• Advanced Programming in the UNIX Environment [35]. Охватывает наиболее важные системы Unix и системы, подобные Unix, однако предшествует появлению Linux. В книге рассматривается материал, аналогичный представленному в двух заключительных глав настоящей книги: системные вызовы и библиотеки совместного использования. Кроме того, в ней предложено множество примеров и объясняются различия между версиями Unix.

• UNIX Network Programming [33]. Подробно рассматривает сетевое программирование, включая традиционные виды организации сетей, недоступных в Linux. Во время чтения этой книги особое внимание следует уделять интерфейсу сокетов Беркли (см. главу 17), который обеспечивает максимальную переносимость. Эта книга пригодится, если возникнет потребность в модификации кода для переноса сетевой программы Linux в среду какой-нибудь новой разновидности Unix.

• A Practical Guide to Red Hat Linux 8 [32]. Книга почти на 1500 страниц, содержащая информацию о применении Linux, программировании оболочки и системном администрировании. Несмотря на то что в названии книги упоминается Red Hat Linux 8, большинство содержащейся в ней информации относится ко всем разновидностям Linux. Она также содержит краткую ссылку на многие утилиты, содержащиеся в системе Linux.

• Linux in a Nutshell [31]. Предоставляет краткую информацию об утилитах.

• Linux Device Drivers, second edition [28]. Обучает написанию драйверов устройств Linux как тех, кто знаком с кодом операционной системы, так и тех, кто с ним не знаком.

Полный список рекомендуемой литературы можно найти в конце книги.

Все исходные коды данной книги являются производными от тщательно протестированных рабочих примеров. Исходные коды доступны на сайте http://ladweb.net, а также на сайте издательства. Для ясности в некоторых коротких фрагментах кода оставлены проверки лишь наиболее типичных ошибок, а не всех возможных. Тем не менее, в загружаемых кодах вы найдете проверки всех существенных ошибок.

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

Операционная система Linux стремительно развивается, и ко времени прочтения книги некоторые факты могут измениться. Данная книга была написана с учетом ядра Linux 2.6 и библиотеки GNU С версии 2.3.

Второе издание

Ниже перечислены добавления и модификации, появившиеся во втором издании книги.

• Вся книга была обновлена с учетом новой спецификации Unix версии 6 — обновленной версии стандарта POSIX.

• Небольшие фрагменты исходного кода примеров приводятся с номерами строк, облегчая ориентирование в соответствии с полным исходным кодом.

• Глава 1 содержит обновленную и расширенную историю разработки Linux.

• В главе 4 рассматриваются утилиты strace и ltrace.

• В главе 6 рассматривается библиотека GNU С (glibc) и стандарты, на которых она основана. Также в этой главе объясняется, как и почему следует использовать макросы проверки свойств. Кроме того, описываются основные системные вызовы, рассматриваемые во всех разделах книги; способы обнаружения возможностей системы во время выполнения; разнообразные интерфейсы, предоставляемые glibc; подход glibc к обратной совместимости.

• Глава 7 содержит значительно расширенную информацию об инструментах отладки памяти, включая новые свойства отладки памяти библиотеки GNU С, новую версию mpr и новый инструмент Valgrind.

• В главе 12 рассматриваются сигналы реального времени и контексты сигналов.

• В главе 13 документируются системные вызовы poll() и epoll, предоставляющие рекомендуемые альтернативы select().

• В главе 16 рассматривается и рекомендуется новый механизм распределения псевдотерминалов (Pseudo TTY). Также внимание уделяется системным базам данных utmp и wtmp.

• В главе 17 рассматривается как IPv6, так и IPv4, включая новые интерфейсы системных библиотек для написания программ, которые могут равнозначно использовать IPv6 и IPv4. Также рассматриваются более ранние интерфейсы, которым уделялось внимание в первом издании, чтобы дать возможность поддерживать код, использующий эти интерфейсы, и переносить его в более новые интерфейсы. Кроме того, обсуждается более широкий набор функций, чем нужен для многих сетевых серверов, например, неблокирующая accept().

• Глава 22 — это новая глава, в которой рассматриваются основные требования к написанию защищенных программ и объясняется, почему вопросы безопасности относятся ко всем программам, а не только к системным демонам и утилитам.

• Глава 23 содержит более полное обсуждение использования регулярных выражений, включая простую версию утилиты grep в качестве примера.

• В главе 26 рассматриваются новейшие улучшения библиотеки popt и усовершенствованный код примера.

• К главе 28 добавлена реализация Linux-PAM.

• В главе 25 документируется библиотека qdbm, а не Berkeley db, поскольку лицензия qdbm является менее ограничивающей.

• Почти каждая глава содержит важные обновления.

Описанные ниже материалы из книги были изъяты.

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

• Информация об управлении портами ввода-вывода; это обычно использовать не рекомендуется, поскольку оно конфликтует со структурой управления устройствами и режимом электропитания Linux.

• Точные копии общедоступной лицензии GNU и библиотеки GNU. Несмотря на свою важность, перепечатка этих лицензий не улучшает знание их содержания. Также со времени публикации первого издания увеличилась важность ряда других лицензий.

• Инструмент отладки памяти Checker больше не поддерживается, поэтому во втором издании не рассматривается.

Благодарности

Мы благодарим наших технических рецензентов за потраченное время и тщательность. Их предложения помогли улучшить эту книгу. Особую благодарность выражаем Линусу Торвальдсу (Linus Torvalds), Алану Коксу (Alan Сох), Теду Тсо (Ted Ts'o) и Арьену ван де Вену (Arjan van de Ven), которые нашли время, чтобы ответить на наши вопросы.

Поддержав нас в написании первого издания, наши жены — Ким Джонсон (Kim Johnson) и Бригид Троан (Brigid Troan) были так терпеливы и великодушны, что побудили нас написать второе издание. Без их помощи и поддержки не удалось бы написать эту книгу, не говоря уже о ее переиздании.

От издательства

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

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

Отправляя письмо или сообщение, не забудьте указать название книги и ее авторов, а также свой обратный адрес. Мы внимательно ознакомимся с вашим мнением и обязательно учтем его при отборе и подготовке к изданию новых книг.

Наши электронные адреса:

E-mail: info@williamspublishing.com

WWW: http://www.williamspublishing.com

Наши почтовые адреса:

в России: 115419, Москва, а/я 783

в Украине: 03150, Киев, а/я 152

Часть I Начало работы

Глава 1 История создания Linux

Термин Linux используется для обозначения разных понятий. Технически точным определением является следующее.

Linux — это свободно распространяемое ядро Unix-подобной операционной системы.

Однако многие подразумевают под термином Linux всю операционную систему, основанную на ядре Linux.

Linux — это свободно распространяемая Unix-подобная операционная система, включающая ядро, системные инструменты, приложения и завершенную среду разработки.

В этой книге используется второе определение, поскольку вы будете программировать не только для ядра, а для всей операционной системы.

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

С другой стороны, после работы с Linux вы можете предпочесть пользоваться только ею, не утруждая себя переносом.

Linux — это не просто еще одна система, подобная Unix. Это не просто хорошая платформа, куда можно переносить программы — это также хорошая платформа, на которой можно создавать и запускать приложения. Она широко используется во всем мире, помогая популяризировать концепцию открытого исходного кода (Open Source) или свободного программного обеспечения (Free Software). Краткий экскурс в историю поможет понять, как и почему это случилось.

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 (свободное ПО) обычно рассматриваются как синонимы.

С целью продвижения своей идеи Ричард Столлман не без помощи других создал общедоступную лицензию (General Public License — GPL). Эта лицензия оказала настолько большое влияние, что аббревиатура GPL вошла в жаргон разработчиков как глагол; вместо "применить условия GPL к создаваемому вами ПО" часто говорят "to GPL".

Лицензия GPL состоит из трех пунктов.

1. Каждый получатель ПО, подпадающего под условия GPL, имеет право получить исходный код этого ПО без дополнительной платы (исключая плату за доставку).

2. Любое ПО, производное от ПО, подпадающего под условия GPL, должно сохранить GPL в качестве лицензии для свободного распространения.

3. Любой владелец ПО, подпадающего под условия GPL, имеет право распространения этого ПО на условиях, не конфликтующих с GPL.

Важным является то, что в этих лицензионных условиях не упоминается цена (за исключением ситуации, когда исходный код не разрешается поставлять как продукт с дополнительной стоимостью). ПО, подпадающее под условия GPL, может продаваться клиентам по любой цене. Однако затем эти клиенты имеют права на распространение ПО, включая исходный код, по собственному усмотрению. С появлением Internet это право приобрело эффект сохранения низкой цены ПО, соответствующего лицензии GPL (обычно она равняется нулю), одновременно давая компаниям возможность продавать такое ПО и предоставлять услуги вроде поддержки, которые его дополняют.

Частью GPL, вызывающей больше всего противоречий, является второй пункт: к ПО, производному от ПО, соответствующего лицензии GPL, должны быть также применены условия GPL. Хотя недоброжелатели из-за этого пункта называют GPL "вирусом", сторонники настаивают на том, что этот пункт является одной из самых сильных сторон GPL. Он предотвращает ситуации, когда компании получают ПО, подпадающее под условия GPL, добавляют в него несколько свойств и делают из результата патентованный пакет.

Основным проектом участников FSF является проект GNU's Not Unix (GNU), цель которого — создание свободно распространяемой Unix-подобной операционной системы. При запуске проекта GNU было очень мало высококачественного свободно распространяемого ПО, поэтому его участники начали с создания приложений и инструментов для будущей системы, а не с самой операционной системы. Поскольку лицензия GPL была также произведена FSF, ко многим ключевым компонентам операционной системы GNU применены условия GPL, но на протяжении многих лет проект GNU принял многие другие пакеты, например, X Window System, систему верстки ТЕХ и язык Perl, свободно распространяемые под другими лицензиями.

Результатом проекта GNU стало несколько основных пакетов и множество второстепенных. Основные пакеты включают редактор Emacs, библиотеку GNU С, коллекцию компиляторов GNU (gcc, как изначально назывался компилятор GNU С перед добавлением С++), оболочку bash и gawk (GNU's awk). Второстепенные пакеты включают высококачественные утилиты оболочек и программы обработки текста, которые обычно присутствуют в системе Unix.

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.

Доступно множество дистрибутивов 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, а прошлые отклонения от него по возможности откорректированы.

Самым существенным отличием между 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.

Авторские права не вечны. Вся интеллектуальная собственность со временем становится всеобщим достоянием; это означает, что общество со временем присваивает авторские права на собственность, и любой человек может сделать с этой собственностью все, что угодно. Лицензионные условия утрачивают свою обязательность, как только собственность становится всеобщим достоянием. Существует следующая уловка: если вы создаете производную работу, основанную на работе общего пользования, вы получаете авторские права на свои изменения. Поэтому, несмотря на то, что авторские права на многие старые книги уже истекли, став всеобщим достоянием, редакторы часто вносят небольшие изменения, исправляя ошибки, допущенные в оригинале. Затем они часто требуют права собственности на производную работу, включающую внесенные ими изменения. Эти авторские права предотвращают законное копирование отредактированной версии, хотя вы можете свободно копировать оригинал с истекшими авторскими правами, который является всеобщим достоянием.

Существуют ограничения того, что может охраняться авторскими правами. Невозможно опубликовать книгу, содержащую только слово "the", и затем пытаться требовать лицензионной платы от всех, кто использует это слово в своих книгах. Однако если вы создадите стилизованное изображение слова "the", то сможете приобрести на это авторские права, если докажете, что ранее такого написания не существовало. Несмотря на то что мы можем открыто использовать слово "the", мы не имеем право продавать репродукции вашей работы, не получив от вас лицензию.

Такие ограничения применяются и к ПО. Если вы имеете лицензионное право на изменение чьего-либо ПО, но вносите совершенно незначительное изменение, будет абсурдно требовать авторские права на это изменение. Вы не сможете защищать требование авторских прав на это изменение в суде; ваше изменение будет общим достоянием, так же, как и слово "the". Однако если вы внесли значительные изменения в ПО, то получите авторские права на это изменение. Исключением может быть ситуация, когда, например, владельцы авторских прав на оригинал лицензируют изменения в ПО так, что владение авторскими правами на все изменения возвращается к ним.

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.

2.3.5. Лицензия Artistic License

Исходный код языка Perl распространяется под действием лицензии, позволяющей соблюдать условия или GPL, или альтернативной лицензии с причудливым названием Artistic License (Творческая лицензия). Основной целью этой лицензии является сохранение прав на неограниченное открытое распространение и предотвращение продажи пользователями усовершенствованных патентованных изменений, выдающих себя за официальные версии. Другие авторы ПО приняли соглашение Perl, позволяющее пользователям следовать условиям либо GPL, либо Artistic License; к некоторым применяются условия лишь Artistic License.

2.3.6. Несовместимости лицензий

Различные лицензионные условия свободного ПО допускают различные типы коммерческого использования, изменения и распространения. Чаще всего желательно повторно использовать существующий код в ваших собственных проектах. До известной степени это неизбежно — почти каждая написанная вами программа будет связана с библиотекой С, так что знания лицензионных условий библиотеки С будут необходимы так же, как и знания условий других библиотек, с которыми вы компонуете свою программу. Также вы можете изъявить желание включить фрагменты исходного кода других программ в свои собственные программы.

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

Если вы работаете с кодом, к которому применена лицензия GPL или LGPL, вы не сможете включить его в код, к которому применены условия лицензии стиля раннего BSD, поскольку GPL и LGPL запрещают "дополнительные ограничения", а старая лицензия BSD содержит дополнительные ограничения (не учитывающие ограничения GPL или LGPL) касательно рекламы и поддержки. По причине этого конфликта к некоторым элементам ПО применены альтернативные условия — условия и GPL, и лицензии раннего стиля BSD; у вас есть право выбора, каких лицензионных условий придерживаться.

Если код, к которому применены условия GPL или LGPL, включен в работу, производную от лицензии стиля BSD/MIT/X, ко всей производной работе (для всех практических целей) должны быть применены условия GPL либо LGPL соответственно.

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

Глава 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 — man 7 man.

Во время просмотра оперативных страниц руководства помните, что многие системные вызовы и библиотечные функции имеют одинаковые имена. В большинстве случаев вам требуются сведения о библиотечных функциях, с которыми вы будете осуществлять компоновку, а не о системных вызовах, к которым периодически обращаются эти библиотечные функции. Для доступа к описанию библиотечных функций применяйте man 3 функция, поскольку имена некоторых библиотечных функций совпадают с именами системных вызовов из раздела 2.

Также обратите особое внимание на то, что оперативные страницы руководства библиотеки поддерживаются отдельно от самой библиотеки С. Поскольку библиотека С обычно не меняет своего поведения, это не является проблемой. Все дистрибутивы Linux теперь используют библиотеку GNU С, которая рассматривается в главе 6. К библиотеке GNU С прилагается полная документация. Эта информация доступна в форме Texinfo.

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) и примеры. У каждого пакета имеется свой собственный каталог, носящий имя этого пакета и номер его версии.

Часть II Инструментальные средства и среда разработки

Глава 4 Инструментальные средства разработки

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

Дистрибутивы Linux включают в себя множество серьезных и проверенных средств разработки; большинство из этих средств на протяжении нескольких лет входили в системы разработки под Unix. Средства разработки Linux не отличаются ненужными излишествами и броскостью; большинство из них представляют собой инструменты командной строки без графического интерфейса пользователя. За все годы их применения эти средства зарекомендовали себя с самой лучшей стороны, и их изучение лишним не будет.

Если вы уже знакомы с Emacs, vi, make, gdb, strace и ltrace, в этой главе ничего нового вы для себя не найдете. Тем не менее, в оставшейся части книги предполагаются хорошие знания какого-нибудь текстового редактора. Практически весь свободный исходный код Unix и Linux собирается при помощи make, a gdb — один из самых распространенных отладчиков, доступных для Linux и Unix. Утилита strace (или подобная утилита под названием trace либо truss) доступна в большинстве систем Unix; утилита ltrace была изначально написана для Linux и в большинстве систем недоступна (на момент написания книги).

Однако не стоит думать, что для Linux нет графических средств разработки; на самом деле, все как раз наоборот. Этих средств огромное количество.

На момент написания этой книги привлекали внимание две интегрированных среды разработки (Integrated Development Environment — IDE), которые могут входить в используемый вами дистрибутив: KDevelop (http://kdevelop.org/), часть среды рабочего стола KDE, и Eclipse (http://eclipse.org/), межплатформенная среда, основанная на Java, которая первоначально, была разработана IBM, а теперь поддерживается крупным консорциумом. Однако в этой книге мы не будем останавливаться на рассмотрении упомянутых сред, поскольку они сопровождаются детальной документацией.

Даже несмотря на то, что для работы в Linux доступны многочисленные IDE, они пользуются не такой популярностью, как на других платформах. Даже если среда IDE применяется, все же более практичным считается написание программного обеспечения с открытым исходным кодом без ее задействования. Все это делается для того, чтобы другие программисты, которые захотят сделать свой вклад в ваш проект, не были стеснены вашим выбором IDE. Среда KDevelop поможет собрать проект, который будет использовать стандартные инструменты Automake, Autoconf и Libtool, используемые в многочисленных проектах с открытым исходным кодом.

Сами по себе стандартные средства Automake, Autoconf и Libtool играют важную роль в процессе разработки. Они были созданы для помощи в построений приложений таким образом, чтоб эти приложения могли быть почти автоматически перенесены в другие операционные системы. Ввиду того, что эти средства сложны, в настоящей книге мы рассматривать их не будем. Кроме того, эти средства регулярно изменяются; электронные версии GNU Autoconf, Automake и Libtool [41] доступны по адресу http://sources.redhat.com/autobook/.

4.1. Редакторы

Разработчики Unix традиционно придерживались строгих и разнотипных предпочтений особенно в выборе редакторов.

Доступно множество редакторов, которые легко изучить самостоятельно; наиболее распространенными можно считать vi и Emacs. Оба редактора являются мощными представителями своего типа, чего не скажешь на первый взгляд. У обоих редакторов сравнительно крутая кривая обучения, и они радикально отличаются друг от друга. Emacs является достаточно крупным; он сам себе операционная среда, vi не занимает много места и разработан специально для внедрения в среду Unix. Было написано множество клонов и альтернативных версий каждого редактора, и у самих версий также имеются свои клоны.

В этой книге мы не будем углубляться в изучение vi и Emacs, поскольку материал занял бы слишком много места. В [32] каждому редактору посвящены отдельные главы, кроме того, рекомендуем обратиться к [5] и [17]. В нашей книге мы только сравним Emacs и vi и расскажем, как получить оперативную справку по каждому из них.

Emacs включает исчерпывающий набор руководств, в которых объясняется не только использование Emacs как редактора, но и показывается, как применять Emacs для чтения и отправки электронной почты и новостей в Usenet, для игр (игра гомоку очень даже неплоха) и для ввода команд оболочки. В Emacs, написав полное имя внутренней команды, всегда можно ее выполнить, даже если она не привязана к клавишам.

В отличие от Emacs, документация по vi менее развернутая и менее известна. vi является только редактором, и многие важные команды можно выполнить путем нажатия одной клавиши. Здесь можно переключаться между режимом, в котором при нажатии стандартных букв алфавита они помещаются в текст, и режимом, в котором эти буквы являются командами. Например, можно использовать клавиши h, j, k и l в качестве клавиш управления курсором для навигации по документу.

Оба редактора позволяют создавать макросы для упрощения работы, но их макроязыки очень сильно отличаются. Emacs включает в себя целый язык программирования под названием elisp (Emacs Lisp), который очень тесно связан с языком программирования Common Lisp. В первоначальном варианте vi встроен более спартанский язык, ориентированный на стек. Большинство пользователей просто связывают с клавишами простые однострочные команды vi, но эти команды зачастую запускают программы за пределами vi, чтобы управлять данными внутри vi. По Emacs Lisp написано огромное руководство, включающее пособие по использованию; по языку, встроенному в vi, документация сравнительно скупа.

Некоторые редакторы позволяют смешивать и совмещать функциональности. Так, существуют редакторы, в которых можно использовать Emacs в режиме vi (viper), позволяющем использование стандартных команд vi; в другом клоне vi под названием vile ("vi like Emacs") можно использовать vi в режиме Emacs.

4.1.1. Emacs

Emacs встречается в нескольких вариациях. Первоначальный редактор Emacs был написан Ричардом Столлманом (Richard Stallman), одним из лидеров Фонда свободного ПО (Free Software Foundation — FSF). В течение многих лет его GNU Emacs был самым популярным редактором. С недавних пор популярностью начал пользоваться другой вариант GNU Emacs — XEmacs, в котором больше места уделяется поддержке графического интерфейса. XEmacs начал свою жизнь в качестве Lucid Emacs, набора расширений GNU Emacs, разработанного теперь уже распавшейся компанией Lucid Technologies. В намерения этой компании входило официально включить XEmacs в GNU Emacs. Но из-за технических различий команды не смогли слить свои коды. Несмотря ни на что, эти два редактора отлично совмещаются, а программисты обоих команд заимствуют коды друг у друга. Ввиду того, что обе эти версии очень похожи, в дальнейшем мы будем ссылаться на них как на Emacs.

Лучший способ для удобной работы с редактором Emacs — изучить пособие по работе с ним. Запустите emacs и наберите ^ht. Наберите ^x^c для выхода из Emacs. С помощью обучающей программы можно узнать, где получить дополнительную информацию по Emacs. Здесь вы не узнаете, как получить руководство по Emacs, распространяемое вместе с самим редактором. Для вызова этого руководства наберите ^hi.

Несмотря на то что пользовательский интерфейс Emacs не такой красочный, как некоторые графические среды IDE, в этом редакторе есть множество мощных средств, которые могут понадобиться многим программистам. Например, при использовании Emacs для редактирования кода С. Emacs распознает тип файла и переходит в режим редактирования С, в котором распознается синтаксис С, что может помочь при поиске опечаток. Если вы запускаете компилятор из Emacs, редактор распознает сообщения об ошибках и предупреждениях компилятора, и позволяет перейти на строку с ошибкой при помощи одной команды, даже если для этого придется открыть новый файл. В Emacs также имеется режим отладки: отладчик находится в одном окне и проходит по коду, который вы отлаживаете в другом окне.

4.1.2. vi

Если вы быстро набираете текст и хотите, чтоб ваши пальцы находились в правильном положении[3], vi вам наверняка понравится, поскольку его набор команд был разработан таким образом, чтобы движений пальцев печатающего было как можно меньше. Этот редактор также ориентирован на пользователей Unix. Если вы знакомы с sed или awk либо другими программами Unix, использующими стандартные регулярные выражения с ^ для перехода к началу строки и $ для перехода к ее концу, работа с vi покажется вам простой и естественной.

К сожалению, освоение vi может оказаться более сложным, нежели Emacs. Дело в том, что хоть пособия по vi подобны учебникам по Emacs, ни в одной версии vi нет стандартного способа запуска учебного пособия. Тем не менее, многие версии, включая версию, поставляемую с обычными дистрибутивами Linux, поддерживают команду :help.

В наиболее общей версии vi, vim ("Vi IMproved"), есть множество интегрированных средств из набора разработки Emacs, включая выделение синтаксиса, автоматическое расположение текста, язык написания сценариев и разбор ошибок компилятора.

4.2. make

Основой программирования под Unix является make — средство, которое существенно упрощает описание компиляции программ. Даже притом, что небольшим программам порой достаточно одной команды для компиляции их исходного кода в исполняемый файл, все же намного легче написать make, чем строку вроде gcc -02 -ggdb -DSOME DEFINE -о foo foo.c. Более того, если имеется множество файлов для компиляции, а код был изменен лишь в некоторых из них, make создаст новые объектные файлы только для тех файлов, на которые повлияли изменения. Чтобы make совершила это "чудо", потребуется описать все файлы в make-файле (Makefile), пример которого показан ниже.

 1: # Makefile

 2:

 3: OBJS = foo.о bar.о baz.o

 4: LDLIBS = -L/usr/local/lib/ -lbar

 5:

 6: foo: $(OBJS)

 7:       gcc -o foo $ (OBJS) $ (LDLIBS)

 8:

 9: install: foo

10:       install -m 644 foo /usr/bin

11: .PHONY: install

• Строка 1 — это комментарий; make следует обычной традиции Unix определения комментариев с помощью символа #.

• В строке 3 определяется переменная по имени OBJS как foo.о bar.о baz.о.

• В строке 4 определяется другая переменная — LDLIBS.

• В строке 6 начинается определение правила, которое указывает на то, что файл foo зависит от (в этом случае, собран из) файлов, имена которых содержатся в переменной OBJS. foo называется целевым объектом, а $(OBJS) — списком зависимостей. Обратите внимание на синтаксис расширения переменной: имя переменной помещается в $(...).

Строка 7 — это командная строка, указывающая на то, как построить целевой объект из списка зависимостей. Командных строк может быть много, и первым символом в командной строке должна быть табуляция.

• Строка 9 — довольно интересный целевой объект. Фактически тут не предпринимается попытка создать файл по имени install; вместо этого (как видно в строке 10) foo инсталлируется в /usr/bin с помощью стандартной программы install. Эта строка вызывает неоднозначность в make: что, если файл install уже существует и является более новым, нежели foo? В этом случае запуск команды make install приведет к выдаче сообщения 'install' is up to date (install является новее) и завершению работы.

• Строка 11 указывает make на то, что install не является файлом, и что необходимо игнорировать любой файл по имени install при вычислении зависимости install. Таким образом, если зависимость install была вызвана (как это сделать мы рассмотрим далее), команда в строке 10 всегда будет выполняться. .PHONY — это директива, которая изменяет операцию make; в этом случае она указывает make на то, что целевой объект install не является именем файла. Целевые объекты .PHONY часто используются для совершения действий вроде инсталляции или создания одиночного имени целевого объекта, которое основывается на нескольких других уже существующих целевых объектов, например:

all: foo bar baz

.PHONY: all

К сожалению, .PHONY не поддерживается некоторыми версиями make. Менее очевидный, не такой эффективный, но более переносимый способ для этого показан ниже.

all: foo bar baz FORCE

FORCE:

Это срабатывает только тогда, когда нет файла по имени FORCE.

Элементы в списках зависимостей могут быть именами файлов, но, поскольку это касается make, они являются целевыми объектами. Элемент foo в списке зависимости install — это целевой объект. При попытке make вычислить зависимость install становится ясно, что в первую очередь необходимо вычислить зависимость foo. А для этого make потребуется вычислить зависимости foo.о, bar.о и baz.о.

Обратите внимание на отсутствие строк, явно указывающих make, как строить foo.о, bar.о или baz.о. Вы не будете определять эти строки непосредственно в редакторе. make обеспечивает предполагаемые зависимости, которые записывать не нужно. Если в файле есть зависимость, заканчивающаяся на , и есть файл с таким же именем, но он заканчивается на , make предполагает, что этот объектный файл зависит от исходного файла. Встроенные суффиксные правила, которые поддерживаются make, позволяют значительно упростить многие make-файлы и, если встроенное правило не соответствует требованиям, можно создать свои собственные суффиксные правила (речь об этом пойдет ниже).

По умолчанию make прекращает работу, как только любая из заданных команд дает сбой (возвращает ошибку). Существуют два способа избежать этого.

Аргумент -k заставляет make создавать максимально возможное количество файлов без останова, даже если какая-то команда вернула ошибку. Это полезно, например, при переносе программы; можно построить столько объектных файлов, сколько нужно, а потом перенести файлы, которые вызвали ошибку, без нежелательных перерывов в работе.

Если известно, что какая-то одна команда будет всегда возвращать ошибку, но вы хотите проигнорировать ее, можно воспользоваться "магией" командной оболочки. Команда /bin/false всегда возвращает ошибку, таким образом, /bin/false всегда будет вызывать прекращение работы, если только не указана опция -k. С другой стороны, конструкция любая_команда || /bin/true никогда не вызовет прекращение работы; даже если любая_команда возвращает false, оболочка затем запускает /bin/true, которая вернет успешный код завершения.

make интерпретирует нераспознанные аргументы командной строки, которые не начинаются с минуса (-), как целевые объекты для сборки. Таким образом, make install приводит к сборке целевого объекта install. Если целевой объект foo устарел, make сначала соберет зависимости foo, а затем инсталлирует его. Если требуется собрать целевой объект, начинающийся со знака минус, этот знак перед именем целевого объекта должен быть продублирован (--).

4.2.1 Сложные командные строки

Каждая командная строка выполняется в своей собственной подоболочке, таким образом, команды cd в командной строке влияют только на строку, в которой они записаны. Любую строку в make-файле можно расширить на множество строк, указывая в конце каждой обратный слэш. Ниже показан пример того, как иногда могут выглядеть командные строки.

 1: cd первый_ каталог; \

 2:  сделать что-то с файлом $ (FOO) ; \

 3:  сделать еще что-то

 4: cd второй_каталог; \

 5:  if [ -f некоторый_файл ] ; then\

 6:   сделать что-то другое; \

 7:  done; \

 8:  for i in * ; do \

 9:   echo $$i >> некоторый__файл ; \

10:  done

make находит в этом фрагменте кода только две строки. Первая командная строка начинается в строке 1 и продолжается до строки 3, а вторая начинается в строке 4 и заканчивается в строке 10. Здесь следует отметить несколько моментов.

• второй_каталог является относительным не к каталогу первый_каталог, а к каталогу, в котором запущен make, поскольку эти команды выполняются в разных подоболочках.

• Строки, образующие каждую командную строку, передаются оболочке в виде одной строки. Таким образом, все символы ;, которые нужны оболочке, должны присутствовать, включая даже те, которые обычно в сценариях оболочки опускаются, поскольку их наличие подразумевается благодаря символам новой строки. Более детально о программировании программной оболочки рассказывается в [22].

• Если требуется разыменовывать переменную make, это делается обычным образом (то есть $(переменная)), но если нужно разыменовывать переменную оболочки, необходимо применять двойной символ $: $$i.

4.2.2. Переменные

Часто бывает необходимо определить только один компонент переменной за раз. Можно написать, например, такой код:

OBJS = foo.о

OBJS = $(OBJS) bar.о

OBJS = $(OBJS) baz.о

Ожидается, что здесь OBJS будет определен как foo.о bar.о baz.о, но в действительности он определен как $(OBJS) baz.о, поскольку make не разворачивает переменные до момента их использования[4]. При ссылке в правиле на OBJS make войдет в бесконечный цикл[5]. Во избежание этого во многих make-файлах разделы организуются следующим образом:

OBJS1 = foo.о

OBJS2 = bar.о

OBJS3 = baz.о

OBJS = $(OBJS1) $(OBJS2) $(OBJS3)

Объявления переменных вроде предыдущего встречаются, когда объявление одной переменной оказывается слишком длинным и потому не удобным.

Развертывание переменной вызывает типичный вопрос, который программист в Linux должен решить. Инструменты GNU, распространяемые с Linux, обычно более функциональны, чем версии инструментов, включенных в другие системы, и GNU make — не исключение. Авторы GNU make предусмотрели альтернативный способ присваивания переменных, но не все версии make понимают эти альтернативные формы. К счастью, GNU make можно собрать для любой системы, в которую можно перенести исходный код, написанных под Linux. Существует форма простого присваивания переменных, которая показана ниже.

OBJS := foo.о

OBJS := $(OBJS) bar.о

OBJS := $(OBJS) baz.о

Операция := заставляет GNU make вычислить выражение переменной при присваивании, а не ждать вычисления выражения при его использовании в правиле. В результате выполнения этого кода OBJS действительно получит foo.о bar.о baz.о.

Простое присваивание переменной используется очень часто, но в GNU make есть еще и другой синтаксис присваивания, который позаимствован из языка С:

OBJS := foo.о

OBJS += bar.о

OBJS += baz.о

4.2.3. Суффиксные правила

Суффиксные правила — это другая область, в которой вам нужно решить, писать ли стандартные make-файлы или использовать расширения GNU. Стандартные суффиксные правила намного ограниченнее, нежели шаблонные правила GNU, но во многих ситуациях стандартные суффиксные правила могут оказаться полезными. К тому же шаблонные правила поддерживаются не во всех версиях make. Суффиксные правила выглядят следующим образом:

.c.o:

$(CC) -с $ (CFLAGS) $ (CPPFLAGS) -о $<

.SUFFIXES: .с .о

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

Это суффиксное правило демонстрирует другую возможность make — автоматические переменные. Понятно, что нужно найти способ подставить зависимость и целевой объект в командную строку. Автоматическая переменная $@ выступает в качестве целевого объекта, $< выступает в качестве первой зависимости, а $^ представляет все зависимости.

Существуют и другие автоматические переменные, которые рассматриваются в руководстве по make. Все автоматические переменные можно использовать в обыкновенных правилах, а также в суффиксных и шаблонных правилах.

Последняя строка примера представляет еще одну директиву. .SUFFIXES указывает make на то, что и являются суффиксами, которые должен использовать make для нахождения способа превратить существующие исходные файлы в необходимые целевые объекты.

Шаблонные правила более мощные и, следовательно, немного сложнее, чем суффиксные правила. Ниже приведен пример эквивалентного шаблонного правила для показанного выше суффиксного правила.

% .о: % .с

$(CC) -с $(CFLAGS) $(CPPFLAGS) -о $<

Дополнительные сведения о make можно получить в [26]. GNU make также включает замечательное и удобное в обращении руководство в формате Texinfo, которое можно почитать на сайте FSF, распечатать или заказать у них в форме книги.

Большинство крупных проектов с открытым исходным кодом используют инструменты Automake, Autoconf и Libtool. Эти инструменты представляют собой коллекцию знаний об особенностях различных систем и стандартах сообщества, которая может помочь в построении проектов. Таким образом, потребуется писать лишь немного кода, специфического для проекта. Например, Automake пишет целевые объекты install и uninstall, Autoconf автоматически определяет возможности системы и настраивает программное обеспечение для его соответствия системе, a Libtool отслеживает различия в управлении совместно используемыми библиотеками на разных системах.

По этим трем инструментам написана целая книга — [41]; здесь мы даем лишь основу, которая понадобится для работы с GNU Autoconf, Automake и Libtool.

4.3. Отладчик GNU

gdb — это отладчик, рекомендуемый Free Software Foundation, gdb представляет собой хороший отладчик командной строки, на котором строятся некоторые инструменты, включая режим gdb в Emacs, графический отладчик Data Display Debugger (http://www.gnu.org/software/ddd/) и встроенные отладчики в некоторых графических интерфейсах IDE. В этом разделе рассматривается только gdb.

Запустите gdb с помощью команды gdb имя_программы. gdb не будет просматривать значение PATH в поисках исполняемого файла. Отладчик загрузит символьную информацию для исполняемого файла и запросит дальнейших действий.

Существует три способа проверить процесс с помощью gdb.

• Используя команду run для обычного выполнения программы.

• Используя команду attach для начала проверки уже запущенного процесса. При подключении к процессу, последний останавливается.

• Исследуя существующий файл ядра для определения состояния процесса при его завершении. Для исследования файла ядра gdb потребуется запустить с помощью команды имя_программы файл_ядра.

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

gdb не требует написания полного имени команды; указание r достаточно для run, n — для next, s — для step. Более того, для повторения наиболее часто употребляемой команды, нужно просто нажать клавишу <Enter>. Таким образом, пошаговое выполнение программы становится проще.

Ниже предложен небольшой набор полезных команд gdb; gdb включает полное онлайновое руководство в формате GNU info (запустите info gdb), в котором детально объясняются все опции gdb. В [19] содержится неплохое подробное руководство по работе с gdb. gdb также поддерживает оперативную справку, ссылки на которую можно найти внутри gdb; доступ к справочным файлам можно получить, введя команду help. Можно также получить справку по каждой определенной команде, набрав help команда или help тема.

Подобно командам оболочки, команды gdb могут принимать аргументы. "Вызвать help с аргументом команда" означает то же самое, что и "набрать help команда".

Некоторые команды gdb также принимают идентификаторы формата для спецификации вывода значений. Идентификаторы формата располагаются за именем команды и отделяются от него косой чертой. После выбора формата необходимость использовать его каждый раз при повторе команды отпадает; gdb запоминает выбранный формат и использует его по умолчанию.

Идентификаторы формата отделены от команд символом / и состоят из трех элементов: цифра, буква формата и буква, отражающая размер. Цифра и буква размера не обязательны; по умолчанию в качестве цифры устанавливается 1, а размер получает подходящее значение по умолчанию, основанное на букве формата.

Буквы формата следующие: о для обозначения восьмеричного числа, x для шестнадцатеричного числа, d для десятичного числа, и для беззнакового десятичного числа, t для двоичных данных, f для числа с плавающей запятой, а для адреса, i для инструкций, с для символа, s для строки.

Символы, отображающие размер, таковы: b — байт, h — полуслово (2 байта), w — слово (4 байта), g — слово-гигант (8 байт).

attach, at

Подключает отладчик к уже запущенному процессу. Единственным аргументом является идентификатор процесса (pid), к которому осуществляется подключение. Процессы, с которыми установлено подключение, останавливаются, прерывая любые ожидающие или текущие системные вызовы, которые разрешено прерывать. См. detach.

backtrace, bt, where, w

Выводит трассировку стека.

break, b

Устанавливает точку прерывания. Можно указать имя функции, номер строки текущего файла (файл, содержащий выполняемый в данный момент код), пару имя_файла:номер_строки или даже произвольный адрес с помощью *адрес.gdb назначает и выводит уникальный номер для каждой точки прерывания. См. condition, clear и delete.

clear

Удаляет точку прерывания. Принимает такой же аргумент, как break. См. delete.

condition

Изменяет точку прерывания, определенную номером (см. break), для прерывания, только если выражение истинно. Допускаются произвольные выражения.

(gdb) b664

Breakpoint 3 at 0х804а5с0: file ladsh4.c, line664.

(gdb) condition 3 status==0

delete

Удаляет точку прерывания, определенную номером.

detach

Отключается от текущего подключенного процесса.

display

Отображает значение выражения каждый раз при остановке выполнения. Принимает такие же аргументы (включая модификаторы формата), как print. Выводит номер отображения, которое впоследствии может использоваться для отмены отображения. См. undisplay.

Help

Вызывает справку. При вызове без аргумента предоставляет краткое описание доступной справочной информации. При вызове с другой командой в качестве аргумента выводит справку по этой команде. Доступны перекрестные ссылки.

jump

Переходит на произвольный адрес и продолжает выполнение процесса с этой точки. Адрес — единственный аргумент; его можно определить в форме номера строки или адреса, указанного как *адрес.

list, l

Выданная без аргументов list сначала выводит 10 строк, расположенных возле текущего адреса. Последующие вызовы list выводят последующие 10 строк. При использовании аргумента - выводит предыдущие 10 строк. При указании номера строки выводит 10 строк, окружающих эту строку. При указании пары имя_файла:номер_строки выводит 10 строк, окружающих заданную. При указании имени функции выводит 10 строк возле начала функции. При указании адреса в виде *адрес выводит 10 строк, окружающих код, находящийся по этому адресу. При указании двух строк, разграниченных запятыми, выводит все строки между заданными.

next, n

Переходит на следующую строку исходного кода в текущей функции, без захода внутрь функций. См. step.

nexti

Переходит на следующую инструкцию машинного языка без захода внутрь функций. См. stepi.

print, p

Выводит значение выражения в понятной форме. Если есть переменная char* с, команда print с выведет адрес строки, a print *с выведет саму строку. Для структур выводятся их члены. Можно использовать приведения типов, которые gdb будет учитывать. Если код скомпилирован с опцией -ggdb, в выражениях станут доступны перечислимые значения и определения препроцессора. См. display. Команда print принимает идентификаторы формата, несмотря на то, что при указании и преобразовании типов идентификаторы формата зачастую не нужны. См. x.

run, r

Запускает текущую программу с начала. Аргументы команды run передаются в командную строку для запуска программы. В gdb, подобно оболочке, можно универсализировать имена файлов с помощью * и [], а также осуществлять переадресацию посредством <, > и >>, но нельзя создавать каналы или внутренние документы. Без аргументов run использует аргументы, которые были определены в самой последней команде run или set args. Для запуска без аргументов после их задействования используется команда set args без дополнительных аргументов.

set

gdb позволяет менять значения переменных, например:

(gdb) set а = argv[5]

Также каждый раз при выводе выражения с помощью print создается сокращенная переменная вроде $1, на которую впоследствии можно ссылаться. Таким образом, если ранее был выведен argv[5] и gdb указал на то, что результат сохранен в $6, можно переписать предыдущее присваивание так:

(gdb) set а = $6

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

step, s

Выполняет инструкции программы до достижения новой строки исходного кода. См. next.

stepi

Выполняет в точности одну инструкцию машинного языка; с заходом внутрь функций. См. nexti.

undisplay

Если выдана без аргумента, отменяет все отображения. В противном случае отменяет отображения указанные номерами. См. display.

whatis

Выводит тип данных выражения, переданного в качестве аргумента команды.

where, w

См. backtrace.

x

Команда x подобна print с тем исключением, что она явно ограничивается выводом содержимого по указанному адресу в произвольном формате. Если идентификатор формата не используется, gdb будет применять самый последний идентификатор из указанных.

4.4. Действия при трассировке программы

Существуют две программы, помогающие трассировать исполняемые файлы. Ни одной из этих программ исходный код не нужен; фактически, они не могут использовать исходные коды. Обе программы выводят в символьной текстовой форме журнал действий, выполняемых приложением.

Первая, strace, выводит запись о каждом системном вызове программы. Вторая, ltrace, выводит запись о каждой функции библиотеки, которую вызывает программа (и по выбору может также трассировать системные вызовы). Эти инструменты могут оказаться полезными при определении неполадок в случаях явного сбоя.

Например, предположим, что имеется системный демон, функционирующий уже некоторое время, который начал выдавать ошибки сегментации. Скорее всего, это вызвано изменением в некоторых файлах данных, но неизвестно каких именно. Первым шагом должен быть запуск системного демона под управлением strace. Нужно просмотреть несколько последних файлов, которые демон открывал перед тем, как произошла ошибка сегментации, и найти в этих файлах возможные причины. Либо предположим, что другой демон внезапно начал занимать много процессорного времени; в этом случае можно запустить его сначала под strace, а затем и под ltrace, если strace четко не покажет, что конкретно делал демон. В результате можно определить входные параметры или условия, которые привели к потреблению такого количества процессорного времени.

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

Обе утилиты поддерживают похожий набор опций.

или --demangle Только для ltrace. Декодирует (или расшифровывает) имена библиотечных символов в читабельные имена. В результате убираются начальные символы подчеркивания (многие функции glibc имеют внутренние имена с начальными символами подчеркивания) и функции библиотеки С++ становятся более читабельными (С++ шифрует информацию о типе в символьные имена).
Только для strace. Указывает подмножество вызовов, которые нужно вывести. Существует множество возможных спецификаций, описанных на man-странице strace; самой распространенной спецификацией является -е trace=file, которая трассирует только системные вызовы, связанные с файловым вводом-выводом и обработкой файлов.
-f Пытается «следовать вызову fork()», по возможности трассируя дочерние процессы. Обратите внимание, что дочерний процесс может некоторое время работать без трассировки до тех пор, пока strace или ltrace сможет подключиться к нему и трассировать его действия.
имя_файла Вместо вывода на стандартное устройство вывода выводит в файл имя файла.
pid Вместо запуска нового экземпляра программы подключается к процессу с идентификатором pid.
-S Только для ltrace. Отслеживает системные и библиотечные вызовы.
-v Только для strace. Не сокращает большие структуры в системных вызовах вроде семейства вызовов stat(), termios и так далее.

На man-страницах утилит можно найти описание этих и других опций, здесь не упомянутых.

Глава 5 Опции и расширения gcc

Для правильного использования gcc, стандартного компилятора С для Linux, необходимо изучить опции командной строки. Кроме того, gcc расширяет язык С. Даже если вы намерены писать исходный код, придерживаясь ANSI-стандарта этого языка, некоторые расширения gcc просто необходимо знать для понимания заголовочных файлов Linux.

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

Стремление соблюсти ISO-стандарт С весьма полезно, но в связи с тем, что С является низкоуровневым языком, встречаются ситуации, когда стандартные средства недостаточно выразительны. Существуют две области, в которых широко применяются расширения gcc: взаимодействие с ассемблерным кодом (эти вопросы раскрываются по адресу http://www.delorie.com/djgpp/doc/brennan/) и сборка совместно используемых библиотек (см. главу 8). Поскольку заголовочные файлы являются частью совместно используемых библиотек, некоторые расширения проявляются также в системных заголовочных файлах.

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

5.1. Опции gcc

gcc принимает множество командных опций. К счастью, набор опций, о которых действительно нужно иметь представление, не так велик, и в этой главе мы его рассмотрим.

Большинство опций совпадают или подобны опциям других компиляторов, gcc включает в себя огромную документацию по своим опциям, доступную через info gcc (man gcc также выдает эту информацию, однако man-страницы не обновляются настолько часто, как документация в формате Texinfo).

-о имя_файла Указывает имя выходного файла. Обычно в этом нет необходимости, если осуществляется компиляция в объектный файл, то есть по умолчанию происходит подстановка имя_файла на имя_файла. Однако если вы создаете исполняемый файл, по умолчанию (по историческим причинам) он создается под именем а.out. Это также полезно в случае, когда требуется поместить выходной файл в другой каталог.
Компилирует без компоновки исходный файл, указанный для командной строки. В результате для каждого исходного файла создается объектный файл. При использовании make компилятор gcc обычно вызывается для каждого объектного файла; таким образом, в случае возникновения ошибки легче обнаружить, какой файл не смог скомпилироваться. Однако если вы вручную набираете команды, часто в одном вызове gcc указывается множество файлов. В случае, если при задании множества файлов в командной строке может возникнуть неоднозначность, лучше указать только один файл. Например, вместо gcc -с -о а.о а.с b.с имеет смысл применить gcc -с -o a.o b.c.
-Dfoo Определяет препроцессорные макросы в командной строке. Возможно, потребуется отменить символы, трактуемые оболочкой как специальные. Например, при определении строки следует избегать употребления ограничивающих строки символов ". Вот два наиболее употребляемых способа: '-Dfoo="bar"' и -Dfoo=\"bar\". Первый способ работает намного лучше, если в строке присутствуют пробелы, поскольку оболочка рассматривает пробелы особым образом.
-Iкаталог Добавляет каталог в список каталогов, в которых производится поиск включаемых файлов.
-Lкаталог Добавляет каталог в список каталогов, в которых производится поиск библиотек, gcc будет отдавать предпочтение совместно используемым библиотекам, а не статическим, если только не задано обратное.
-lfoo Выполняет компоновку с библиотекой libfoo. Если не указано обратное, gcc отдает предпочтение компоновке с совместно используемыми библиотеками (libfoo.so), а не статическими (libfoo.a). Компоновщик производит поиск функций во всех перечисленных библиотеках в том порядке, в котором они перечислены. Поиск завершается тогда, когда будут найдены все искомые функции.
-static Выполняет компоновку с только статическими библиотеками. См. главу 8.
-g, -ggdb Включает отладочную информацию. Опция -g заставляет gcc включить стандартную отладочную информацию. Опция -ggdb указывает на необходимость включения огромного количества информации, которую в силах понять лишь отладчик gdb.
Если дисковое пространство ограничено или вы хотите пожертвовать некоторой функциональностью ради скорости компоновки, следует использовать -g. В этом случае, возможно, придется воспользоваться другим отладчиком, а не gdb. Для максимально полной отладки необходимо указывать -ggdb. В этом случае gcc подготовит максимально подробную информацию для gdb. Следует отметить, что в отличие от большинства компиляторов, gcc помещает некоторую отладочную информацию в оптимизированный код. Однако трассировка в отладчике оптимизированного кода может быть сопряжена со сложностями, так как во время выполнения могут происходить прыжки и пропуски фрагментов кода, которые, как ожидалось, должны были выполняться. Тем не менее, при этом можно получить хорошее представление о том, как оптимизирующие компиляторы изменяют способ выполнения кода.
-O, -On Заставляет gcc оптимизировать код. По умолчанию, gcc выполняет небольшой объем оптимизации; при указании числа (n) осуществляется оптимизация на определенном уровне. Наиболее распространенный уровень оптимизации — 2; в настоящее время в стандартной версии gcc самым высоким уровнем оптимизации является 3. Мы рекомендуем использовать -O2 или -O3; -O3 может увеличить размер приложения, так что если это имеет значение, попробуйте оба варианта. Если для вашего приложения важна память и дисковое пространство, можно также использовать опцию -Os, которая делает размер кода минимальным за счет увеличения времени выполнения. gcc включает встроенные функции только тогда, когда применяется хотя бы минимальная оптимизация (-O).
-ansi Поддержка в программах на языке С всех стандартов ANSI (X3.159-1989) или их эквивалента ISO (ISO/IEC 9899:1990) (обычное называемого С89 или реже С90). Следует отметить, что это не обеспечивает полное соответствие стандарту ANSI/ISO.
Опция -ansi отключает расширения gcc, которые обычно конфликтуют со стандартами ANSI/ISO. (Вследствие того, что эти расширения поддерживаются многими другими компиляторами С, на практике это не является проблемой.) Это также определяет макрос __STRICT_ANSI__ (как описано далее в этой книге), который заголовочные файлы используют для поддержки среды, соответствующей ANSI/ISO.
-pedantic Выводит все предупреждения и сообщения об ошибках, требуемые для ANSI/ISO-стандарта языка С. Это не обеспечивает полное соответствие стандарту ANSI/ISO.
-Wall Включает генерацию всех предупреждений gcc, что обычно является полезным. Но таким образом не включаются опции, которые могут пригодиться в специфических случаях. Аналогичный уровень детализации будет установлен и для программы синтаксического контроля lint в отношении вашего исходного кода, gcc позволяет вручную включать и отключать каждое предупреждение компилятора. В руководстве по gcc подробно описаны все предупреждения.

5.2. Заголовочные файлы

Время от времени вы можете застать себя на том, что просматриваете заголовочные файлы Linux. Скорее всего, вы найдете рад конструкций, не совместимых со стандартом ANSI/ISO. Некоторые из них стоят того, чтобы в них разобраться. Все конструкции, рассматриваемые в этой книге, более подробно изложены в документации по gcc.

5.2.1. long long

Тип long long указывает на то, что блок памяти, по крайней мере, такой же большой, как long. На Intel i86 и других 32-разрядных платформах long занимает 32 бита, а long long — 64 бита. На 64-разрядных платформах указатели и long long занимают 64 бита, a long может занимать 32 или 64 бита в зависимости от платформы. Тип long long поддерживается в стандарте С99 (ISO/IEC 9899:1999) и является давним расширением С, которое обеспечивается gcc.

5.2.2. Встроенные функции

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

5.2.3. Альтернативные расширенные ключевые слова

В gcc у каждого расширенного ключевого слова (ключевые слова, не описанные стандартом ANSI/ISO) есть две версии: само ключевое слово и ключевое слово, окруженное с двух сторон двумя символами подчеркивания. Когда компилятор применяется в стандартном режиме (обычно тогда, когда задействована опция -ansi), обычные расширенные ключевые слова не распознаются. Так, например, ключевое слово attribute в заголовочном файле должно быть записано как __attribute__.

5.2.4. Атрибуты

Расширенное ключевое слово attribute используется для передачи gcc большего объема информации о функции, переменной или объявленном типе, чем это позволяет код С, соответствующий стандарту ANSI/ISO. Например, атрибут aligned дает указание gcc о том, как именно выравнивать переменную или тип; атрибут packed указывает на то, что заполнение использоваться не будет; noreturn определяет то, что возврат из функции никогда не произойдет, что позволяет gcc лучше оптимизироваться и избегать фиктивных предупреждений.

Атрибуты функции объявляются путем их добавления в объявление функции, например:

void die_die_die(int, char*) __attribute__ ((__noreturn__));

Объявление атрибута размещается между скобками и точкой с запятой и содержит ключевое слово attribute, за которым следуют атрибуты в двойных круглых скобках. Если атрибутов много, следует использовать список, разделенный запятыми.

int printm(char*, ...)

__attribute__((const,

 format(printf, 1, 2)));

В этом примере видно, что printm не рассматривает никаких значений, кроме указанных, и не имеет побочных эффектов, относящихся к генерации кода (const), printm указывает на то, что gcc должен проверять аргументы функции так же, как и аргументы printf(). Первый аргумент является форматирующей строкой, а второй — первым параметром замены (format).

Некоторые атрибуты будут рассматриваться по мере дальнейшего изложения материала (например, во время описания сборки совместно используемых библиотек в главе 8). Исчерпывающую информацию по атрибутам можно найти в документации gcc в формате Texinfo.

Глава 6 Библиотека GNU C

Библиотека GNU С (glibc) — это стандартная библиотека языка С, разработанная для Linux-систем. Существуют и другие библиотеки С, которые иногда используются в определенных целях (например, очень маленькое подмножество стандартных библиотек С применяется во встроенных системах и для начальной загрузки). Но во всех дистрибутивах Linux стандартной библиотекой языка С, предоставляющей значимый объем функциональности, является glibc. Именно эта библиотека и описывается в настоящей книге.

6.1. Выбор возможностей glibc

В glibc существует набор макросов для выбора возможностей. Эти макросы используются для выбора стандарта, которому будет подчиняться glibc. Иногда стандарты конфликтуют между собой, a glibc позволяет выбирать именно тот набор стандартов (формальный, де-юре, и неформальный, де-факто), которым нужно соответствовать полностью либо частично. Технически такие макросы называются макросами проверки возможностей.

Знание этих макросов необходимо, так как набор макросов, определенных по умолчанию, не обеспечивает полную функциональность glibc. Некоторые механизмы, описанные в этой книге, в выбранном по умолчанию наборе функций не доступны; далее мы опишем макросы, необходимые для включения каждого такого механизма.

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

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

Макросы определяются в системном заголовочном файле feature.h, который не должен включаться непосредственно. Взамен его включают все другие заголовочные файлы, которые зависят от содержимого feature.h.

Набор макросов по умолчанию содержит _SVID_SOURCE=1, _BSD_SOURCE=1, _POSIX_SOURCE=1 и _POSIX_C_SOURCE=199506L. Описание каждой из этих опций можно найти ниже, но все это, по сути, транслируется в поддержку возможностей стандарта 1995 POSIX (этот стандарт использовался до объединения стандартов POSIX и Single Unix), всех стандартных функций System V и всех функций BSD, которые не конфликтуют с функциями System V. Данного набора макросов достаточно для большинства программ.

При определении в gcc опции -ansi, как было описано ранее, автоматически определяется внутренний макрос __STRICT_ANSI__, который отключает все макросы, определенные по умолчанию.

За исключением __STRICT_ANSI__, который представляет собой специальный макрос (и должен настраиваться только компилятором в контексте опции командной строки -ansi), эти макросы имеют накопительный характер, то есть можно определять любые их комбинации. Точное определение изменений _BSD_SOURCE зависит от настройки других макросов (более детально об этом — ниже); все остальные макросы — исключительно накопительные.

Некоторые макросы определяются различными версиями POSIX или других стандартов, другие являются общими, а третьи могут использоваться только в glibc.

_POSIX_SOURCE Если указан этот макрос, становятся доступными все интерфейсы, определенные как часть оригинальной спецификации POSIX.1. Данный макрос был определен в первоначальном стандарте POSIX.1-1990.
_POSIX_C_SOURCE Этот макрос может заменять _POSIX_SOURCE. Если установлен в 1, то эквивалентен _POSIX_SOURCE. Если его значение больше либо равно 2, макрос включает интерфейсы С, соответствующие POSIX.2, и задействует регулярные выражения. Если значение больше либо равно 199309L, макрос включает в себя дополнительные интерфейсы С, соответствующие пересмотренному в 1993 году стандарту POSIX, в частности, включая функциональность реального времени. Если его значение больше либо равно 199506L (по умолчанию), макрос включает дополнительные интерфейсы С, соответствующие пересмотренному в 1995 году стандарту POSIX, в частности, включая потоки POSIX. Этот макрос был описан версией POSIX, выпущенной после 1990 года для разграничения поддержки различных версий стандартов POSIX (а теперь также и Single Unix). Во многих случаях полностью замещается _XOPEN_SOURCE.
_XOPEN_SOURCE Макрос _XOPEN_SOURCE определен XSI-частью стандарта Single Unix и описывает логическое надмножество интерфейсов, включенных с помощью _POSIX_C_SOURCE. Этот макрос также был определен XPG. Если макрос определен, указываются функциональные возможности из начального стандарта XPG4 (Unix95). Если макрос определен со значением 500, включаются функциональные возможности из стандарта XPG5 (Unix98, SuS версии 2). Если установлено значение 600, включаются функциональные возможности из начального стандарта IEEE Std 1003.1-2003 (комбинированный документ по POSIX и SuS).
_ISOC99_SOURCE Этот макрос проверки возможностей экспортирует интерфейсы, определенные в новых стандартах ISO/IEC С99.
_SVID_SOURCE При указании данного макроса для выбора возможностей становится доступным стандарт SVID (System V Interface Definition). Это не значит, что glibc обеспечивает полную реализацию стандарта SVID; она всего лишь открывает указанную функциональность SVID, существующую в glibc.
_BSD_SOURCE Функции BSD могут конфликтовать с другими функциями, и эти конфликты всегда разрешаются в пользу поведения, соответствующего стандарту System V, или, если определен или подразумевается любой макрос функций POSIX, X/Open или System V, единственным макросом, который включает поведение BSD является _ISOC99_SOURCE. (Точное определение этого макроса временами изменялось и может меняться в дальнейшем, поскольку он не регламентируется каким-либо стандартом.)
_GNU_SOURCE В случаях конфликта _GNU_SOURCE включает все, что возможно, отдавая предпочтение интерфейсам System V, а не BSD. Этот макрос также добавляет некоторые специальные для GNU и Linux интерфейсы, например, владение файлами.

Когда стандартного набора макросов недостаточно, обычно определяют макрос _GNU_SOURCE (включает все — самое простое решение), _XOPEN_SOURCE=600 (наиболее вероятно, что пригодится поднабор _GNU_SOURCE) или _ISOC99_SOURCE (использование функций наиболее позднего стандарта С, поднабор _XOPEN_SOURCE=600).

6.2. Интерфейсы POSIX

6.2.1. Обязательные типы POSIX

POSIX описывает некоторые определения типов в заголовочном файле <sys/types.h>, которые используются для многих аргументов и возвращаемых значений. Эти определения типов важны, потому что стандартные типы языка С могут быть разными на различных машинах, так как они нестрого определены в стандарте С. Из-за такого нестрогого определения язык С полезен на широком диапазоне оборудования — размер слов на 16-разрядных машинах отличается от такового на 64-разрядных машинах, а язык программирования низкого уровня не должен скрывать эту разницу — но для POSIX требуется большая гарантия. От заголовочного файла библиотеки С <sys/types.h> требуется определение набора соответствующих типов для каждой машины, которая поддерживает POSIX. Каждый из этих определений типов можно легко отличить от собственного типа С, поскольку он заканчивается на _t.

Ниже описано подмножество, используемое для интерфейсов.

dev_t Арифметический тип данных, содержащий старшие (major) и младшие (minor) числа, соответствующие специальным файлам устройств, обычно расположенным в подкаталоге /dev. В Linux dev_t можно манипулировать с помощью макросов major(), minor() и makedev(), которые определены в <sys/sysmacros.h>. Обычно dev_t используется только в системном программировании, описанном в главе 11.
uid_t, gid_t Целочисленные типы, содержащие уникальные идентификаторы, соответственно, пользователя и группы. Удостоверения идентификаторов пользователя и группы рассматриваются в главе 10.
pid_t Целочисленный тип, обеспечивающий уникальное значение для системного процесса (описан в главе 10).
id_t Целочисленный тип, способный хранить без усечения любой тип pid_t, uid_t или gid_t.
off_t Целочисленный тип со знаком для измерения размера файла в байтах.
size_t Целочисленный тип без знака для измерения размеров объектов в памяти, например, символьных строк, массивов или буферов.
ssize_t Целочисленный тип со знаком для подсчета байтов (положительные значения) или хранения кода возврата ошибки (отрицательные значения).
time_t Целочисленный тип (во всех обычных системах) или тип с плавающей точкой (позволяет рассматривать VMS как операционную систему POSIX), выдающий время в секундах, как описано в главе 18.

Типы намеренно описаны нечетко. Нет никакой гарантии, что типы будут одинаковыми на двух разных платформах Linux или даже в двух различных средах, работающих на одной и той же платформе. Скорее всего, 64-разрядная машина, поддерживающая как 64-разрядную, так и 32-разрядную среды, будет иметь разные значения для некоторых из этих типов в каждой среде.

Кроме того, в будущих версиях Linux представленные типы могут изменяться в рамках, установленных стандартом POSIX.

6.2.2. Раскрытие возможностей времени выполнения

Многие системные возможности имеют ограничения, другие являются необязательными, а некоторые могут содержать связанную с ними информацию. Ограничение на длину строки аргументов, передаваемых новой программе, защищает систему от произвольных запросов памяти, которые в ряде случаев могут вызвать крах системы. Не во всех системах POSIX реализовано управление заданиями. Любая программа может получить сведения о наиболее поздней версии стандарта POSIX, которая реализована в системе.

Функция sysconf() выдает такой тип системной информации, которая для одного и того же исполняемого файла в различных системах может отличаться и которую невозможно узнать во время компиляции.

#include <unistd.h>


long sysconf (int);

Целочисленный аргумент в sysconf() — это один из наборов макросов с префиксом _SC_. Ниже перечислены макросы, которые используются чаще всего.

_SC_CLK_TCK Возвращает количество тактов в секунду внутренних часов ядра, различаемое программами. Следует отметить, что ядро может содержать одни или больше часов, работающих на более высокой частоте. _SC_CLK_TCK обеспечивает подсчет тактов, которые используются для получения информации из ядра, и этот макрос не является индикатором времени ожидания системы.
_SC_STREAM_MAX Возвращает максимальное количество стандартных потоков ввода-вывода С, которые могут быть одновременно открыты в системе.
_SC_ARG_MAX Возвращает максимальную длину аргумента командной строки и переменных окружения в байтах, которые используются любой из функций exec(). Если это ограничение превышено, exec() вернет ошибку Е2ВIG.
_SC_OPEN_MAX Возвращает максимальное количество файлов, которые одновременно могут быть открыты процессом; это то же самое, что и программное ограничение RLIMIT_NOFILE, которое может быть запрошено функцией getrlimit() и установлено функцией setrlimit(). Это единственное значение sysconf(), которое может изменяться во время выполнения программы; при вызове setrlimit() для изменения ограничения RLIMIT_NOFILE. _SC_OPEN_MAX также подчиняется новому программному ограничению.
_SC_PAGESIZE или _SC_PAGE_SIZE Возвращает размер одной страницы в байтах. В системах, которые могут поддерживать разные размеры страниц, возвращается размер одной обычной страницы, для которой выделено определенное количество памяти и которая считается естественным размером страниц для конкретной системы.
_SC_LINE_MAX Возвращает максимальную длину в байтах входной строки, обрабатываемой текстовыми утилитами, включая завершающий символ новой строки. Следует отметить, что во многих утилитах GNU, используемых в Linux-системах, фактически нет жестко закодированной максимальной длины строки, потому могут применяться входные строки произвольной длины. Однако переносимая программа не должна вызывать текстовые утилиты для строк, длина которых превышает _SC_LINE_MAX; во многих Unix-системах утилиты работают с фиксированным максимальным размером строки, и его превышение может привести к неопределенным результатам.
_SC_NGROUPS_MAX Возвращает количество дополнительных групп (см. главу 10), которые может иметь процесс.

6.2.3. Поиск и настройка базовой системной информации

Существует несколько порций полезной информации о системе, которая может понадобиться программе. Например, название и версия операционной системы могут служить для определения функциональности, предлагаемой системными программами.

Системный вызов uname() позволяет программе обнаружить информацию времени ее выполнения.

#include <sys/utsname.h>


int uname(struct utsname* unameBuf);

В случае ошибки функция возвращает ненулевое значение, что происходит только в ситуациях, когда передается недопустимый указатель unameBuf. При нормальном завершении структура, на которую он указывает, заполняется строками, завершаемыми NULL, которые описывают текущую систему. В табл. 6.1 представлены члены структуры utsname.


Таблица 6.1. Члены структуры utsname

Член Описание
sysname Название операционной системы (в данном случае Linux).
release Номер версии выполняющегося ядра. Это полная версия вроде 2.6.2. Номер может быть легко изменен тем, кто выполнял сборку ядра, и вполне возможно, что цифр будет больше трех. Во многих версиях можно встретить дополнительную цифру для описания примененных исправлений, например, 2.4.17-23.
version Под Linux здесь содержится временная метка, описывающая время, когда собиралось ядро.
machine Короткая строка, указывающая тип микропроцессора, на котором работает операционная система. Для Pentium Pro или более мощных она может быть i686, для процессоров класса Alpha — alpha, а для 64-разрядных процессоров PowerPC — ррс64.
nodename Имя хоста машины, которое обычно является первичным именем хоста в Internet.
domainname Домен NIS (или YP), которому принадлежит машина.

Член nodename (имя узла) часто называется системным именем хоста (то, что отображает команда hostname), однако его не следует путать с именем Internet-хоста. Несмотря на то что во многих системах эти члены не различаются, путать их не стоит. В системе с множеством Internet-адресов есть множество имен Internet-хостов, но только одно имя узла, поэтому эти имена не являются эквивалентными.

Более распространенная ситуация связана с домашними компьютерами, которые используют Internet-каналы широкополосной связи. Обычно их имя хоста в Internet выглядит вроде host127-56.raleigh.myisp.com, а имена Internet-хостов меняются каждый раз при отключении на длительное время от модема[6]. Владельцы этих машин дают своим компьютерам имя узла, которое им больше нравится, например, loren или eleanor, что совершенно не относится к адресам Internet. При наличии множества машин, работающих на одном домашнем шлюзе, все они будут разделять один Internet-адрес (и одно имя Internet-хоста), но могут иметь имена вроде Linux.mynetwork.org и freebsd.mynetwork.org, которые все еще не являются именами Internet-хоста. В связи со всеми вышеперечисленными причинами, предполагать, что имя системного узла является допустимым именем Internet-хоста для машины не верно.

Имя узла системы устанавливается с помощью системного вызова sethostname()[7], и имя домена NIS (YP)[8] — посредством системного вызова setdomainname().

#include <unistd.h>


int sethostname(const char * name, size_t len);

int setdomainname(const char * name, size_t len);

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

6.3. Совместимость

Приложения, которые скомпилированы с заголовочными файлами из библиотеки glibc и привязанные к одной из ее версий, будут работать и с более поздними версиями библиотеки. Эта обратная совместимость обычно означает, что программисту не придется пересобирать свои приложения только из-за того, что выпущена новая версия glibc.

Существуют практические ограничения для обратной совместимости. Во-первых, смешивание объектов из разных версий glibc в одном исполняемом файле может иногда работать, но специально для такой совместимости ничего не предпринимается. Следует отметить, что это касается динамически загружаемых, а также статически связанных объектов. Во-вторых, приложение должно использовать только стандартные возможности glibc. Приложение, которое зависит от побочных эффектов ошибок или основано на неопределенном поведении одной из версий glibc, может не работать с более поздними версиями этой библиотеки. Приложение, компонуемое с приватными символами glibc (обычно они имеют префикс а_), также вряд ли будет работать с более новыми версиями glibc.

Обратная совместимость поддерживается тогда, когда задействованы символы, разработанные специально для соответствия стандартам версий. Когда разработчики glibc хотят внести несовместимое изменение в glibc, они сохраняют оригинальную реализацию или пишут совместимую реализацию данного интерфейса и помечают его более старым номером версии glibc. Затем они реализуют новый интерфейс (который может отличаться по семантике, сигнатуре или и тем, и другим) и помечают его новым номером версии glibc. Приложения, построенные на базе старой версии glibc, используют старый интерфейс, а приложения, построенные на основе новой версии — новый интерфейс.

Большинство других библиотек поддерживают совместимость, включая номер версии в имя библиотеки и позволяя множеству разных версий быть установленными одновременно. Например, инструментальные наборы GTK+ 1.2 и GTK+ 2.0 могут быть одновременно установлены в одной системе, каждый со своим собственным набором заголовочных и библиотечных файлов, путем встраивания в путь к заголовочным файлам и файлам библиотек имени версии.

Раздел стандарта по наименованию разделяемых библиотек в Linux включает старший номер версии для возможности установки в системе множества версий библиотеки. Это используется не очень часто, поскольку в одной системе невозможно скомпоновать новые приложения с множеством версий библиотеки; это просто обеспечивает поддержку лишь обратной совместимости для существующих приложений, построенных на более старых системах. На практике разработчикам требуется собирать приложения со многими версиями одной и той же библиотеки, поэтому большинство основных библиотек содержат в своем названии и номер версии.

Глава 7 Средства отладки использования памяти

Несмотря на то что С бесспорно является стандартным языком программирования в системах Linux, он имеет ряд особенностей, не дающих программистам возможности писать код, не содержащий тонких ошибок, которые впоследствии очень сложно отладить. Утечки памяти (когда память, выделенная с помощью malloc(), никогда не освобождается посредством free()) и переполнение буфера (например, запись за пределы массива) — наиболее распространенные и трудные для обнаружения программные ошибки. Недогрузка буфера (вроде записи перед началом массива) — менее распространенное, но обычно еще более тяжелое для отслеживания явление. В этой главе представлены несколько средств отладки, которые могут значительно упростить обнаружение и изоляцию упомянутых проблем.

7.1. Код, содержащий ошибки

 1: / * broken.с* /

 2:

 3: #include <stdlib.h>

 4: #include <stdio.h>

 5: #include <string.h>

 6:

 7: char global[5];

 8:

 9: int broken(void){

10:  char *dyn;

11:  char local[5];

12:

13:  /* Для начала немного перезаписать буфер */

14:  dyn = malloc(5);

15:  strcpy(dyn, "12345");

16:  printf ("1: %s\n", dyn);

17:  free(dyn);

18:

19:  /* Теперь перезаписать буфер изрядно */

20:  dyn = malloc(5);

21:  strcpy(dyn, "12345678");

22:  printf("2: %s\n", dyn);

23:

24:  /* Пройти перед началом выделенного с помощью malloc локального буфера */

25:  * (dyn-1) ='\0';

26:  printf ("3: %s\n", dyn);

27:  /* обратите внимание, что указатель не освобожден! */

28:

29:  /* Теперь двинуться после переменной local */

30:  strcpy(local, "12345");

31:  printf ("4: %s\n", local);

32:  local[-1] = '\0';

33:  printf("5: %s\n", local);

34:

35:  /* Наконец, атаковать пространство данных global */

36:  strcpy(global, "12345");

37:  printf ("6: %s\n", global);

38:

39:  /* И записать поверх пространства перед буфером global */

40:  global[-1] = '\0';

41:  printf("7: %s\n", global);

42:

43:  return 0;

44: }

45:

46: int main (void) {

47:  return broken();

48: }

В этой главе мы рассмотрим проблемы в показанном выше сегменте кода. Этот код разрушает три типа областей памяти: память, выделенную из динамического пула памяти (кучи) с помощью malloc(), локальные переменные размещенные в стеке программы и глобальные переменные, хранящиеся в отдельной области памяти, которая была статически распределена при запуске программы[9]. Для каждого класса памяти эта тестовая программа выполняет запись за пределами зарезервированной области памяти (по одному байту) и также сохраняет байт непосредственно перед зарезервированной областью. К тому же в коде имеется утечка памяти, что позволит продемонстрировать, как с помощью различных средств отследить эти утечки.

Несмотря на то что в представленном коде кроется много проблем, в действительности, он работает нормально. Не означает ли это, что проблемы подобного рода не важны? Ни в коем случае! Переполнение буфера часто приводит к неправильному поведению программы задолго до фактического его переполнения, а утечки памяти в программах, работающих длительное время, приводят к пустой растрате ресурсов компьютера. Более того, переполнение буфера является классическим источником уязвимостей безопасности, как описано в главе 22.

Ниже показан пример выполнения программы.

$ gcc -Wall -о broken broken.с

$ ./broken

1: 12345

2: 12345678

3: 12345678

4: 12345

5: 12345

6: 12345

7: 12345

7.2. Средства проверки памяти, входящие в состав glibc

Библиотека GNU С (glibc) предлагает три простых средства проверки памяти. Первые два — mcheck() и MALLOC_CHECK_ — вызывают проверку на непротиворечивость структуры данных кучи, а третье средство — mtrace() — выдает трассировку распределения и освобождения памяти для дальнейшей обработки.

7.2.1. Поиск повреждений кучи

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

Если вы установили переменную окружения MALLOC_CHECK_, выбирается другой, несколько более медленный набор функций управления памятью. Этот набор более устойчив к ошибкам и может обнаруживать ситуации, когда free() вызывается более одного раза для одного и того же указателя, а также когда происходят однобайтные переполнения буфера. Если MALLOC_CHECK_ установлена в 0, функции управления памятью просто более устойчивы к ошибкам, но не выдают никаких предупреждений. Если MALLOC_CHECK_ установлена в 1, функции управления памятью выводят предупреждения о стандартных ошибках при замеченной проблеме. Если MALLOC_CHECK_ установлена в 2, функции управления памятью вызывают abort(), когда замечают проблемы.

Установка MALLOC_CHECK_ в 0 может оказаться полезной, если вам мешает найти ошибку в памяти другая ошибка, которую в этот момент исправить нет возможности; эта установка позволяет работать с другими средствами отслеживания ошибок памяти.

Установка MALLOC_CHECK_ в 1 полезна в случае, когда никаких проблем не видно, поэтому определенные уведомления могут помочь.

Установка MALLOC_CHECK_ в 2 наиболее полезна при работе в отладчике, поскольку при возникновении ошибки он позволяет выполнить обратную трассировку вплоть до функций управления памятью. В результате вы максимально приблизитесь к месту возникновения ошибки.

$ MALLOC_CHECK_=1 ./broken

malloc: using debugging hooks

malloc: используются отладочные функции

1: 12345

free(): invalid pointer 0x80ac008!

free(): недопустимый указатель 0x80ac008!

2: 12345678

3: 12345678

4: 12345

5: 12345

6: 12345

7: 12345

$ MALLOC_CHECK_=2 gdb ./broken

...

(gdb) run

Starting program: /usr/src/lad/code/broken

Запуск программы: /usr/src/lad/code/broken

1: 12345

Program received signal SIGABRT, Aborted.

Программа получила сигнал SIGABRT, прервана.

0x00 с 64 с 32 in _dl_sysinfo_int80() from/lib/ld-linux.so.2

(gdb) where

#0 0x00c64c32 in _dl_sysinfo_int80() from /lib/ld-linux.so.2

#1 0x00322969 in raise() from /lib/tls/libc.so.6

#2 0x00324322 in abort() from /lib/tls/libc.so.6

#3 0x0036d9af in free_check() from /lib/tls/libc.so.6

#4 0x0036afa5 in free() from /lib/tls/libc.so.6

#5 0x0804842b in broken() at broken.c:17

#6 0x08048520 in main() at broken.с:47

Другой способ заставить glibc проверить кучу на непротиворечивость — воспользоваться функцией mcheck():

typedef void(*mcheck Callback)(enummcheck_status status);

void mcheck(mcheck Callback cb) ;

В случае вызова функции mcheck(), функция malloc() размещает известные последовательности байтов перед и после возвращенной области памяти, чтобы можно было обнаружить переполнение или недогрузку буфера, free() ищет эти сигнатуры и, если они были повреждены, вызывает функцию, указанную аргументом cb. Если cb равен NULL, выполняется выход. Запуск программы, связанной с mcheck(), в gdb может показать, какие именно области памяти были повреждены, если только они явно освобождаются с помощью free(). Однако метод mcheck() не может точно определить место ошибки; лишь программист может вычислить это, основываясь на понимании логики работы программы.

Компоновка нашей тестовой программы с mcheck дает следующие результаты:

$ gcc -ggdb -о broken broken.с -lmcheck

$ ./broken

1: 12345

memory clobbered past end of allocated block

память разрушена после конца распределенного блока

Вследствие того, что mcheck всего лишь выдает сообщения об ошибках и завершает работу, найти ошибку невозможно. Для точного обнаружения ошибки потребуется запустить программу внутри gdb и заставить mcheck вызывать abort() при обнаружении ошибки. Можно просто вызвать mcheck() внутри gdb или поместить mcheck(1) в первой строке вашей программы (веред вызовом malloc()). (Следует отметить, что mcheck() можно вызвать в gdb без необходимости компоновки программы с библиотекой mcheck.)

$ rm -f broken; make broken

$ gdb broken

...

(gdb) break main

Breakpoint 1 at 0x80483f4: file broken.c, line 14.

Точка прерывания 1 по адресу 0x80483f4: файл broken, с, строка 14.

(gdb) command 1

Type commands for when Breakpoint 1 is hit, one per line.

End with a line saying just "end".

Наберите команды, которые выполнятся при достижении точки прерывания 1, по одной в строке.

Завершите строкой, содержащей только "end".

> call mcheck(&abort)

> continue

> end (gdb) run

Starting program: /usr/src/lad/code/broken

Запуск программы: /usr/src/lad/code/broken

Breakpoint 1, main () at broken.с: 14

47 return broken();

$1 = 0

1: 12345

Program received signal SIGABRT, Aborted.

Программа получила сигнал SIGABRT, прервана.

0x00e12c32 in _dl_sysinfo_int80() from /lib/ld-linux.so.2

(gdb) where

#00x00el2c32 in _dl_sysinfo_int80() from /lib/ld-linux.so.2

#1 0x0072c969 in raise() from /lib/tls/libc.so.6

#2 0x0072e322 in abort() from /lib/tls/libc.so.6

#3 0x007792c4 in freehook() from /lib/tls/libc.so.6

#4 0x00774fa5 in free() from /lib/tls/libc.so.6

#5 0x0804842b in broken() at broken.c:17

#6 0x08048520 in main() at broken.с:47

Важной частью этого кода является обнаруженная ошибка в строке 17 файла broken.с. Видно, что ошибка была обнаружена во время первого вызова free(), который указал на наличие проблемы в области памяти dyn. (freehook() представляет собой ловушку, с помощью которой mcheck выполняет проверки.)

Библиотека mcheck не может помочь в обнаружении переполнения или недогрузки буфера в локальных или глобальных переменных, а только в областях памяти, распределенных с помощью malloc().

7.2.2. Использование mtrace() для отслеживания распределений памяти

Один из простых способов нахождения всех утечек памяти в программе предусматривает регистрацию всех вызовов malloc() и free(). По окончании программы очень легко сопоставить блоки, распределенные через malloc(), с точками, где они были освобождены с помощью free() или сообщить об ошибке, если для какого-то блока free() не вызывалась.

В отличие от mcheck(), в mtrace() нет соответствующей библиотеки для компоновки. Это не проблема, поскольку трассировку можно осуществлять в gdb. Однако для включения трассировки с помощью mtrace() должна быть установлена переменная окружения MALLOC_TRACE в допустимое имя файла; это может быть либо имя существующего файла, в который процесс может вести запись, либо имя нового файла, который процесс создаст и будет в него записывать.

$ MALLOC_TRACE=mtrace.log gdb broken

...

(gdb) breakmain

Breakpoint 1 at 0x80483f4: filebroken.c, line 14.

(gdb) command 1

Type commands for when Breakpoint 1 is hit, one per line.

End with a line saying just "end".

>call mtrace()

>continue

>end

(gdb) run

Starting program: /usr/src/lad/code/broken

Breakpoint 1, main() at broken.с:47

47 return broken();

$1 = 0

1: 12345

2: 12345678

3: 12345678

4: 12345

5: 12345

6: 12345

7: 12345

Program exited normally.

Программа завершена нормально.

 (gdb) quit

$ ls -l mtrace.log

-rw-rw-r-- 1 ewt ewt 220 Dec 27 23:41 mtrace.log

$ mtrace ./broken mtrace.log

Memory not freed:

He освобождена память:

----------------------

   Address   Size Caller

     Адрес Размер Место вызова

0x09211378    0x5 at /usr/src/lad/code/broken.с:20

Обратите внимание, что программа mtrace точно обнаружила утечку памяти. Также она может найти факт освобождения с помощью free() памяти, которая ранее не распределялась, если этот факт будет зафиксирован в журнальном файле, но на практике так не происходит, поскольку в этом случае программа немедленно аварийно завершается.

7.3. Поиск утечек памяти с помощью mpr

Возможности mtrace() в glibc достаточно неплохие, но профилировщик распределения памяти mpr (http://www3.telus.net/taj_khattra/mpr.html) в некоторых аспектах более прост в использовании и содержит более совершенные сценарии для обработки выходных журнальных файлов.

Первый шаг в применении mpr (после сборки кода с включенной отладочной информацией[10]) состоит в установке переменной окружения MPRFI, которая указывает mpr, с какой командой связывать журнал (если переменная не установлена, журнал не генерируется). Для небольших программ MPRFI устанавливается подобно cat >mpr.log. Для программ покрупнее MPRFI можно существенно сэкономить пространство за счет сжатия журнального файла во время его записи, установив MPRFI в gzip -1 >mpr.log.gz.

Самый легкий способ — воспользоваться сценарием mpr для запуска программы; если MPRFI еще не установлена, она получит значение gzip -1 >log.%p.gz, что приведет к созданию журнального файла с идентификатором процесса отлаживаемой программы и загрузке библиотеки mpr. В результате сборка программы не понадобится. Ниже показан пример создания журнального файла для исправленной версии нашей тестовой программы.

$ MPRFI="cat >mpr.log" mpr ./broken

1: 12345

2: 12345678

3: 12345678

4: 12345

5: 12345

6: 12345

7: 12345

$ ls -l mpr.log

-rw-rw-r-- 1 ewt ewt 142 May 17 16:22 mpr.log

После создания журнального файла доступны многие средства для его анализа. Все эти программы получают журнальный файл mpr в качестве стандартного ввода. Если вывод из этих средств содержит числа в тех местах, где ожидаются имена функций (возможно, с предупреждением вроде "cannot map pc to name" ("невозможно отобразить программный счетчик на имя")), проблема может быть связана с версией утилиты awk, которую использует mpr. В документации mpr для достижения лучших результатов рекомендуется экспортировать переменную окружения MPRAWK для выбора mawk в качестве версии awk: export MPRAWK='mawk -W sprintf=4096'. Кроме того, сбить с толку mpr может еще и рандомизация стека, которая обеспечивается функциональностью ядра "Exec-shield"; исправить положение можно за счет использования команды setarch, отключающей Exec-shield во время работы исследуемой программы и во время работы фильтров mpr: setarch i386 mpr программа и setarch i386 mprmap ...

В конечном итоге для некоторых стековых фреймов mpr может не найти символическое имя; в этом случае просто проигнорируйте их.

mprmap программа Преобразует адреса программы в журнале mpr в имена функций и местоположения в исходном коде. В аргументе указывается имя исполняемого файла, для которого должен генерироваться журнал. Чтобы увидеть все распределения в программе вместе с цепочкой вызовов функций, которые осуществили эти распределения, можно использовать mprmap программа < mpr.log. По умолчанию отображаются имена функций. При указании флажка -f отображаются также имена файлов, а при указании -l — еще и номера строк внутри файлов. Флажок -l подразумевает наличие -f. Вывод этой программы является допустимым журнальным файлом mpr, который может быть связан каналом с любой другой утилитой mpr.
mprchain Преобразует журнал в вывод, сгруппированный по цепочкам вызовов. Цепочка вызовов функций — это список всех функций, активных в программе на определенный момент. Например, если main() вызывает getargs(), которая впоследствии вызывает parsearg(), активная цепочка вызовов во время работы parsearg() отображается как main:getargs:parsearg. Для каждой отдельной цепочки вызовов, в которой распределялась память во время выполнения программы, mprchain отображает количество распределений и общее количество распределенных байт.
mprleak Этот фильтр просматривает журнальный файл на предмет наличия всех неосвобожденных фрагментов памяти. В качестве стандартного вывода генерируется новый журнальный файл, содержащий только те распределения, которые могут привести к утечкам памяти. Вывод этой программы является допустимым журнальным файлом mpr, который может быть связан каналом с любой другой утилитой mpr.
mprsize Этот фильтр сортирует распределения памяти по размеру. Чтобы просмотреть утечки памяти по размеру, нужно передать вывод mprleak на вход mprsize.
mprhisto Отображает гистограмму распределений памяти.

Теперь, когда известно об анализаторах журнальных файлов, очень просто найти утечки памяти в нашей тестовой программе. Для этого достаточно воспользоваться командой mprleak mpr.log | mprmap -l ./broken (что эквивалентно mprmap -l ./broken mpr.log | mprleak) и в результате обнаружить утечку памяти в строке 20.

$ mprleak mpr.log | mpr map -l ./broken

m:broken(broken.c,20): main(broken.c,47):5:134518624

7.4. Обнаружение ошибок памяти с помощью Valgrind

Valgrind (http://valgrind.kde.org/) представляет собой специфический для Intel х86 инструмент, эмулирующий центральный процессор класса х86 для непосредственного наблюдения над всеми обращениями к памяти и анализа потока данных (он может, например, выявлять чтения неинициализированной памяти, тем не менее перенос содержимого неинициализированной ячейки в другую ячейку, которая никогда для читается, как неинициализированное чтение он не трактует). Valgrind обладает множеством других возможностей, включая просмотр использования кэша и поиск состязаний в многопоточных программах. В действительности, в Valgrind имеется универсальное средство для добавления большего количества возможностей, основанных на его эмуляторе центрального процессора. Однако для наших целей мы лишь кратко рассмотрим выполнение с его помощью агрессивного поиска ошибок памяти, что представляет его стандартное поведение.

Valgrind не требует повторной компиляции программы, хотя, как и все средства отладки, он имеет возможность компилировать программы с отладочной информацией.

$ valgrind ./broken

==30882== Memcheck, a.k.a. Valgrind, a Memory ERROR detector for x86-linux.

==30882== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.

==30882== Using valgrind-2.0.0, a program super vision framewok for x86-linux.

==30882== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.

==30882== Estimated CPU clock rate is 1547 MHz

==30882== For more details, rerun with: -v

==30882==

==30882== Invalid write of size 1

==30882== Недопустимая запись размером 1

==30882== at 0xC030DB: strcpy (mac_replace_strmem.с:174)

==30882== by 0x8048409: broken (broken.с:15)

==30882== by 0x804851F: main (broken.с:47)

==30882== by 0x802BAE: libc_start_main (in /lib/libc-2.3.2.so)

==30882== Address 0x650F029 is 0 bytes after a block of size 5 alloc'd

==30882== at 0xC0C28B: malloc (vg_replace_malloc.с:153)

==30882== by 0x80483F3: broken (broken.с:14)

==30882== by 0x804851F: main (broken.с:47)

==30882== by 0x802BAE: libc_start_main (in /lib/libc-2.3.2.so)

==30882==

==30882== Conditional jump or move depends on uninitialised value(s)

==30882== Условный переход или перемещение зависит от

          неинициализироваиного значения(й)

==30882== at 0x863D8E: __GI_strlen (in /lib/libc-2.3.2.so)

==30882== by 0x83BC31: _IO_printf (in /lib/libc-2.3.2.so)

==30882== by 0x804841C: broken (broken.с:16)

==30882== by 0x804851F: main (broken.с:47)

1: 12345

==30882==

==30882== Invalid write of size 1

==30882== at 0xC030D0: strcpy (mac_replace_.с: 173)

==30882== by 0x804844D: broken (broken.с:21)

==30882== by 0x804851F: main (broken.с:47)

==30882== by 0x802BAE: _libc_start_main (in /lib/libc-2.3.2.so)

==30882== Address 0x650F061 is 0 bytes after a block of size 5 alloc'd

==30882== at 0xC0C28B: malloc (vg_replace_ malloc.с:153)

==30882== by 0x8048437: broken (broken.с:20)

==30882== by 0x804851F: main (broken.с:47)

==30882== by 0x802BAE: libc_start_main (in /lib/libc-2.3.2.so)

==30882==

==30882== Invalid write of size 1

==30882== at 0xC030DB: strcpy (mac_replace_strmem.с:174)

==30882== by 0x804844D: broken (broken.с:21)

==30882== by 0x804851F: main (broken.с:47)

==30882== by 0x802BAE: libc_start_main (in /lib/libc-2.3.2.so)

==30882== Address 0x650F064 is 3 bytes after a block of size 5 alloc'd

==30882== at 0xC0C28B: malloc (vg_replace_malloc.с:153)

==30882== by 0x8048437: broken (broken.с:20)

==30882== by 0x804851F: main (broken.с:47)

==30882== by 0x802BAE: __libc_start_main (in /lib/libc-2.3.2.so)

==30882==

==30882== Invalid read of size 4

==30882== Недопустимое чтение размером 4

==30882== at 0x863D50: __GI_strlen (in /lib/libc-2.3.2.so)

==30882== by 0x83BC31: _IO_printf (in /lib/libc-2.3.2.so)

==30882== by 0x8048460: broken (broken.с:22)

==30882== by 0x804851F: main (broken.с:47)

==30882== Address 0x650F064 is 3 bytes after a block of size 5 alloc'd

==30882== at 0xC0C28B: malloc (vg_replace_malloc.с:153)

==30882== by 0x8048437: broken (broken.с:20)

==30882== by 0x804851F: main (broken.с:47)

==30882== by 0x802BAE: __libc_start_main (in /lib/libc-2.3.2.so)

==30882==

==30882== Invalid read of size 1

==30882== at 0x857A21: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.3.2.so)

==30882== by 0x835309: _IO_vfprintf_internal (in /lib/libc-2.3.2.so)

==30882== by 0x83BC31: _IO_printf(in /lib/libc-2.3.2.so)

==30882== by 0x8048460: broken (broken.с:22)

==30882== Address 0x650F063 is 2 bytes after a block of size 5 alloc'd

==30882== at 0xC0C28B: malloc (vg_replace_malloc.с:153)

==30882== by 0x8048437: broken (broken.с:20)

==30882== by 0x804851F: main (broken.c:47)

==30882== by 0x802BAE: __libc_start_main (in /lib/libc-2.3.2.so)

==30882==

==30882== Invalid read of size 1

==30882== at 0x857910: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.3.2.so)

==30882== by 0x835309: _IO_vfprintf_internal (in /lib/libc-2.3.2.so)

==30882== by 0x83BC31: _IO_printf (in /lib/libc-2.3.2.so)

==30882== by 0x8048460: broken (broken.с:22)

==30882== Address 0x650F061 is 0 bytes after a block of size 5'alloc'd

==30882== at 0xC0C28B: malloc (vg_replace_malloc.с:153)

==30882== by 0x8048437: broken (broken.с:20)

==30882== by 0x804851F: main (broken.с:47)

==30882== by 0x802BAE: __libc_start_main (in /lib/libc-2.3.2.so)

2: 12345678

==30882==

==30882== Invalid write of size 1

==30882== at 0x8048468: broken (broken.с:25)

==30882== by 0x804851F: main (broken.с:47)

==30882== by 0x802BAE: __libc_start_main (in /lib/libc-2.3.2.so)

==30882== by 0x8048354: (within /usr/src/d/lad2/code/broken)

==30882== Address 0x650F05B is 1 bytes before a block of size 5 alloc'd

==30882== at 0xC0C28B: malloc (vg_replace_malloc.c:153)

==30882== by 0x8048437: broken (broken.с:20)

==30882== by 0x804851F: main (broken.с:47)

==30882== by 0x802BAE: __libc_start_main (in /lib/libc-2.3.2.so)

==30882==

==30882== Invalid read of size 4

==30882== at 0x863D50: __GI_strlen (in /lib/libc-2.3.2.so)

==30882== by 0x83BC31: _IO_printf (in /lib/libc-2.3.2.so)

==30882== by 0x804847A: broken (broken.c:2 6)

==30882== by 0x804851F: main (broken.c:47)

==30882== Address 0x650F064 is 3 bytes after a block of size 5 alloc'd

==30882== at 0xC0C28B: malloc (vg_replace_malloc.c:153)

==30882== by 0x8048437: broken (broken.с:20)

==30882== by 0x804851F: main (broken.c:47)

==30882== by 0x802BAE: __libc_start_main (in /lib/libc-2.3.2.so)

==30882==

==30882== Invalid read of size 1

==30882== at 0x857A21: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.3.2.so)

==30882== by 0x835309: _IO_vfprintf_internal (in /lib/libc-2.3.2.so)

==30882== by 0x83BC31: _IO_printf (in /lib/libc-2.3.2.so)

==30882== by 0x804847A: broken (broken.c:2 6)

==30882== Address 0x650F063 is 2 bytes after a block of size 5 alloc'd

==30882== at 0xC0C28B: malloc (vg_replace_malloc.c:153)

==30882== by 0x8048437: broken (broken.с:20)

==30882== by 0x804851F: main (broken.с:47)

==30882== by 0x802BAE: __libc_start_main (in /lib/libc-2.3.2.so)

==30882==

==30882== Invalid read of size 1

==30882== at 0x857910: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.3.2.so)

==30882== by 0x835309: _IO_vfprintf_internal (in /lib/libc-2.3.2.so)

==30882== by 0x83BC31: _IO_printf (in /lib/libc-2.3.2.so) ==30882== by 0x804847A: broken (broken.c:2 6)

==30882== Address 0x650F061 is 0 bytes after a block of size 5 alloc'd

==30882== at 0xC0C28B: malloc (vg_replace_malloc.с:153)

==30882== by 0x8048437: broken (broken.с:20)

==30882== by 0x804851F: main (broken.с:47)

==30882== by 0x802BAE: __libc_start_main (in /lib/libc-2.3.2.so)

3: 12345678

4: 12345

==30882==

==30882== Invalid write of size 1

==30882== at 0x80484A6; broken (broken.c:3 2)

==30882== by 0x804851F: main (broken.с:47)

==30882== by 0x802BAE: __libc_start_main (in /lib/libc-2.3.2.so)

==30882== by 0x8048354: (within /usr/src/d/lad2/code/broken)

==30882== Address 0xBFF2D0FF is just below %esp. Possibly a bug in GCC/G++

==30882== v 2.96 or 3.0.X. To suppress, use: --workaround-gcc 296-bugs = yes

5: 12345

6: 12345

7: 12345

==30882==

==30882== ERROR SUMMARY: 22 ERRORS from 12 contexts (suppressed: 0 from 0)

==30882== malloc/free: in use at exit: 5 bytes in 1 blocks.

==30882== malloc/free: 2 allocs, 1 frees, 10 bytes allocated.

==30882== For a detailed leak analysis, rerun with: --leak-check=yes

==30882== For counts of detected ERRORS, rerun with: -v

==30882== ИТОГИ ПО ОШИБКАМ: 22 ошибки в 12 контекстах (подавлено: 0 из 0)

==30882== malloc/free: используются после завершения: 5 байт в 1 блоке.

==30882== malloc/free: 2 распределения, 1 освобождение, 10 байт распределено.

==30882== Для детального анализа утечек памяти запустите с: --leak-check=yes

==30882== Для подсчета обнаруженных ошибок запустите с: -v

Обратите внимание, что Valgrind нашел все, кроме глобального переполнения и недогрузки, и указал на ошибки более точно, нежели любое другое ранее описанное средство.

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

$ valgrind --leak-check=yes ./broken

...

==2292== searching for pointers to 1 not-freed blocks.

==2292== checked 5318724 bytes.

==2292== поиск указателей на 1 неосвобожденный блок.

==2292== проверено 5318724 байт.

==2292==

==2292== 5 bytes in 1 blocks are definitely lost in loss record 1 of 1

==2292== 5 байт в 1 блоке определенно потеряны в потерянной записи 1 из 1

==2292== at 0хЕС528В: malloc (vg_replace_malloc.с:153)

==2292== by 0x8048437: broken (broken.с:20)

==2292== by 0x804851F: main (broken.с:47)

==2292== by 0x126BAE: __libc_start_main (in /lib/libc-2.3.2.so)

==2292==

==2292== LEAK SUMMARY:

==2292== definitely lost: 5 bytes in 1 blocks.

==2292== possibly lost: 0 bytes in 0 blocks.

==2292== still reachable: 0 bytes in 0 blocks.

==2292== suppressed: 0 bytes in 0 blocks.

==2292== Reachable blocks (those to which a pointer was found) are not shown.

==2292== To see them, rerun with: --show-reachable=yes

==2292== ИТОГИ ПО УТЕЧКАМ:

==2292== определенно потеряно: 5 байт в 1 блоке.

==2292== возможно потеряно: 0 байт в 0 блоке.

==2292== пока достижимы: 0 байт в 0 блоке.

==2292== подавлено: 0 байт в 0 блоке.

==2292== Достижимые блоки (на которые найдены указатели) не показаны.

==2292== Чтобы увидеть их, запустите с: --show-reachable=yes

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

Valgrind могут слегка ввести в заблуждение программы, скомпилированные с высокими уровнями оптимизации. Если вы получаете отчет об ошибке памяти, которая не выглядит осмысленно, попробуйте перекомпилировать программу с вместо -O2 (или выше) и сгенерировать новый отчет.

7.5. Electric Fence

Следующее средство, которое мы рассмотрим — это Electric Fence (доступен на ftp://sunsite.unc.edu/pub/Linux/devel/lang/c и во многих дистрибутивах). Несмотря на то что Electric Fence не обнаруживает утечки памяти, он очень помогает в изоляции переполнений буфера. Каждый современный компьютер (включая все машины, работающие под Linux) обеспечивают аппаратную защиту памяти. Linux этим пользуется для изоляции программ друг от друга (например, сеанс vi не имеет доступа к памяти gcc) и для безопасного разделения кода между процессами, делая его только для чтения. Системный вызов mmap() в Linux (см. главу 13) позволяет процессу воспользоваться также аппаратной защитой памяти.

Electric Fence заменяет обычную функцию malloc() библиотеки С версией, которая распределяет запрошенную память и (обычно) непосредственно после запрошенной выделяет фрагмент памяти, доступ к которой процессу не разрешен. Если процесс попытается получить доступ к этой памяти, ядро немедленно остановит его с выдачей ошибки сегментации. За счет такого распределения памяти Electric Fence обеспечивает уничтожение программы, если та предпримет попытку чтения или записи за границей буфера, распределенного malloc(). Детальную информацию по использованию Electric Fence можно прочитать на его man-странице (man libefence).

7.5.1. Использование Electric Fence

Одна из наиболее примечательных особенностей Electric Fence заключается в простоте ее использования. Нужно всего лишь скомпоновать свою программу с библиотекой libefence.а, указав -lefence в качестве последнего аргумента. В результате код будет готов к отладке. Давайте посмотрим, что происходит при запуске тестовой программы с применением Electric Fence.

$ ./broken

Electric Fence 2.2.0 Copyright (C) 1987 - 1999 Bruce Perens.

1: 12345

Segmentation fault (core dumped)

Ошибка сегментации (дамп ядра сброшен)

Хотя Electric Fence непосредственно не указывает на место, где произошла ошибка, проблема становится намного очевидней. Можно легко и точно определить проблемный участок, запустив программу под управлением отладчика, например gdb. Для того чтоб gdb смог точно указать на проблему, соберите программу с отладочной информацией, указав для gcc флажок -g, затем запустите gdb и зададите имя исполняемого файла, который нужно отладить. Когда программы уничтожается, gdb точно показывает, в какой строке произошел сбой.

Вот как выглядит описанная процедура.

$ gcc -ggdb -Wall -о broken broken.с -lefence

$ gdb broken

...

(gdb) run

Starting program: /usr/src/lad/code/broken

Electric Fence 2.2.0 Copyright (C) 1987 - 1999 Bruce Perens.

1: 12345

Program received signal SIGSEGV, Segmentation fault.

Программа получила сигнал SIGSEGV, ошибка сегментации.

0х007948с6 in strcpy() from /lib/tls/libc.so.6

(gdb) where

#0 0x007948c6 in strcpy() from /lib/tls/libc.so.6

#1 0x08048566 in broken() at broken.c:21

#2 0x08048638 in main() at broken.c:47

(gdb)

Благодаря Electric Fence и gdb, становится понятно, что в строке 21 файла broken.с имеется ошибка, связанная со вторым вызовом strcpy().

7.5.2. Выравнивание памяти

Хотя инструмент Electric Fence очень помог в обнаружении второй проблемы в коде, а именно — вызова strcpy(), переполнившего буфер, первое переполнение буфера найдено не было.

Проблему в этом случае нужно решать с помощью выравнивания памяти. Большинство современных компьютеров требуют, чтобы многобайтные объекты начинались с определенных смещений в оперативной памяти. Например, процессоры Alpha требуют, чтобы 8-байтовый тип — длинное целое (long) — начинался с адреса, кратного 8. Это значит, что длинное целое может располагаться по адресу 0x1000 или 0x1008, но не 0x1005[11].

На основе этих соглашений реализации malloc() обычно возвращают память, первый байт которой выровнен в соответствии с размером слова процессора (4 байта для 32-разрядных и 8 байтов на 64-разрядных процессоров). По умолчанию Electric Fence пытается эмулировать такое поведение, предлагая функцию malloc(), возвращающую только адреса, кратные sizeof(int).

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

В случае с нашей тестовой программой первый вызов malloc() распределил пять байт.

Для того чтобы Electric Fence удовлетворял своим ограничениям по выравниванию, он трактует этот вызов как запрос восьми байт, с дополнительными тремя доступными байтами. В этом случае небольшие переполнения буфера, распространяющиеся на эту область, не перехватываются.

В связи с тем, что выравнивание malloc() обычно можно игнорировать, а выравнивание может способствовать незаметному переполнению буфера, Electric Fence предоставляет возможность управление выравниванием через переменную окружения ЕF_ALIGNMENT. Если эта переменная установлена, все результаты malloc() выравниваются в соответствии с ее значением. Например, если переменная установлена в значение 5, все результаты malloc() будут рассматриваться как кратные 5 (тем не менее, это значение не особенно полезно). Для отключения выравнивания памяти перед запуском программы установите ЕF_ALIGNMENT в 1. В среде Linux некорректно выровненный доступ в любом случае исправляются в ядре, несмотря на то, что в результате скорость выполнения программы может существенно снизиться. Программа будет функционировать корректно, если только в ней не присутствуют небольшие переполнения буфера.

Ниже приведен пример поведения тестовой программы, скомпонованной с Electric Fence, после установки ЕF_ALIGNMENT в 1.

$ export EF_ALIGNMENT=1

$ gdb broken

...

(gdb) run

Starting program: /usr/src/lad/code/broken

Electric Fence 2.2.0 Copyright (C) 1987 - 1999 Bruce Perens.

Program received signal SIGSEGV, Segmentation fault.

0x002a78c6 in strcpy() from /lib/tls/libc.so.6

(gdb) where

#0 0x002a78c6 in strcpy() from /lib/tls/libc.so.6

#1 0x08048522 in broken() at broken.c:15

#2 0x08048638 in main() at broken.с:47

На этот раз Electric Fence нашел переполнение буфера, которое произошло первым.

7.5.3. Другие средства

Electric Fence не только помогает обнаружить переполнение буфера, но и может найти недогрузку буфера (выполняя доступ к памяти, расположенной перед началом выделяемого malloc() буфера) и получает доступ к памяти, освобождаемой с помощью free(). Если переменная окружения EF_PROTECT_BELOW установлена в 1, Electric Fence перехватывает недогрузку буфера вместо его переполнения. Это происходит путем размещения недоступной области памяти непосредственно перед фактической областью памяти, возвращаемой функцией malloc(). При этом Electric Fence не сможет обнаружить переполнение буфера из-за страничной организации памяти, реализованной в большинстве процессоров. Выравнивание памяти может затруднить обнаружение переполнения буфера, однако оно не влияет на недогрузку буфера. Функция malloc() из Electric Fence всегда возвращает адрес памяти в начале страницы, которая всегда выровнена по границе слова.

Если EF_PROTECT_FREE установлена в 1, free() делает переданную ей область памяти недоступной, но не возвращает ее в пул свободной памяти. Если программа пытается получить доступ к этой памяти на любом этапе в будущем, ядро обнаружит несанкционированный доступ. Настройка EF_PROTECT_FREE помогает удостовериться, что код ни на одном этапе выполнения не использует память, освобожденную с помощью free().

7.5.4. Ограничения

Несмотря на то что Electric Fence выполняет неплохую работу по обнаружению переполнения буферов, выделенных malloc(), он не помогает отслеживать проблемы ни с глобальными, ни с локальными данными. Electric Fence также не обнаруживает утечки памяти, потому решать эту проблему придется другими средствами.

7.5.5. Потребление ресурсов

Хотя Electric Fence является мощным, легким в употреблении и быстрым инструментом (поскольку все проверки доступа осуществляются аппаратными средствами), за все это приходится платить свою цену. Большинство процессоров позволяют системе управлять доступом к памяти только в единицах, равных странице, за один раз. На процессорах Intel 80x86, например, каждая страница занимает 4096 байт. Вследствие того, что Electric Fence требует от malloc() установки двух разных областей памяти для каждого вызова (одна — позволяющая доступ, а другая — запрещающая), каждый вызов malloc() потребляет страницу памяти, или 4 Кбайт[12]! Если в тестируемом коде распределяется множество небольших участков памяти, его компоновка с Electric Fence может легко увеличить потребление памяти программы на два или три порядка. При этом использование EF_PROTECT_FREE еще более усугубляет положение, поскольку память никогда не освобождается.

Для систем с большими относительно размера отлаживаемой программы объемами памяти при поиске источника определенной проблемы Electric Fence может действовать быстрее, чем Valgrind. Тем не менее, если для функционирования Electric Fence требуется организовать пространство для свопинга размером в 1 Гбайт, то Valgrind, вполне вероятно, окажется намного быстрее, даже несмотря на то, что он использует эмулятор, а не собственно центральный процессор.

Глава 8 Создание и использование библиотек

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

8.1. Статические библиотеки

Статические библиотеки представляют собой простые коллекции объектных файлов, объединенных утилитой ar (архиватор), ar группирует объектные файлы в один архив и добавляет таблицу, в которой указано, какие объектные файлы в архиве какие символы определяют. Затем компоновщик, ld, связывает ссылки на символ в одном объектном файле с определением этого символа в объектном файле архива. Для статических библиотек используется суффикс .

В статическую библиотеку можно преобразовать группу объектных файлов с помощью такой команды:

ar res libname.a foo.o bar.о baz.o

Также в архив можно добавлять объектные файлы по одному.

ar res libname.a foo.o

ar res libname.a bar.о

ar res libname.a baz.o

В любом случае libname.a получится одинаковым. В команде использованы перечисленные ниже опции.

r Включает объектные файлы в библиотеку, заменяя любой уже существующий в архиве файл с таким же именем.
с Молча создает библиотеку, если таковой еще не существует.
s Поддерживает в таблице соответствие названий символов объектным файлам.

При сборке статических библиотек необходимость в использовании других опций возникает не часто. Однако ar поддерживает другие опции и возможности, о которых подробно можно прочесть на man-странице команды.

8.2. Совместно используемые библиотеки

Совместно используемые, или разделяемые, библиотеки обладают рядом преимуществ по сравнению со статическими библиотеками.

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

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

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

• При обнаружении ошибки совместно используемую библиотеку можно заменить исправленной версией, а не компилировать повторно каждую программу, ее использующую.

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

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

Теперь стандартный формат двоичного файла практически на каждой платформе Linux представляет собой современный, расширяемый файловый формат ELF (Executable and Linking Format — формат исполняемых и компонуемых модулей), описанный в [24], ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.g и ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz. Это значит, что практически на всех платформах Linux шаги, предпринимаемые для создания и использования разделяемых библиотек, совершенно одинаковы.

8.3. Разработка совместно используемых библиотек

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

Совместно используемые библиотеки ориентированы на поддержание обратной совместимости. Это значит, что двоичный файл, собранный с ранней версией библиотеки, будет работать и с более поздней ее версией. Однако в некоторых случаях библиотеки не являются совместимыми: например, при необходимости модифицировать интерфейсы способом, не предусматривающим обратную совместимость.

8.3.1. Управление совместимостью

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

Например, разработчики и службы поддержки библиотеки С в Linux стараются поддерживать обратную совместимость для всех выпусков библиотеки С с одним и тем же старшим номером версии. Версия 5 библиотеки С прошла через пять небольших ревизий и, за некоторыми исключениями, программы, работающие с первой младшей версией, будут работать и с последней. (Исключения составляют неудачно написанные программы, основанные на неопределенном поведении библиотеки С или библиотеке С с ошибками, которые были исправлены в более новых версиях.) Ввиду того, что все библиотеки С версии 5 рассчитаны на обратную совместимость с предыдущими версиями, все они используют одно и то же имя soname — libc.so.5, относящееся к имени файла, в котором оно хранится — /lib/libc.so.5.m.r, где m — младший номер версии, a r — номер выпуска.

Приложения, которые компонуются с совместно используемой библиотекой, не компонуются непосредственно, например, с /lib/libc.so.6, даже если этот файл существует. Программа ldconfig, стандартная системная утилита, создает символическую ссылку /lib/libc.so.6 (soname) на /lib/libc-2.3.2.so, действительное имя библиотеки.

В результате упрощается модернизация совместно используемых библиотек. Для обновления версии 2.3.2 до 2.3.3 потребуется всего лишь скопировать новую версию libc-2.3.3.so в каталог /lib и запустить ldconfig. ldconfig просматривает все библиотеки с soname, равным libc.so.6, и создает символическую ссылку из soname на самую новую библиотеку, включающую это soname. Затем все приложения, скомпонованные с /lib/libc.so.6, автоматически используют новую библиотеку при последующих запусках, a /lib/libc-2.3.2.so можно смело удалить, поскольку потребность в ней полностью отпадает.

Не компонуйте программы со специфическими версиями библиотеки, если на то нет веских причин. Всегда используйте стандартную опцию -lимя_библиотеки компилятора или компоновщика. Таким образом, вы никогда не скомпонуете по ошибке приложение с неправильной версией. Компоновщик всегда будет искать файл libимя_библиотеки.so, который будет символической ссылкой на новую версию библиотеки.

Итак, для компоновки с библиотекой С компоновщик находит /usr/lib/libc.so, указывающую на то, что нужно использовать /lib/libc.so.6, который является ссылкой на /lib/libc-2.3.2.so. Приложение компонуется с soname-именем libc-2.3.2.so — libc.so.6, и при запуске оно находит /lib/libc.so.6 и связывается с libc-2.3.2.so, поскольку libc.so.6 является символической ссылкой на libc-2.3.2.so.

8.3.2. Несовместимые библиотеки

Если новая версия библиотеки не должна быть совместимой с предшествующими ее версиями, ей потребуется присвоить другое имя soname. Например, для выпуска новой версии библиотеки С, не совместимой со старой версией, разработчики использовали soname libc.so.6 вместо libc.so.5. В результате делается акцент на несовместимости, а приложения, скомпонованные с разными версиями библиотеки, могут сосуществовать в одной системе. Приложения, скомпонованные с одной из версий libc.so.5, будут продолжать использовать последнюю версию библиотеки с soname libc.so.5, а приложения, скомпонованные с одной из версий libc.so.6, будут работать с последней версией библиотеки, соответствующей soname libc.so.6.

8.3.3. Разработка совместимых библиотек

При разработке собственных библиотек необходимо знать факторы, делающие библиотеку несовместимой. Существуют три основных причины несовместимости.

1. Изменение или удаление интерфейсов экспортированных функций.

2. Изменение экспортированных элементов данных, исключая добавление необязательных элементов в конец структур, размещенных внутри библиотеки.

3. Изменение поведения функций, выходящее за пределы первоначальной спецификации.

Для поддержания совместимости версий библиотеки можно предпринимать следующие действия.

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

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

8.4. Сборка совместно используемых библиотек

Если вы разобрались с концепцией имен soname, все остальное просто. Достаточно следовать нескольким несложным правилам, которые перечислены ниже.

• Собирайте свой исходный код с указанием флага -fPIC для gcc. В результате сгенерируется независимый от места расположения код, который можно компоновать и загружать по любому адресу[13].

• Не используйте опцию компилятора -fomit-frame-pointer. Библиотеки по-прежнему будут работать, но отладчики станут бесполезными. Если в библиотеке будет найдена ошибка, пользователь не сможет осуществить обратную трассировку ошибки в коде.

• При компоновке библиотеки используйте gcc вместо ld. Компилятору С известно, как вызывать загрузчик для правильной компоновки, к тому же нет никакой гарантии, что интерфейс для ld останется неизменным.

• При компоновке библиотеки не забывайте предоставлять имя soname. Для этого используется специальная опция компилятора -Wl. Для сборки своей библиотеки используйте команду

gcc -shared -Wl, -soname, sonamelibname filelist liblist

где soname — имя soname, libname — имя библиотеки, включая полное имя версии, например, libc.so.5.3.12, filelist — список объектных файлов, которые нужно разместить в библиотеке, a liblist — список других библиотек, предоставляющих символы, к которым будет получать доступ эта библиотека. Последний элемент очень легко пропустить, поскольку без него библиотека будет работать в системе, в которой она создана, но может не работать в других ситуациях. Практически для любой библиотеки в список следует включать библиотеку С, поместив -lс в конце списка.

Чтобы создать файл libfоо.so.1.0.1 с soname-именем libfоо.so.1 из объектных файлов fоо.о и bar.о, используйте следующую команду:

gcc -shared -Wl,-soname,libfoo.so.1 -о libfoo.so.1.0.1 foo.o bar.о -lc

• He разбивайте на полосы библиотеку, если только не сталкиваетесь с окружением, где пространство ограничено. Разбитые на полосы библиотеки будут функционировать, но будут иметь такие же основные недостатки, что и библиотеки, собранные из объектных файлов, скомпилированных с -fomit-frame-pointer.

8.5. Инсталляция совместно используемых библиотек

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

1. Скопируйте совместно используемую библиотеку в каталог, в котором она должна быть сохранена.

2. Если нужно, чтоб компоновщик смог найти библиотеку без указания ее с помощью флажка -Lбиблиотека, инсталлируйте библиотеку в /usr/lib или создайте символическую ссылку в /usr/lib по имени имя_библиотеки.so, которая указывает на файл совместно используемой библиотеки. Вы должны использовать относительную символическую ссылку (когда /usr/lib/libc.so указывает на ../../lib/libc.so.5.3.12), а не абсолютную (когда /usr/lib/libc.so указывает на /lib/libc.so.5.3.12).

3. Если нужно, чтобы компоновщик смог обнаружить библиотеку без ее инсталляции в системе (или до ее инсталляции), создайте ссылку имя_библиотеки.so в текущем каталоге. Затем используйте -L., чтоб указать gcc на поиск библиотек в текущем каталоге.

4. Если полный путь к каталогу, в который вы инсталлировали файл совместно используемой библиотеки, не перечислен в /etc/ld.so.conf, добавьте его в этот файл, указав в отдельной строке.

5. Запустите программу ldconfig, которая создаст в каталоге, где инсталлирован файл совместно используемой библиотеки, еще одну символическую ссылку из имени soname на установленный файл. Затем в кэше динамического загрузчика появится соответствующая запись. В результате динамический загрузчик сможет найти вашу библиотеку при запуске скомпонованных с нею программ, не проводя поиск ее во множестве каталогов[14].

Создавать записи в /etc/ld.so.conf и запускать ldconfig нужно только тогда, когда библиотеки инсталлируются в качестве системных.

8.5.1. Пример

В качестве очень простого, но все же информативного примера создадим библиотеку, содержащую одну короткую функцию. Ниже показано содержимое файла libhello.c.

1: /* libhello.c */

2:

3: #include <stdio.h>

4:

5: void print_hello (void) {

6:  printf("Добро пожаловать в библиотеку!\n");

7: }

Разумеется, необходима программа, которая использует библиотеку libhello.

1: / * usehello.c * /

2:

3: #include "libhello.h"

4:

5: int main(void) {

6:  print_hello();

7:  return 0;

8: }

Содержимое libhello.h оставлено в качестве упражнения для самостоятельной проработки. Для того чтобы скомпилировать и воспользоваться этой библиотекой без ее инсталляции в системе, выполните перечисленные ниже шаги.

1. С использованием флажка -fPIC соберите объектный файл совместно используемой библиотеки:

gcc -fPIC -Wall -g -с libhello.c

2. Скомпонуйте libhello с библиотекой С для достижения лучших результатов во всех системах:

gcc -g -shared -Wl, -soname,libhello.so.0 -о libhello.so.0.0 libhello.о -lc

3. Создайте ссылку из soname на библиотеку:

ln -sf libhello.so.0.0 libhello.so.0

4. Создайте ссылку для использования компоновщиком при компиляции приложений с опцией -lhello:

ln -sf libhello.so.0 libhello.so

5. С помощью флажка -L. укажите компоновщику на необходимость поиска библиотек в текущем каталоге, а с помощью -lhello определите, с какой библиотекой выполнять компоновку:

gcc -Wall -g -с usehello.c -о usehello.o

gcc -g -о usehello usehello.o -L. -lhello

(В этом случае приложение будет компоноваться, даже если вы инсталлируете библиотеку в системе вместо того, чтобы оставить ее в текущем каталоге.)

6. Теперь запустите usehello:

LD_LIBRARY_PATH=$(pwd) ./usehello

Переменная окружения LD_LIBRARY_PATH указывает системе места, где следует искать библиотеки (более детальная информация представлена в следующем разделе). Конечно, по желанию можно установить libhello.so.* в /usr/lib и избежать настройки переменной окружения LD_LIBRARY_PATH.

8.6. Работа с совместно используемыми библиотеками

Самый легкий способ работы с совместно используемыми библиотеками — игнорировать тот факт, что она совместная. Компилятор С автоматически задействует совместно используемые библиотеки вместо статических, если ему явно не указано обратное.

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

8.6.1. Использование деинсталлированных библиотек

После запуска программы динамический загрузчик обычно ищет необходимые программе библиотеки в кэше (/etc/ld.so.cache, созданном ldconfig) библиотек, которые находятся в каталогах, записанных в /etc/ld.so.conf. Однако если установлена переменная окружения LD_LIBRARY_PATH, поиск осуществляется сначала в каталогах, перечисленных в ней. Это значит, что если вы хотите использовать измененную версию библиотеки С при работе с определенной программой, эту библиотеку можно поместить в любой каталог и соответствующим образом изменить LD_LIBRARY_PATH. Например, некоторые версии браузера Netscape, скомпонованные с версией 5.2.18 библиотеки С, не будут работать вследствие ошибки сегментации при запуске со стандартной библиотекой С 5.3.12. Это происходит из-за более строгой политики malloc(). Многие помещают копию библиотеки С 5.2.18 в отдельный каталог, например, /usr/local/netscape/lib/, переносят туда исполняемый файл браузера Netscape и заменяют /usr/local/bin/netscape сценарием оболочки, который выглядит примерно так:

#!/bin/sh

export LD_LIBRARY_PATH=/usr/local/netscape/lib:$LD_LIBRARY_PATH

exec /usr/local/netscape/lib/netscape $*

8.6.2. Предварительная загрузка библиотек

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

Пример может служить zlibc. Эта библиотека заменяет файловые функции библиотеки С функциями, которые работают со сжатыми файлами. При открытии файла zlibc ищет как запрашиваемый файл, так и gzip-версию файла. Если запрашиваемый файл существует, zlibc в точности воспроизводит функцию библиотеки С, но если файла нет, а вместо него обнаруживается gzip-версия, библиотека распаковывает gzip-файл безо всякого уведомления приложения. Связанные с ней ограничения описаны в документации, zlibc позволяет значительно увеличить количество свободного пространства на диске, разумеется, за счет снижения скорости. Существуют два способа предварительной загрузки библиотеки. Для действия только на определенные программы, можно установить переменную окружения для необходимых случаев:

LD_PRELOAD=/lib/libsomething.o exec /bin/someprogram $*

Кроме того, как и с zlibc, может возникнуть потребность предварительно загрузить библиотеку для всех программ в системе. Самый простой способ для этого — добавить в файл /etc/ld.so.preload строку, которая указывает библиотеку, подлежащую загрузке. Для случая zlibc строка будет выглядеть следующим образом:

/lib/uncompress.о

Глава 9 Системное окружение Linux

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

9.1. Окружение процесса

Как подробно описано в главе 10, в каждом выполняющемся процессе есть переменные окружения. Переменные окружения представляют собой пары "имя-значение", и некоторые из них представляют ценность для программистов на языке С. (Многие переменные в первую очередь используются при программировании оболочки, как ускоренные альтернативы запуску программ, вызывающих функции библиотек; в этой книге они описываться не будут.)

EDITOR или VISUAL При установке EDITOR или VISUAL у пользователя появляется возможность выбирать текстовый редактор для редактирования текстового файла. Использование двух различных переменных объясняется тем, что когда-то EDITOR применялась для телетайпной машины, a VISUAL — для полноэкранного терминала.
LD_LIBRARY_PATH Обеспечивает разделенные двоеточиями пути к каталогам, в которых следует искать библиотеки. Обычно эту переменную устанавливать не нужно, поскольку в системном файле /etc/ld.so.conf есть вся необходимая информация. Модифицировать его в своих программах вряд ли придется; эта переменная предоставляет информацию для системного компоновщика времени выполнения, ld.so. Однако, как было описано в главе 8, LD_LIBRARY_PATH может оказаться полезной при разработке совместно используемых библиотек.
LD_PRELOAD Перечисляет библиотеки, которые должны быть загружены для переопределения символов в системных библиотеках. LD_PRELOAD, как и LD_LIBRARY_PATH, более подробно описана в главе 8.
PATH Предоставляет разделенный двоеточиями путь к каталогам, где следует искать исполняемые программы для запуска. Следует отметить, что в Linux (как и во всех вариантах Unix), в отличие от некоторых операционных систем, не принят автоматический поиск исполняемого файла в текущем каталоге. Для этого путь должен включать каталог . (точка). Более подробно о работе с этой переменной рассказывается в главе 10.
TERM Предоставляет информацию о типе терминала, установленного у пользователя; это определяет способ позиционирования символов на экране. Более подробно об этом читайте в главах 24 и 21.

9.2. Системные вызовы

В этой книге практически повсеместно упоминаются системные вызовы, которые являются фундаментальными для программного окружения. На первый взгляд, они выглядят как обычные вызовы функций С. И это не случайно; они представляют собой специальную разновидность вызовов функций. Чтобы понять различия, нужно иметь общее представление о структуре операционной системы. Несмотря на то что операционная система Linux состоит из множества фрагментов кода (утилиты, библиотеки, приложения, программные библиотеки, драйверы устройств, файловые системы, управление памятью и так далее), все эти кодовые фрагменты работают в одном из двух контекстов: режиме пользователя или режиме ядра.

При разработку программы написанный код работает в режиме пользователя (user mode). Драйверы устройств и файловые системы, наоборот, работают в режиме ядра (kernel mode). В пользовательском режиме программы тщательно защищены от повреждений, вызванных их взаимодействием друг с другом или остальной частью системы. Код, работающий в режиме ядра, имеет полный доступ к компьютеру и может делать или же разрушать все, что угодно.

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

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

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

9.2.1. Ограничения системных вызовов

Режим ядра защищен от влияния режима пользователя. Одна из таких защит состоит в том, что тип данных, передаваемых между режимами ядра и пользователя, ограничен, легко верифицируется и следует строгим соглашениям.

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

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

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

9.2.2. Коды возврата системных вызов

Коды возврата, зарезервированные для всех системных вызовов — это универсальные коды возврата ошибок, представленные небольшими отрицательными числами. Библиотека С проверяет наличие ошибок каждый раз, когда происходит системный вызов. При возникновении ошибки библиотека помещает значение ошибки в глобальную переменную errno[15]. В большинстве случаев все, что вам необходимо при проверке ошибки — посмотреть, отрицательный ли код возврата. Коды ошибок определены в <errno.h>, и errno можно сравнить с любым номером ошибки из этого файла, после чего обработать ее специальным образом.

Переменная errno используется и в другом случае. Библиотека С предлагает три способа получения строк, предназначенных для описания возникшей ошибки.

perror()

Печатает сообщение об ошибке. Передайте в функцию строку с информацией о том, что код намеревался предпринять.

if ((file = open(DB_PATH, O_RDONLY)) < 0) {

 perror("не удается открыть файл базы данных");

}

Функция perror() выведет сообщение, описывающее возникшую ошибку, а также объяснение того, что код собирался делать:

не удается открыть файл базы данных: No such file or directory

Обычно неплохо делать свои аргументы для perror() уникальными на протяжении всей программы, в результате при получении сообщений об ошибках из perror() вы будете точно знать, откуда начинать поиск. Обратите внимание, что в строке, передаваемой perror(), нет символа новой строки. Его передавать не нужно — функция сама его выведет.

strerror()

Возвращает статически распределенную строку, описывающую ошибку с номером, передаваемым в единственном аргументе. Это можно использовать при построении, например, своей собственной версии perror().

if ((file = open(DB_PATH, O_RDONLY) ) < 0) {

 fprintf(stderr,

  "не удается открыть файл базы данных %s, %s\n",

  DB_PATH, strerror(errno));

}

sys_errlist

He очень хорошая альтернатива strerror(). sys_errlist — это массив размером sysnerr указателей на статические, доступные только для чтения символьные строки, которые описывают ошибки. Попытка записи в эти строки приводит к нарушению сегментации и сбросу дампа ядра.

if ((file = open(DB_PATH, O_RDONLY)) < 0) {

 if (errno < sys_nerr) {

  fprintf(stderr,

   "не удается открыть файл базы данных %s, %s\n",

   DB_PATH, sys_errlist[errno]);

 }

}

Этот массив не является ни стандартным, ни переносимым, и упоминается здесь лишь потому, что вы можете столкнуться с кодом, от него зависящим. Заменив такой код вызовом функции strerror(), вы получите существенный выигрыш.

Если вы не собираетесь использовать errno сразу же после генерации ошибки, сохраните ее копию. Любая библиотечная функция может установить errno в любое значение, поскольку в ней могут присутствовать системные вызовы, о которых вы даже не подозреваете. А некоторые библиотечные функции могут устанавливать errno даже без системных вызовов.

9.2.3. Использование системных вызовов

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

Большинство, но не все, системные вызовы объявлены в <unistd.h>. Фактически файл <unistd.h> представляет собой универсальное вместилище практически для всех системных вызовов. Чтобы определить, какие включаемые файлы нужно использовать, обычно нужно обратиться к системным man-страницам. Хотя описания функций на man-страницах зачастую весьма лаконичны, там можно найти точные указания о том, какой файл должен быть включен для использования функции.

Есть одна особенность, свойственная системам Unix. Системные вызовы документированы в отдельном разделе man-страниц для библиотечных функций, и вы будете использовать библиотечные функции для доступа к системным вызовам. Там, где библиотечные функции отличаются от системных вызовов, предусмотрены отдельные man- страницы. Это не вызывало бы проблем, однако практически всегда требуется читать страницу, описывающую библиотечную функцию, номер которой больше номера страницы с описанием соответствующего системного вызова. Ввиду того, что man-страницы выводятся, начиная с меньших номеров, приходится проделывать лишнюю работу.

Простого указания номера раздела недостаточно. Системные вызовы, которые помещены в минимальные функции-оболочки из библиотеки С, не документированы как часть библиотеки, следовательно команда man 3 функция не найдет их. Для того чтобы убедиться, что вы прочли всю необходимую для вас информацию, вначале взгляните на man-страницу, не указывая раздел. Если это раздел 2 на man-странице, посмотрите, есть ли там раздел 3 с таким же именем. Если открывается раздел 1 man-страницы, как это часто случается, внимательно просмотрите разделы 2 и 3.

К счастью, существует другой способ решения такой проблемы. Многие версии программы man, включая используемую в системах Linux, позволяют указывать альтернативный путь поиска man-страниц. Прочтите man-страницу о самой программе man, чтобы определить, поддерживается ли в вашей версии man переменная окружения MANSECT и аргумент -S. Если переменная поддерживается, можно установить MANSECT в что-нибудь вроде 3:2:1:4:5:6:7:8:tcl:n:l:p:о. Просмотрите в файле конфигурации man (в большинстве систем Linux это /etc/man.config) текущую настройку MANSECT.

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

if (ioctl(fd, FN, data)) {

 /* обработка ошибки на основе errno */

}

Часто встречается следующая форма:

if (ioctl(fd, FN, data) < 0) {

 /* обработка ошибки на основе errno */

}

Для системных вызовов, которые возвращают 0, обозначая успех, оба эти случая идентичны. В своем коде можете выбрать то, что вам больше подходит. Будьте готовы к тому, что столкнетесь с этими и другими способами обработки в чужих кодах.

9.2.4. Общие коды возврата ошибок

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

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

Для определения того, какую ошибку можно ожидать от определенного системного вызова, обращайтесь к соответствующим man-страницам. В частности, с помощью команды man 3 errno можно получить список кодов ошибок, определенных POSIX. Тем не менее, ситуация часто изменяется, и man-страницы не всегда отвечают существующему состоянию дел. Если системный вызов возвращает неожиданный код ошибки, можно предположить, что скорее man-страница устарела, а не системный вызов дал сбой. Исходный код Linux поддерживается более тщательно, чем документация.

E2BIG Список аргументов слишком длинный. При запуске нового процесса с помощью exec() существует ограничение на длину задаваемого списка аргументов. См. главу 10.
EACCESS В доступе будет отказано. Эта ошибка возвращается системным вызовом access(), рассматриваемым в главе 11, и представляет собой более информативный код возврата, чем само состояние ошибки.
EAGAIN Возвращается при попытке выполнения неблокируемого ввода-вывода, если нет доступных данных. EWOULDBLOCK является синонимом EAGAIN. При блокируемом вводе-выводе системный вызов установил бы блокировку и ожидал бы данных.
EBADF Неправильный номер файла. Был передан номер файла, не ссылающийся на открытый файл, в функцию read(), close(), ioctl() или другой системный вызов, принимающий номер файла в качестве аргумента.
EBUSY Системный вызов mount() возвращает эту ошибку при попытке смонтировать файловую систему, которая уже смонтирована, или размонтировать файловую систему, которая в настоящий момент используется.
ECHILD Дочерние процессы отсутствуют. Возвращается семейством системных вызовов wait(). См. главу 10.
EDOM Это ошибка не системного вызова, а ошибка из библиотеки С системы. EDOM устанавливается математическими функциями, если аргумент выходит за пределы допустимого диапазона. (Это EINVAL для области функции.) Например, функция sqrt() не работает с комплексными числами и потому не принимает отрицательные аргументы.
EEXIST Возвращается creat(), mknod() или mkdir(), если файл уже существует, или функцией open() в том же случае, если указаны флаги O_CREAT и O_EXCL.
EFAULT Неверный указатель (указывающий на недоступную область памяти) был передан в качестве аргумента системному вызову. Обращение по этому указателю из пользовательской программы, которая произвела системный вызов, приведет к ошибке сегментации.
EFBIG Возвращается write() при попытке записи файла, который длиннее, чем может логически обработать файловая система (физические ограничения пространства во внимание не принимаются).
EINTR Системный вызов был прерван. Прерываемые системные вызовы рассматриваются в главе 12.
EINVAL Возвращается, если системный вызов получил недопустимый аргумент.
EIO Ошибка ввода-вывода. Обычно генерируется драйвером устройства для обозначения ошибки в оборудовании или неисправимой ошибку взаимодействия с устройством.
EISDIR Возвращается системными вызовами, требующими имя файла, например unlink(), если последний компонент в имени пути является каталогом, а не файлом, а данная операция не может быть применена к каталогу.
ELOOP Возвращается системными вызовами, которые принимают путь, если при разборе пути встречается слишком много символических ссылок в строке (то есть символические ссылки, указывающие на символические ссылки, которые, в свою очередь, указывают на символические ссылки и так далее). Текущее ограничение — 16 символических ссылок на строку.
EMFILE Возвращается, если для вызываемого процесса нельзя открыть больше файлов.
EMLINK Возвращается link(), если в компонуемом файле уже содержится максимальное количество ссылок для файловой системы (в стандартной файловой системе Linux этот максимум составляет 32 000).
ENAMETOOLONG Имя пути слишком длинное либо для системы, либо для файловой системы, к которой вы пытаетесь получить доступ.
ENFILE Возвращается, если ни один процесс системы не может открыть больше ни одного файла.
ENODEV Возвращается mount(), если запрошенный тип файловой системы не доступен. Возвращается open() при попытке открыть специальный файл для устройства, для которого нет ассоциированного драйвера в ядре.
ENOENT Файл или каталог не существует. Возвращается при попытке получить доступ к несуществующему файлу или каталогу.
ENOEXEC Ошибка исполняемого формата. Может появиться при попытке запустить (устаревший) а.out в системе, в которой отсутствует поддержка бинарных файлов а.out. Может также встречаться при попытке запуска бинарного файла формата ELF, собранного для другой архитектуры центрального процессора.
ENOMEM Не хватает памяти. Возвращается функциями brk() и mmap() при неудачной попытке распределения памяти.
ENOSPC Возвращается write() при попытке записать файл длиннее, чем объем свободного пространства в файловой системе.
NOSYS Системный вызов не реализован. Обычно происходит при запуске нового исполняемого файла на старом ядре, которое не поддерживает системный вызов.
ENOTBLK Системный вызов mount() возвращает эту ошибку при попытке смонтировать в качестве файловой системы файл, не являющийся специальным файлом блочного устройства.
ENOTDIR Промежуточный компонент пути существует, но не является каталогом. Возвращается любым системным вызовом, принимающим имя файла.
ENOTEMPTY Возвращается rmdir(), если удаляемый каталог не пуст.
ENOTTY Обычно встречается, когда приложение, которое пытается обратиться к терминалу, запущено с перенаправлением ввода или вывода в канал. Но также может встречаться при попытке совершить операцию ввода-вывода на неправильном типе устройства. Стандартное сообщение об ошибке в этом случае, "not a typewriter", может сбить с толку.
ENXIO Нет такого устройства или адреса. Обычно генерируется при попытке открыть специальный файл устройства, который ассоциируется с частью не установленного или не настроенного оборудования.
EPERM У процесса недостаточно полномочий для завершения операции. Эта ошибка обычно встречается в файловых операциях. См. главу 11.
EPIPE Возвращается write(), если читающая сторона канала или сокета закрыта и захвачен или проигнорирован сигнал SIGPIPE. См. главу 12.
ERANGE Не являясь ошибкой системного вызова, ERANGE устанавливается математическими функциями, если результат невозможно представить возвращаемым типом. Эта ошибка может также возникать в других функциях, если им передается слишком короткий буфер для возвращаемой строки. (Для диапазона этой ошибке соответствует EINVAL.)
EROFS Возвращается write() при попытке записать в файловую систему, доступную только для чтения.
ESPIPE Возвращается lseek() при навигации по файлу, дескриптор которого не поддерживает навигацию (включая файловые дескрипторы для каналов, именованных каналов и сокетов). См. главы 11 и 17.
ESRCH Нет такого процесса. См. главу 10.
ETXTBSY Возвращается open() при попытке открыть на запись запущенный исполняемый файл или совместно используемую библиотеку или любой другой файл, отображенный на память с установленным флажком MAP_DENYWRITE (см. главу 13). Чтобы избежать такого поведения, необходимо переименовать файл, сделать новую копию с таким же именем, как у старого файла, и работать с этой новой копией. См. главу 11 с обсуждением того, почему так происходит.
EXDEV Возвращается link(), если исходные и целевые файлы находятся в разных файловых системах.

Распространены и некоторые другие коды возврата ошибок, которые относятся только к сетевым функциям. Более подробную информацию можно найти в главе 17.

9.3. Поиск заголовочных и библиотечных файлов

Заголовочные файлы в системе Linux хранятся в иерархии каталогов /usr/include. Именно там по умолчанию компилятор ищет включаемые файлы. (Заголовочные файлы могут храниться за пределами /usr/include, но тогда на них имеются ссылки внутри /usr/include. Например, на момент написания книги включаемые файлы системы X были расположены в /usr/X11R6/include/X11, но благодаря символической ссылке компилятор мог найти их через /usr/include/X11.)

С библиотеками дело обстоит практически так же, правда, с некоторыми нюансами. Библиотеки, которые считаются важными для загрузки системы (и ее отладки в случае необходимости), расположены в /lib. Другие системные библиотеки находятся в /usr/lib, кроме библиотек X11R6, которые хранятся в /usr/X11R6/lib. Компилятор по умолчанию будет искать стандартные системные библиотеки.

Некоторые библиотеки обеспечивают поддержку разработки в одной системе для нескольких основных своих версий. В большинстве случаев доступны специальные утилиты конфигурации, которые обеспечивают включение корректных версий заголовочных файлов и компоновку с подходящими версиями библиотек. Унифицированный инструмент под названием pkg-config обеспечивает эту информацию для каждой версии каждой библиотеки, разработанной для его поддержки.

Часть III Системное программирование

Глава 10 Модель процессов

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

10.1. Определение процесса

Что такое процесс? В исходной реализации Unix процессом была любая выполняющаяся программа. Для каждой программы ядро системы отслеживает перечисленные ниже аспекты.

• Текущая точка выполнения (такая как ожидание возврата системного вызова из ядра), часто называемая программным контекстом.

• К каким файлам имеет доступ программа.

• Сертификаты (credentials) программы (например, какой пользователь и группа владеют процессом).

• Текущий каталог программы.

• К какому пространству памяти имеет доступ программа и как оно распределено.

Процесс также является базовой единицей планирования для операционной системы. Только процессам разрешено выполняться в центральном процессоре.

10.1.1. Усложнение концепции — потоки

Хотя определение процесса может показаться очевидным, концепция потока (thread) делает все это несколько менее ясным. Поток позволяет единственной программе выполняться во многих местах одновременно. Все потоки, созданные одной программой, разделяют большинство характеристик, которые отличают процессы друг от друга. Например, множество потоков, порожденных от одной программы, разделяют информацию об открытых файлах, правах доступа, текущем каталоге и образе памяти. Как только один из потоков модифицирует глобальную переменную, все потоки увидят новое значение, а не только тот, что это сделал.

Многие реализации Unix (включая каноническую версию AT&T System V) были перепроектированы, чтобы сделать потоки фундаментальным элементом планирования для ядра, и процесс превратился в коллекцию потоков, разделяющих ресурсы. Поскольку множество ресурсов разделяется между потоками, ядро может быстрее переключаться между потоками одного процесса, чем оно это делает при полноконтекстном переключении между процессами. В результате в большинстве ядер Unix существует двухуровневая модель процессов, которая различает потоки и процессы.

10.1.2. Подход Linux

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

Под Linux процесс определен исключительно как планируемая сущность, и единственная вещь, которая уникальна для процесса — это текущий контекст выполнения. Он не предполагает ничего относительно разделенных ресурсов, потому что процесс, создающий новый дочерний процесс, имеет полный контроль над тем, какие из ресурсов процессы могут разделять между собой (см. детали в описании системного вызова clone() в конце этой главы). Эта модель позволяет сохранять традиционную систему управления процессами Unix, в то время как традиционный интерфейс потоков строится вне ядра.

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

10.2 Атрибуты процессов

10.2.1. Идентификатор процесса и происхождение

Два из наиболее фундаментальных атрибутов — это идентификатор процесса (process ID), или pid, а также идентификатор его родительского процесса. Идентификатор pid — это положительное целое число, которое уникально идентифицирует работающий процесс и сохраняется в переменной типа pid_t. Когда создается новый процесс, исходный процесс, известный как родитель нового процесса, будет уведомляться, когда этот дочерний процесс будет завершен.

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

Если родитель процесса завершается (делая дочерний процесс висячим), такой процесс становится дочерним для начального процесса (init). Начальный процесс — это первый процесс, который запускается при загрузке машины и которому присваивается значение pid, равное 1. Одной из основных задач начального процесса является сбор кодов завершения процессов, чьи родители исчезли, позволяя ядру удалять такие дочерние процессы из таблицы процессов системы. Процессы могут получать свой pid и pid родителя с помощью функций getpid() и getppid().

pid_t getpid(void) Возвращает pid текущего процесса.
pid_t getppid(void) Возвращает pid родительского процесса.

10.2.2. Сертификаты

В Linux используются традиционные механизмы обеспечения безопасности Unix для пользователей и групп. Идентификаторы пользователя (uid) и группы (gid) — это целые числа[16], которые отображаются на символические имена пользователей и групп в файлах /etc/passwd и /etc/group, соответственно (более подробную информацию о базах данных пользователей и групп можно получить в главе 28). Однако ядро ничего не знает об именах — оно имеет дело только с целочисленными представлениями. Идентификатор uid, равный 0, зарезервирован за системным администратором, обычно имеющим имя root. Все обычные проверки безопасности отключаются для процессов, запущенных от имени root (то есть с uid, равным 0), что дает администратору полный контроль над системой.

В большинстве случаев процесс имеет единственный uid и единственный gid, ассоциированный с ним. Это идентификаторы, которые используются для большинства целей обеспечения безопасности (как, например, назначение прав владения вновь созданным файлам). Системные вызовы, которые могут модифицировать принадлежность процессов, обсуждаются далее в настоящей главе.

Со времен разработки Unix ограничение процессов принадлежностью к одной группе создало новые трудности. Пользователи, работающие со многими проектами, должны явно переключать свой gid, когда им нужен доступ к файлам, доступ к которым ограничен определенной группой пользователей.

Дополнительные группы были представлены в BSD 4.3 для решения этой проблемы. Хотя каждый процесс по-прежнему имеет собственный первичный gid (который используется, например, как gid для вновь создаваемых файлов), он также связан с набором дополнительных групп. Проверки безопасности, которые используются для обеспечения того, что процесс относится к определенной группе (и только этой группе), теперь позволяет обеспечить доступ и в случае, когда данная группа является одной из дополнительных групп, к которым процесс относится. Макрос sysconf() по имени _SC_NGROUPS_МАХ специфицирует, к скольким дополнительным группам может относиться процесс. (Подробно о sysconf() см. главу 6.) В Linux 2.4 и более ранних версиях _SC_NGROUPS_MAX был равен 32. В Linux 2.6 и последующих версиях _SC_NGROUPS_MAX равен 65536. Не используйте статические массивы для хранения дополнительных групп. Вместо этого выделяйте память динамически, принимая во внимания значение, возвращаемое sysconf(_SC_NGROUPS_MAX). Старый код может пользоваться макросом NGROUPS_MAX для определения количества поддерживаемых групп, установленных в системе. Этот макрос не обеспечивает корректную работу, когда код компилируется в одной среде, а используется в другой.

Установка списка групп для процесса осуществляется системным вызовом setgroups() и может быть выполнена процессом, имеющим полномочия root.

int setgroups(size_t num, const gid_t * list);

Параметр list указывает на массив из num идентификаторов групп gid. Дополнительная группа процесса устанавливается этим списком идентификаторов групп, переданным в массиве list.

Функция getgroups() позволяет получить список дополнительных групп, установленных для процесса.

int getgroups(size_t num, gid_t * list);

list должен указывать на массив элементов типа gid_t, который наполняется идентификаторами дополнительной группы процесса, a num определяет, сколько элементов может типа gid_t содержать list. В случае ошибки системный вызов getgroups() возвращает -1 (обычно это происходит, когда list недостаточно велик, чтобы вместить дополнительный список групп процесса), или же количество дополнительных групп. В особом случае, когда num равно 0, getgroups() просто возвращает количество дополнительных групп процесса.

Ниже показан пример использования getgroups().

gid_t *groupList;

int numGroups;

numGroups = getgroups(0, groupList);

if (numGroups) {

 groupList = alloca(numGroups * sizeof(gid_t));

 getgroups(numGroups, groupList);

}

Более сложный пример getgroups() приведен в главе 28.

Таким образом, процесс имеет uid, первичный gid и набор дополнительных групп, ассоциированных с ним. К счастью, это все, о чем нужно знать большинству программистов. Существуют два класса программ, которым необходимо очень гибкое управление идентификаторами пользователей и групп — это программы setuid/setgid и системные демоны.

Системные демоны — это программы, которые всегда запущены в системе и выполняют определенные действия в ответ на внешние воздействия. Например, большинство демонов World Wide Web (http) функционируют всегда, ожидая подключения к ним клиента, чтобы обрабатывать клиентские запросы. Другие демоны, такие как cron (которые запускаются периодически), пребывают в спящем состоянии до тех пор, пока не наступает время, когда они должны выполнить какие-то действия. Большинство демонов должны быть запущены с полномочиями root, но выполняют действия по запросу пользователя, который может попытаться нарушить системную безопасность с помощью демонов.

ftp — хороший пример демона, который нуждается в гибком управлении uid. Изначально он запускается с правами root и затем переключает свой uid на uid пользователя, который подключился к нему (большинство систем запускают дополнительный процесс для обработки каждого ftp-запроса, поэтому такой подход работает достаточно хорошо). Это оставляет работу по проверке доступа к файлам ядру, к которому он относится. Однако в некоторых случаях демон ftp должен открывать сетевое подключение таким способом, который разрешен только root, поскольку пользовательские процессы не могут выдать сами себе административные полномочия (по вполне ясной причине), но сохранение идентификатора uid пользователя root вместо переключения на пользовательский uid должен потребовать от демона ftp самостоятельной проверки всего доступа к файловой системе. Решение этой дилеммы применяется симметрично — к обоим uid и первичным gid, поэтому мы и говорим здесь об uid.

В действительности процесс имеет три uid: реальный, сохраненный и эффективный uid[17]. Эффективный uid используется для всех проверок безопасности и является единственным uid процесса, который обычно имеет какой-то эффект.

Сохраненный и действительный идентификаторы uid проверяются только тогда, когда процесс пытается изменить его эффективный uid. Любой процесс может изменять свой эффективный uid на сохраненный или действительный. Только процессы с эффективным uid, равным 0 (процессы, запущенные от имени root), могут изменять свой эффективный uid на произвольное значение.

Обычно эффективный, реальный и действительный uid процесса совпадают. Однако этот механизм решает дилемму демона ftp. Когда он запускается, все его идентификаторы устанавливаются в 0, что предоставляет ему полномочия root. Когда подключается пользователь, демон устанавливает свой эффективный uid равным uid пользователя, оставляя сохраненный и действительный uid равными 0. Когда демону ftp требуется выполнить действие, разрешенное только root, он устанавливает свой эффективный uid в 0, выполняет действие, а затем переустанавливает эффективный uid в значение uid подключенного пользователя.

Хотя демон ftp вообще не нуждается в сохраненном uid, другие классы программ, применяющие этот механизм — двоичные модули setuid и setgid — используют его.

Программа passwd — это простой пример того, зачем нужна функциональность setuid и setgid. Программа passwd позволяет пользователям изменять свои пароли. Пользовательские пароли обычно хранятся в файле /etc/passwd. Выполнять запись в этот файл может только пользователь root, что предотвращает изменение информации о пользователях другими пользователями. Но пользователи должны иметь возможность изменять свои собственные пароли, поэтому необходим какой-то способ предоставить программе passwd права на изменение /etc/passwd.

Чтобы обеспечить эту гибкость, пользователь программы может устанавливать специальные биты в группе бит прав доступа этой программы (см. главу 11). Это сообщает ядру, что всякий раз, когда программа запускается, она должна выполняться с тем же эффективным uid (или gid), как у пользователя, который владеет файлом программы, независимо от того, какой пользователь запустил программу. Такие программы называются setuid- или setgid-программами.

Принадлежность программы passwd пользователю root и установка бита setuid в наборе битов доступа программы позволяют всем пользователям изменять свои пароли. Когда пользователь запускает passwd, эта программа выполняется с эффективным идентификатором пользователя 0, что позволяет ей модифицировать /etc/passwd и изменять пользовательский пароль. Конечно, passwd должна быть реализована очень тщательно, дабы исключить побочные эффекты. Программы setuid — это популярная цель для злоумышленников, проникающих в систему, поэтому плохо написанная программа подобного рода дает простую возможность получить неавторизованный доступ.

Существуют много случаев, когда программы setuid требуют специальных прав доступа на короткий период времени и должны переключаться на uid действительного пользователя в остальное время (как это делает демон ftp). Программы setuid имеют установленный эффективный uid равным uid ее владельца, но они также "знают" uid того пользователя, который их запустил (сохраненный uid), что упрощает обратное переключение. В дополнение они могут устанавливать свой действительный uid в значение setuid (не затрагивая сохраненный uid), при необходимости повторно получая эти специальные полномочия. В этой ситуации эффективный, сохраненный и действительный идентификаторы пользователя работают вместе, насколько возможно, упрощая систему безопасности.

К несчастью, применение этого механизма может сбивать с толку, поскольку в POSIX и BSD применяются слегка отличающиеся подходы, a Linux поддерживает оба. Решение BSD более полнофункционально, чем метод POSIX. Оно использует функцию setreuid().

int setreuid(uid_t ruid, uid_t euid);

Действительный uid процесса устанавливается в ruid, а эффективный — в euid. Если любой из параметров равен -1, идентификатор вызовом не затрагивается.

Если эффективный uid процесса равен 0, такой вызов всегда выполняется успешно. В противном случае идентификаторы могут быть установлены равными либо сохраненному uid, либо реальному uid процесса. Следует отметить, что этот вызов никогда не изменяет сохраненный uid или реальный uid текущего процесса. Чтобы сделать это, используйте функцию POSIX setuid(), которая может модифицировать сохраненный uid.

int setuid(uid_t euid);

Как и в случае setreuid() эффективный uid процесса устанавливается в euid, если euid равен действительному uid процесса либо эффективный uid процесса на момент вызова равен 0.

Когда setuid() используется процессом, чей эффективный uid установлен в 0, все uid процесса изменяются на euid. К сожалению, это делает невозможным использование setreuid() в setuid-программах, которым нужно временное использование другого uid, поскольку после вызова setreuid() процесс не может восстановить свои полномочия root.

Хотя способность переключать uid упрощает написание кода, с помощью которого нельзя нарушить безопасность системы, все же это не панацея. Существует очень много популярных методов обманного проникновения в выполняющийся код [18]. До тех пор пока либо сохраненный, либо действительный uid процесса равен 0, такие атаки легко могут устанавливать эффективный uid процесса в 0. Это не дает возможности переключению uid эффективно предотвращать серьезную уязвимость системных программ. Однако если процесс может передать любой доступ к полномочиям root, устанавливая эффективный, сохраненный и действительный идентификаторы в ненулевые значения, это ограничивает эффективность любых атак против него.

10.2.3. Идентификатор uid файловой системы

В очень специальных случаях программе может понадобиться сохранять свои права root для всего, кроме доступа к файловой системе, при котором она использует пользовательский uid. Изначально использовавшийся в Linux NFS-сервер пространства пользователя может служить иллюстрацией проблемы, которая возникает, когда процесс предполагает применение пользовательского uid. Хотя NFS-сервер в прошлом применял setreuid() для переключения uid при доступе к файловой системе, такое поведение позволяло пользователю, чей uid совпадает с uid NFS-сервера, уничтожать NFS-сервер. В конечном итоге, пользователь получал владение процессом NFS-сервера. Чтобы предотвратить проблемы подобного рода, Linux использует uid файловой системы (fsuid) для контроля доступа к файловой системе.

Всякий раз когда изменяется эффективный uid процесса, его fsuid устанавливается равным новому эффективному идентификатору пользователя, что делает fsuid прозрачным для большинства приложений. Те приложения, которые нуждаются в дополнительных возможностях, предоставляемых отличающимся значением fsuid, должны применять вызов setfsuid() для явной установки fsuid.

int setfsuid(uid_t uid);

Значение fsuid может быть установлено равным текущим эффективному, сохраненному или действительному идентификаторам пользователя. В дополнение следует сказать, что setfsuid() выполняется успешно, если fsuid остается неизменным или эффективный uid процесса равен 0.

10.2.4. Резюме по идентификаторам пользователей и групп

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

Все эти функции возвращают -1 в случае ошибки и 0 — в случае успеха, если только не указано иначе. Большинство их прототипов находятся в <unistd.h>. Те, что расположены где-то еще, отмечены ниже.

int setreuid(uid_t ruid, uid_t euid); Устанавливает действительный uid текущего процесса в ruid и эффективный uid процесса в euid. Если оба параметра равны -1, то uid остаются неизменными.
int setregid(gid_t rgid, gid_t egid); Устанавливает действительный gid текущего процесса в rgid и эффективный gid процесса в egid. Если оба параметра равны -1, то gid остаются неизменными.
int setuid(uid t uid); Если применяется обычным пользователем, то устанавливает эффективный uid текущего процесса в значение параметра uid. Если используется процессом с эффективным uid, равным 0, то устанавливает действительный, эффективный и сохраненный uid в значение параметра uid.
int setgid(gid_t gid); Если применяется обычным пользователем, то устанавливает эффективный gid текущего процесса в значение параметра gid. Если используется процессом с эффективным gid, равным 0, то устанавливает действительный, эффективный и сохраненный gid в значение параметра gid.
int seteuid(uid_t uid); Эквивалент setreuid(-1, uid).
int setegid(gid_t gid); Эквивалент setregid(-1, gid).
int setfsuid(uid_t fsuid); Устанавливает fsuid текущего процесса в значение параметра fsuid. Прототип находится в <sys/fsuid.h>. Возвращает предшествующий fsuid.
int setfsgid(gid_t fsgid); Устанавливает fsgid текущего процесса в значение параметра fsgid. Прототип находится в <sys/fsuid.h>. Возвращает предшествующий fsgid.
int setgroups(size_t num, const gid_t * list); Устанавливает дополнительные группы текущего процесса из списка, переданного в массиве list, который должен содержать num элементов. Макрос SC_NGROUPS_MAX указывает, сколько групп может быть в списке (от 32 до 65536, в зависимости от работающей у вас версии Linux).
uid_t getuid(); Возвращает действительный uid процесса.
uid_t geteuid(); Возвращает эффективный uid процесса.
gid_t getgid(); Возвращает действительный gid процесса.
gid_t getegid(); Возвращает эффективный gid процесса.
size_t getgroups (size_t size, gid_t list[]); Возвращает текущий набор дополнительных групп процесса в массиве list. Параметр size сообщает, сколько элементов типа gid_t может содержать list. Если размер list недостаточен, чтобы вместить все группы, возвращается -1, а errno устанавливается в EINVAL. В противном случае возвращается фактическое количество групп в list. Если size равен 0, возвращается количество групп, но list не затрагивается. Прототип функции getgroups() находится в <grp.h>.

10.3. Информация о процессе

Ядро предоставляет значительное количество информации о каждом процессе и часть ее передается новым программам во время их загрузки. Вся эта информация образует среду выполнения для процесса.

10.3.1. Аргументы программы

Есть два типа значений, передаваемых новым программам при их запуске: аргументы командной строки и переменные окружения. Для их использования установлено множество соглашений, но система сама по себе не придерживается их автоматически. Однако хорошим тоном считается придерживаться этих соглашений, чтобы помочь вашим программам попасть в мир Unix.

Аргументы командной строки — это набор строк, передаваемый программе. Обычно они представляют собой текст, набранный вслед за именем команды в оболочке, с необязательными аргументами, начинающимися с символа "минус" (-).

Переменные окружения — это набор пар "имя-значение". Каждая пара представляет отдельную строку в форме ИМЯ=ЗНАЧЕНИЕ, и набор таких строк образует окружение (environment) программы. Например, домашний каталог текущего пользователя обычно указан в переменной окружения HOME, поэтому программы, скажем, пользователя Joe часто запускаются, имея в своем окружении HOME=/home/joe.

И аргументы, и окружение становятся доступными программе при запуске. Аргументы командной строки передаются в виде параметров главной функции программы — main(), в то время как указатель на окружение помещается в глобальную переменную environ, которая определена в <unistd.h>[18].

Ниже представлен полный прототип функции main() в мире Linux, Unix и языка ANSI/ISO С.

int main(int argc, char *argv[]);

Возможно, вас удивит, что main() возвращает значение (отличное от void). Это значение, возвращаемое функцией main(), передается родительскому процессу после завершения данного. По соглашению 0 означает, что процесс завершен успешно, а ненулевое значение означает возникновение сбоя. При этом принимаются во внимание только младшие 8 бит из этого кода возврата. Отрицательные значения от -1 до -128 зарезервированы для ненормального завершения процессов по инициативе другого процесса или ядра системы. Код выхода 0 сигнализирует об успешном завершении, а значения от 1 до 127 говорят о том, что программа завершена по ошибке.

Первый параметр, argc, содержит количество аргументов командной строки, переданных программе, тогда как argv — массив указателей на строки — хранит сами аргументы. Первый элемент в массиве, argv[0], содержит имя вызванной программы (хотя и не обязательно полный путь к ней). В элементе argv[argc-1] расположен указатель на завершающий аргумент командной строки, а argv[argc] содержит NULL.

Чтобы получить прямой доступ к окружению, используйте следующую глобальную переменную:

extern char *environ[];

Это представляет environ как массив указателей на каждый элемент программного окружения (помните, каждый элемент — это пара ИМЯ=ЗНАЧЕНИЕ), и финальный элемент массива содержит NULL. Это объявление находится в <unistd.h>, поэтому вам не обязательно объявлять его самостоятельно.

Наиболее общий способ проверки элементов окружения — это вызов getenv, который исключает непосредственное обращение к переменной environ.

const char *getenv(const char * name);

Единственный параметр getenv() — это имя переменной окружения, значение которой интересует. Если переменная существует, getenv() вернет указатель на ее значение. Если переменная не существует в текущем окружении (то есть окружении, на которое указывает environ), функция вернет NULL.

Linux предоставляет два способа добавления строк в программное окружение: setenv() и putenv(). POSIX определяет только putenv(), что делает его более переносимым.

int putenv(const char * string);

Переданный функции параметр string должен иметь форму ИМЯ=ЗНАЧЕНИЕ. putenv() добавляет переменную по имени ИМЯ к текущему окружению и присваивает ей значение ЗНАЧЕНИЕ. Если окружение уже содержит переменную ИМЯ, ее значение изменяется на ЗНАЧЕНИЕ.

BSD определяет функцию setenv(), которую Linux также поддерживает. Это более гибкий и удобный способ добавления переменных к окружению.

int setenv(const char * name, const char * value, int overwrite);

Здесь имя и новое значение переменной окружения передаются раздельно, что обычно программам делать проще. Если overwrite равно 0, окружение не модифицируется, если оно уже содержит переменную по имени name. В противном случае значение переменной модифицируется, как и в putenv().

Ниже приведен короткий пример использования обеих функций. Оба вызова делают одно и то же, заменяя переменную окружения PATH для запущенной программы.

putenv("PATH=/bin:/usr/bin");

setenv("PATH","/bin:/usr/bin", 1);

10.3.2 Использование ресурсов

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


Таблица 10.1. Ресурсы процессов, отслеживаемые Linux

Тип Член Описание
struct timeval ru_utime Общее время, затраченное на выполнение кода в режиме пользователя. Это включает в себя все время, потраченное на выполнение инструкций приложения, но исключая время, потраченное ядром на обслуживание запросов приложения.
struct timeval ru_stime Общее время, потраченное ядром на выполнение запросов процесса. Это не включает времени блокировки процесса в период ожидания выполнения системных вызовов.
long ru_minflt Количество второстепенных сбоев (minor faults), вызванных данным процессом. Второстепенные сбои — это попытки доступа к памяти, переключающие процессор в режим ядра, но не вызывающих обращений к диску. Это случается, когда процесс пытается писать за пределами стека, что вынуждает ядро распределить больше пространства стека, прежде чем продолжить выполнение процесса.
long ru_majflt Количество первостепенных сбоев (major faults), вызванных данным процессом. Первостепенные сбои — это обращения к памяти, заставляющие ядро обратиться к диску, прежде чем программа сможет продолжить работу. Одной из частых причин этого может быть обращение к части исполняемой памяти, которая еще не была загружена в ОЗУ с диска либо была временно выгружена на диск.
long ru_nswap Количество страниц памяти, для которых был выполнен обмен с диском при обращении к памяти из процесса.

Процесс может проверять использование ресурсов им самим, общее использование ресурсов его дочерними процессами либо сумму того и другого.

Системный вызов getrusage() возвращает структуру struct rusage (определенную в <sys/resource.h>), содержащую информацию о текущем использовании ресурсов.

int getrusage(int who, struct rusage * usage);

Первый параметр, who, сообщает, какой из трех счетчиков ресурсов должен быть возвращен. RUSAGE_SELF возвращает использование ресурсов текущим процессом, RUSAGE_CHILDREN — его дочерними процессами, a RUSAGE_BOTH — общее использование ресурсов текущим процессом и всеми его дочерними процессами. Второй параметр getrusage() — это указатель на struct rusage, куда помещается информация об использовании ресурсов. Хотя struct rusage и содержит относительно немного членов (список унаследован из BSD), большинство этих членов пока не используются Linux). Ниже представлено полное определение этой структуры. В табл. 10.1 описаны члены, используемые в настоящее время Linux.

#include <sys/resource.h>


struct rusage {

 struct timeval ru_utime;

 struct timeval ru_stime;

 long intru_maxrss;

 long intru_ixrss;

 long intru_idrss;

 long intru_isrss;

 long intru_minflt;

 long intru_majfit;

 long intru_nswap;

 long intru_inblock;

 long intru_oublock;

 long intru_msgsnd;

 long intru_msgrcv;

 long intru_nsignals;

 long intru_nvcsw;

 long intru_nivcsw;

};

10.3.3. Применение ограничений использования ресурсов

Чтобы помочь в предотвращении неконтролируемого снижения производительности процессами, Unix отслеживает многие ресурсы, которые может использовать процесс, и позволяет системному администратору и самим пользователям накладывать ограничения на расход ресурсов процессами.

Предусмотрены два класса доступных ограничений: жесткие и мягкие ограничения. Жесткие обычно установлены при запуске системы в RLIM_INFINITY, что означает отсутствие каких-либо ограничений. Единственное исключение из этого — RLIMIT_CORE (максимальный размер дампа памяти), который Linux инициирует нулем, чтобы предотвратить неожиданный сброс дампов ядра. Многие дистрибутивы сбрасывают этот лимит при запуске, однако, большинство технических пользователей ожидают появления дампов памяти при некоторых условиях (информацию о дампах памяти можно найти далее в главе). Мягкие ограничения — это те ограничения, которые установлены в ядре в данный момент. Любой процесс может наложить мягкое ограничение на использование ресурса на определенном уровне — равном или более низком, чем установленное жесткое ограничение.


Таблица 10.2. Ограничения ресурсов

Значение Лимит
RLIMIT_AS Максимальный объем памяти, доступный процессу. Включает память для стека, глобальных переменных и динамически выделенную память.
RLIMIT_CORE Максимальный размер дампа памяти, генерируемого ядром (если файл дампа получается слишком большим, он не создается).
RLIMIT_CPU Общее используемое время процессора (в секундах). Более подробно об этом ограничении рассказывается при описании SIGXCPU в главе 12.
RLIMIT_DATA Максимальный объем памяти данных (в байтах). Это не включает динамически выделенную память.
RLIMIT_FSIZE Максимальный размер открытого файла (проверяется при записи). Более подробно об этом ограничении рассказывается при описании SIGXFSZ в главе 12.
RLIMIT_MEMLOCK Максимальный объем памяти, которая может быть блокирована с помощью mlock(). Функция mlock() рассматривается в главе 13.
RLIMIT_NOFILE Максимальное количество открытых файлов.
RLIMIT_NPROC Максимальное количество дочерних процессов, которые может породить данный процесс. Это ограничивает только количество дочерних процессов, которые могут существовать одновременно. Это не ограничивает количества наследников дочерних процессов — каждый из них может иметь до RLIMIT_NPROC потомков.
RLIMIT_RSS Максимальный объем ОЗУ, использованный в любой момент (всякое превышение этого объема используемой памяти вызывает страничную подкачку). Это также известно под названием размера резидентной части (resident set size).
RLIMIT_STACK Максимальный размер памяти стека (в байтах), включая все локальные переменные.

Различные ограничения, которые могут быть установлены, перечислены в табл. 10.2 и определены в <sys/resource.h>. Системные вызовы getrlimit() и setrlimit() устанавливают и получают ограничения для отдельного ресурса.

int getrlimit(int resource, struct rlimit *rlim);

int setrlimit(int resource, const struct rlimit *rlim);

Обе эти функции используют структуру struct rlimit, определенную следующим образом:

struct rlimit {

 long int rlim_cur; /* мягкое ограничение */

 long int rlim_max; /* жесткое ограничение */

};

Второй член структуры — rlim_max, указывает жесткое ограничение лимита, переданного в параметре resource, a rlim_cur — мягкое ограничение. Это те же наборы лимитов, которыми манипулируют команды ulimit и limit, одна из которых встроена в большинство командных оболочек.

10.4. Примитивы процессов

Несмотря на относительно длинную дискуссию, необходимую для описания процесса, создание и уничтожение процессов в Linux достаточно просто.

10.4.1. Создание дочерних процессов

В Linux предусмотрены два системных вызова, которые создают новые процессы: fork() и clone(). Как упоминалось ранее, clone() используется для создания потоков, и этот вызов будет кратко описан далее. А сейчас мы сосредоточимся на fork() — наиболее популярном методе создания процессов.

#include <unistd.h>


pid_t fork(void);

Этот системный вызов имеет уникальное свойство возвращать управление не один раз, а дважды: один раз в родительском процессе и другой — в дочернем. Обратите внимание, что мы не говорим "первый — в родительском" — написание кода, который делает какие-то предположения относительно предопределенного порядка — очень плохая идея.

Каждый из двух возвратов системного вызова fork() имеет разные значения. В родительский процесс этот системный вызов возвращает pid вновь созданного дочернего процесса, а в дочернем он возвращает 0.

Разница возвращаемых значений — это единственное отличие, видимое процессам. Оба имеют одинаковые образы памяти, права доступа, открытые файлы и обработчики сигналов[19]. Рассмотрим простой пример программы, порождающей дочерний процесс.

#include <sys/types.h>

#include <stdio.h>

#include <unistd.h>


int main(void) {

 pid_t child;

 if (!(child = fork())) {

  printf("в дочернем\n");

  exit (0);

 }

 printf("в родительском - дочерний: %d\n", child);

 return 0;

}

10.4.2. Наблюдение за уничтожением дочерних процессов

Сбор состояний возврата дочернего процесса называется ожиданием процесса. Это можно делать четырьмя способами, хотя только один из вызовов предоставляется ядром. Остальные три метода реализованы в стандартной библиотеке С. Поскольку системный вызов ядра принимает четыре аргумента, он называется wait4().

pid_t wait4(pid_t pid, int *status, int options, struct rusage *rusage);

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

pid < -1 Ожидать завершения любого дочернего процесса, чей pgid равен абсолютному значению pid.

pid = -1 Ожидать прерывания любого дочернего процесса.

pid = 0 Ожидать завершения дочернего из той же группы процессов, что и текущий[20].

pid > 0 Ожидать выхода процесса pid.

Второй параметр — это указатель на целое, которое устанавливается в значение, равное соду возврата того процесса, который заставляет wait4() вернуть управление (мы будем зазывать его "проверяемым" процессом). Формат возвращенного состояния довольно закрученный, и для того, чтобы сделать его осмысленным, существует набор макросов.

Три события заставляют wait4() вернуть состояние проверяемого процесса. Процесс может завершиться, он может быть прерван вызовом kill() (получит фатальный сигнал) либо он может быть остановлен по какой-либо причине[21]. Вы можете узнать, что именно случилось, с помощью описанных ниже макросов, каждый из которых принимает возвращаемое состояние wait4() в качестве единственного параметра.

WIFEXITED(status) Возвращает true, если процесс завершился нормально. Процесс завершается нормально, когда его функция main() выходит из программы посредством вызова exit(). Если WIFEXITED истинно, то WEXITSTATUS(status) возвращает код возврата процесса.
WIFSIGNALED(status) Возвращает true, если процесс был прерван сигналом (это происходит, когда он прерывается вызовом kill()). В этом случае WTERMSIG(status) возвращает номер сигнала, прервавшего процесс.
WIFSTOPPED(status) Если процесс приостановлен сигналом, WIFSTOPPED() возвращает true, a WSTOPSIG(status) возвращает номер сигнала, приостановившего процесс. wait4() возвращает информацию только о приостановленных процессах, если указана опция WUNTRACED.

Аргумент options управляет поведением вызова. WHOHANG заставляет функцию немедленно вернуть управление. Если в данный момент нет ни одного процесса, готового сообщить свое состояние, то возвращается 0 вместо допустимого pid. WUNTRACED заставляет wait4() возвратить соответствующий остановленный дочерний процесс. Более подробно о приостановленных процессах рассказывается в главе 15. Оба флажка могут быть объединены вместе битовой операцией "или".

Финальный параметр wait4(), указатель на struct rusage, наполняется информацией об использовании ресурсов проверяемым процессом и всеми его потомками. Более подробная информация об этом давалась при обсуждении getrusage() и RUSAGE_BOTH ранее в главе. Если этот параметр равен NULL, информация о состоянии не возвращается.

Существуют три других интерфейса к wait4(), каждый из которых представляет подмножество его функциональности.

pid_t wait(int *status) Единственный параметр wait() — это указатель на место, куда следует поместить код возврата прерванного процесса. Эта функция всегда блокирует выполнение до тех пор, пока дочерний процесс не будет прерван.
pid_t waitpid (pid_t pid, int *status, int options) Функция waitpid() подобна wait4(). Единственное отличие в том, что она не возвращает информации об использовании ресурсов прерванным процессом.
pid_t wait3(int *status, int options, struct rusage *rusage) Эта функция также подобна wait4(), но не позволяет специфицировать дочерний процесс, который должен быть проверен.

10.4.3. Запуск новых программ

Хотя доступно целых шесть способов запустить одну программу из другой, все они делают почти одно и то же — заменяют текущую выполняющуюся программу другой программой. Обратите внимание на слово "заменяет" — все следы текущей выполняющейся программы при этом исчезают. Если вы хотите оставить исходную программу работающей, вы должны создать новый процесс вызовом fork(), а затем запустить новую программу из дочернего процесса.

Эти шесть функций лишь слегка отличаются по интерфейсу. Только одна из них — execve() — является системным вызовом Linux. Остальные реализованы в библиотеках пользовательского пространства и вызывают execve() для запуска новой программы. Ниже представлены прототипы семейства функций exec().

int execl(const char *path, const char *arg0, ...);

int execlp(const char *file, const char *arg0, ...);

int execle(const char *path, const char *arg0, ...);

int execv(const char *path, const char **argv);

int execvp(const char *file, const char **argv);

int execve(const char *file, const char **argv, const char **envp);

Как уже упоминалось, все эти программы пытаются заменить текущую программу новой. Если это удается, то управление не возвращается (то есть программа, которая вызвала другую программу, уже не выполняется). Если не удается, то возвращается значение -1 и устанавливается код ошибки в errno, как при любом другом системном вызове. Когда новая программа запускается, она принимает массив аргументов (argv) и массив переменных окружения (envp). Каждый элемент envp имеет форму ПЕРЕМЕННАЯ=значение[22].

Основная разница между функциями семейства exec() состоит в том, как новой программе передаются аргументы командной строки. Функции execl() передают каждый элемент в отдельном аргументе argv, причем список завершается NULL. Традиционно первый элемент argv — это команда, использованная для запуска программы. Например, команда оболочки /bin/cat /etc/passwd /etc/group обычно получается в результате следующей вызова exec:

execl("/bin/cat", "/bin/cat", "/etc/passwd", "/etc/group", NULL);

Первый аргумент — это полный путь к программе, которую требуется выполнить, а остальные аргументы передаются программе в виде argv. Заключительный параметр execl() должен быть равен NULL — это служит признаком конца списка параметров. Если вы пропустите NULL, то, скорее всего, функция завершится ошибкой сегментации либо вернет EINVAL. Окружение, переданное новой программе — это то, на что указывает глобальная переменная environ, как упоминалось ранее в настоящей главе.

Функциям execv аргументы командной строки передаются как массив С строк[23], имеющих тот же формат, что применяется для передачи argv новой программе.

Последним элементом должен быть NULL для обозначения конца массива, а первый элемент (argv[0]) должен содержать имя вызываемой программы.

Наш пример с bin/cat /etc/passwd /etc/group может быть закодирован, используя execv, следующим образом:

char *argv[] = { "/bin/cat", "/bin/cat", "/etc/passwd", "/etc/group", NULL }; execv("/bin/cat", argv);

Если нужно передать специфическое окружение новой программе, для этого подойдут execle() и execve(). Они в точности похожи на execl() и execv(), но принимают указатель на окружение в качестве последнего аргумента. Окружение устанавливается так же, как argv.

Например, ниже показан один способ запуска /usr/bin/env (эта программа печатает окружение, которое ей передано) с небольшим набором переменных окружения:

char *newenv[] = { "PATH=/bin:/usr/bin", "HOME=/home/sweethome", NULL };

execle("/usr/bin/env", "/usr/bin/env", NULL, newenv);

Вот та же идея, реализованная с помощью execve():

char *argv[] = { "/usr/bin/env", NULL };

char *newenv[] = { "PATH=/bin:/usr/bin", "HOME=/home/sweethome", NULL };

execve("/usr/bin/env", argv, newenv);

Последние две функции, execlp() и execvp(), отличаются от первых двух тем, что выполняют поиск программы, которую нужно запустить, в текущем пути (установленном переменной окружения PATH). Аргументы программы, однако, не модифицируются, поэтому argv[0] не содержит полного пути к запускаемой программе. Ниже показана модифицированная версия нашего первого примера, который ищет cat в текущем PATH.

execlp("cat", "cat", "/etc/passwd", "/etc/group", NULL);

char *argv[] = { "cat", "/etc/passwd", "/etc/group", NULL };

execvp("cat", argv);

Если вместо этого воспользоваться execl() или execv(), этот фрагмент кода завершится ошибкой, если только cat не окажется в текущем каталоге.

Если вы пытаетесь запустить программу со специфическим окружением, при этом желая выполнять поиск пути, вам придется искать путь вручную и использовать execle() или execve(), поскольку ни одна из функций exec() не делает того, что вам нужно.

Обработчики сигналов предохраняются внутри функций exec() несколько неочевидным образом. Этот механизм рассматривается в главе 12.

10.4.4. Ускоренное создание процессов с помощью vfork()

Обычно процессы, в которых вызывается fork(), немедленно вызывают exec() для другой программы (это то, что оболочка делает всякий раз, когда вы вводите команду), что делает полную семантику fork() более расточительной по вычислительным ресурсам, чем это необходимо.

Чтобы оптимизировать этот общий случай, существует vfork().

#include <unistd.h>


pid_t vfork(void);

Вместо создания совершенно новой среды выполнения для нового процесса vfork() создает новый процесс, который разделяет память с исходным процессом. Ожидается, что новый процесс запустит другой процесс посредством exit() или exec() очень быстро, но его поведение непредсказуемо, если он модифицирует память, возвратит управление из функции vfork(), содержащейся в нем, либо вызовет любую новую функцию. В дополнение к этому исходный процесс приостанавливается, до тех пор, пока новый либо не будет прерван, либо вызовет функцию exec()[24]. Однако не все системы обеспечивают семантику разделения памяти и приостановки родительского процесса vfork(), поэтому приложения не должны полагаться на такое поведение.

10.4.5. Уничтожение процессом самого себя

Процессы прерывают себя вызовом либо exit(), либо _exit(). Когда функция процесса main() возвращает управление, стандартная библиотека С вызывает exit() со значением, возвращаемым main() в качестве параметра.

void exit(int exitCode);

void _exit(int exitCode);

Две формы, exit() и _exit(), отличаются тем, что exit() — функция из библиотеки С, a _exit() — системный вызов. Системный вызов _exit() прерывает программу немедленно, и exitCode сохраняется в качестве кода возврата процесса. Когда используется exit(), то перед тем, как запустить системный вызов _exit(exitCode), вызываются функции, зарегистрированные в atexit(). Помимо всего прочего, это позволяет стандартной библиотеке ввода-вывода ANSI/ISO сбросить все свои буферы.

Регистрация функций, которые должны быть запущены при вызове exit(), выполняется с помощью функции atexit():

int atexit(void (*function) (void));

Единственный параметр, переданный atexit() — это указатель на функцию. Когда вызывается exit(), все функции, зарегистрированные через atexit(), вызываются в порядке, обратном тому, в котором они регистрировались. Следует отметить, что если используется _exit() либо процесс прерывается сигналом (подробно о сигналах читайте в главе 12), то функции, зарегистрированные atexit(), не вызываются.

10.4.6. Уничтожение других процессов

Разрушение другого процесса почти столь же просто, как создание нового — нужно просто уничтожить его:

int kill(pid_t pid, int signum);

pid должен быть идентификатором процесса, который требуется уничтожить, а signum описывает, как это нужно сделать. Доступны два варианта выполнения операции[25] прерывания дочернего процесса. Вы можете применить SIGTERM, чтобы прервать его "вежливо". Это означает, что процесс при этом может сообщить ядру о том, что кто-то пытается его уничтожить; в результате появляется возможность завершить его корректно (сохранив файлы, например). Процесс может в этом случае игнорировать запрос на прерывание такого типа и продолжать выполняться. Применение значения SIGKILL в качестве параметра signum вызывает немедленное прерывание процесса без каких-либо вопросов. Если signum равно 0, то kill() проверяет, имеет ли тот процесс, что вызвал kill(), соответствующие полномочия, возвращает ноль, если это так, либо ненулевое значение, если полномочий недостаточно. Это обеспечивает процессу возможность проверки корректности pid.

Параметр pid в среде Linux может принимать перечисленные ниже значения.

pid > 0 Сигнал отправляется процессу с идентификатором pid. Если такого процесса нет, возвращается ESRCH.
pid < -1 Сигнал посылается всем процессам, принадлежащим группе с pgid, равным -pid. Например, kill(-5316, SIGKILL) немедленно прерывает все процессы из группы 5316. Такая возможность используется оболочками управления заданиями, как описано в главе 15.
pid = 0 Сигнал отправляется всем процессам группы, к которой относится текущий процесс.
pid = -1 Сигнал посылается всем процессам системы за исключением инициализирующего процесса (init). Это применяется для полного завершения системы.

Процессы могут нормально уничтожать вызовом kill() только те процессы, которые разделяют тот же эффективный идентификатор пользователя, что и у них самих. Существуют два исключения из этого правила. Во-первых, процессы с эффективным uid, равным 0, могут уничтожать любые процессы в системе. Во-вторых, любой процесс может посылать сигнал SIGCONT любому процессу в том же сеансе[26].

10.4.7. Дамп ядра

Хотя мы уже упоминали, что передача SIGTERM и SIGKILL функции kill() прерывает процесс, вы также можете использовать несколько других значений (все они описаны в главе 12). Некоторые из них, такие как SIGABRT, заставляют программу перед уничтожением сбрасывать дамп ядра (dump core).

Дамп ядра программы содержит полную хронологию состояния программы перед ее уничтожением[27]. Большинство отладчиков, включая gdb, могут анализировать файл дампа и рассказывать, что программа делала непосредственно перед тем, как была уничтожена, а также поможет исследовать образ памяти процесса. Дамп ядра выгружается в файл по имени core, расположенный в текущем каталоге процесса.

Когда процесс нарушает какие-то системные требования (например, пытается обратиться к памяти, доступ к которой запрещен), ядро прерывает процесс, вызывая встроенную версию kill() с параметром, который заставляет выгрузить дамп ядра. Ядро может уничтожать процессы по разным причинам, включая арифметические ошибки, такие как деление на ноль, либо по причине выполнения программой некорректных инструкций, либо при попытке доступа к запрещенной области памяти. Последняя причина вызывает ошибку сегментации, что выражается в сообщении segmentation fault (core dumped) (ошибка сегментации (дамп ядра сброшен)). Если вы обладаете хоть каким-нибудь опытом программирования в Linux, то наверняка неоднократно получали это сообщение.

Если для процесса установлен лимит на размер файла дампа, равный 0 (рассматривался ранее в этой главе), то никакой дамп ядра не выгружается.

10.5. Простые дочерние процессы

Хотя функции fork(), exec() и wait() позволяют программам в полной мере использовать модель процессов Linux, многим приложениям не нужен такой контроль дочерних процессов. Существуют две библиотечных функции, которые упрощают создание дочерних процессов: system() и popen().

10.5.1. Запуск и ожидание с помощью system()

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

int system (const char* cmd);

system() порождает дочерний процесс, который выполняет exec() для /bin/sh, который, в свою очередь, запускает cmd. Исходный процесс ожидает завершения дочерней оболочки и возвращает тот же код, что wait()[28]. Если вам не нужно оставлять в памяти оболочку (что случается редко), cmd должна включать предшествующее слово "exec", которое заставляет оболочку вызывать exec() вместо запуска cmd как подпроцесса.

Поскольку cmd запускается из оболочки /bin/sh, то здесь применимы все обычные правила расширения команд. Ниже показан пример вызова system(), который отображает исходные тексты С из текущего каталога.

#include <stdlib.h>

#include <sys/wait.h>


int main() {

int result;

result = system("exec ls *.c");

if (!WIFEXITED(result))

 printf("(аварийный выход)\n");

 exit(0);

}

Команда system() должна применяться с большой осторожностью в программах, которые запускаются со специальными полномочиями. Поскольку системная оболочка предоставляет множество мощных средств и сильно зависит от переменных окружения, system() является уязвимым местом в плане безопасности, которым могут воспользоваться злоумышленники для проникновения в систему. Однако до тех пор, пока приложение не является демоном или программой setuid/setgid, вызов system() совершенно безопасен.

10.5.2. Чтение и запись из процесса

Хотя system() отображает результат работы команды на устройство стандартного вывода и позволяет дочерним программам читать стандартный ввод, это не всегда идеально. Часто процесс желает читать вывод другого процесса либо отправлять текст на стандартный ввод. popen() облегчает процессам решение этой задачи[29].

FILE * popen(const char *cmd, const char *mode);

cmd выполняется через оболочку, как и в system(). Параметр mode должен быть "r", если родительский процесс желает читать командный вывод, и "w" — для записи в стандартный ввод дочернего процесса. Следует отметить, что с помощью popen() делать одновременно чтение и запись нельзя.

Два процесса, которые читают и пишут друг в друга, достаточно сложны[30] и выходят за рамки возможностей popen()[31].

popen() возвращает FILE* (как это определено в стандартной библиотеке ввода-вывода ANSI/ISO), который может быть прочитан и записан подобно любому другому потоку stdio[32], либо NULL, если операция не удается. Когда завершается родительский процесс, он может воспользоваться pclose() для закрытия потока и прерывания дочернего процесса, если он все еще выполняется. Подобно system(), pclose() возвращает состояние дочернего процесса из wait4().

int pclose(FILE *stream);

Ниже приведен пример простой программы-калькулятора, которая использует программу bc для выполнения всей реальной работы. Важно сбрасывать поток, полученный от popen(), после записи в него, чтобы предотвратить буферизацию stdio от задержки вывода (подробности о буферизации стандартных функций библиотеки stdio можно найти в [15]).

 1: /*calc.c*/

 2:

 3: /* Это очень простой калькулятор, который использует внешнюю команду bc

 4:    для выполнения всей работы. Открывает канал к bc, читает команду,

 5:    передает ее bc и завершается. */

 6: #include <stdio.h>

 7: #include <sys/wait.h>

 8: #include <unistd.h>

 9:

10: int main(void) {

11:  char buf[1024];

12:  FILE *bc;

13:  int result;

14:

15:  /* открыть канал на bc и выйти в случае неудачи */

16:  bc = popen("bc", "w");

17:  if (!bc) {

18:   perror("popen");

19:   return 1;

20:  }

21:

22:  /* пригласить ввести выражение, и прочитать его */

23:  printf("expr:"); fflush(stdout);

24:  fgets(buf, sizeof(buf), stdin);

25:

26:  /* послать выражение bc для вычисления */

27:  fprintf(bc, "%s\n", buf);

28:  fflush(bc);

29:

30:  /* закрыть канал на bc и ожидать выхода из нее */

31:  result = pclose(bc);

32:

33:  if (!WIFEXITED(result))

34:   printf("(аварийный выход)\n");

35:

36:  return 0;

37: }

Подобно system(), popen() запускает команды через системную оболочку и должна использоваться с большой осторожностью, если вызывается из программы со специальными полномочиями.

10.6. Сеансы и группы процессов

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

• Запуск неинтерактивных заданий в фоновом режиме.

• Переключение между интерактивными заданиями с помощью управления заданиями (job control), которое более подробно обсуждается в главе 15.

• Запуск множества процессов, взаимодействующих через программные каналы.

• Запуск оконной системы, вроде X Window System, которая позволяет открывать несколько терминальных окон.

Чтобы управлять всеми этими процессами, ядру необходимо группировать процессы более сложным образом, чем простое отношение "родительский-дочерний", которое мы описали. Этот способ группировки называется сеансами и группами процессов. На рис. 10.1 показано отношение между сеансами, группами процессов и процессами.

Рис. 10.1. Сеансы, группы процессов и процессы

10.6.1. Сеансы

Когда пользователь выходит из системы, ядро должно прервать все процессы, которые пользователь запустил (иначе может остаться множество процессов, которые будут ожидать ввода, а тот никогда не последует). Чтобы упростить эту задачу, процессы организуются в наборы сеансов. Идентификатор сеанса — это то же, что pid процесса, который создает сеанс с помощью системного вызова setsid(). Этот процесс называют лидером сеанса (session leader) для данной группы процессов. Все потомки процесса являются членами сеанса, если только явно не будут удалены из него. Вызов функции setsid() не принимает аргументов, а возвращает идентификатор нового сеанса.

#include <unistd.h>


pid_t setsid(void);

10.6.2. Управление терминалом

Каждый сеанс привязывается к терминалу, от которого процессы и сеансы получают ввод и куда отправляют свой вывод. Терминал может быть локальной консолью машины, терминальным подключением через последовательный порт или псевдотерминалом, который отображается на окно X либо на сетевое подключение (см. главу 16). Терминал, к которому относится сеанс, называется управляющим терминалом (или управляющим tty) данного сеанса. Терминал может быть управляющим одновременно только для одного сеанса.

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

10.6.3. Группы процессов

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

ls | grep "^[аА].*\.gz" | more

Другое популярное средство, появившееся в Unix достаточно давно — управление заданиями (job control). Управление заданиями дает возможность пользователям прерывать текущее задание (известное как задание переднего плана (foreground task)) в то время, пока они уходят и делают на терминале что-то другое. Когда приостановленное задание представляет собой последовательность процессов, работающих вместе, система должна отслеживать, какие именно процессы должны быть приостановлены, когда пользователь желает приостановить задание переднего плана. Группы процессов позволяют системе видеть, какие процессы работают вместе, а потому должны управляться совместно средствами управления заданиями.

Процессы добавляются в группы с помощью setpgid().

int setpgid(pid_t pid, pid_t pgid);

pid — это процесс, который должен быть помещен в новую группу (0 обозначает текущий процесс), pgid — это идентификатор группы процессов, к которой должен принадлежать процесс pid, или 0, если процесс должен быть включен в новую группу процессов, чей pgid тот же, что и pid процесса. Подобно сеансам, лидер группы процессов — это процесс, чей pid совпадает в pgid группы.

Правила применения setpgid() несколько сложны.

1. Процесс может устанавливать группу для себя или одного из своих потомков. Он не может изменять группу для любого другого процесса в системе, даже если процесс, вызвавший setpgid(), имеет административные полномочия.

2. Лидер сеанса не может изменить свою группу.

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

Вызов setpgid() помещает вызывающий процесс в свою собственную группу и собственный сеанс. Это необходимо для того, чтобы гарантировать, что два сеанса не содержат процессы, принадлежащие к одной и той же группе.

Полный пример групп процессов будет приведен при обсуждении системы управления заданиями в главе 15.

Когда соединение с терминалом теряется, ядро посылает сигнал (SIGHUP; подробнее о сигналах рассказывается в главе 12) лидеру сеанса, содержащему группу процессов переднего плана данного терминала. Обычно это командная оболочка. Это позволит оболочке безусловно прерывать пользовательские процессы, извещая их о том, что пользователь выходит из системы (обычно посредством SIGHUP), либо выполнить некоторые другие действия (или бездействие). Хотя это все может показаться усложненным, это дает возможность лидеру группы сеанса принимать решения о том, как управлять закрывающимися терминалами, вместо того, чтобы возлагать эту обязанность на ядро. Это также дает возможность администраторам гибко управлять политиками пользовательских учетных записей.

Определение группы процесса может быть выполнено просто, с помощью функций getpgid() и getpgrp().

pid_t getpgid(pid_t pid) Возвращает pgid процесса pid. Если pid равен 0, возвращается pgid текущего процесса. Для вызова не требуется никаких специальных полномочий. Любой процесс может определять группу, к которой принадлежит любой другой процесс.
pid_t getpgrp(void) Возвращает pgid текущего процесса pid (эквивалентно getprgid(0))

10.6.4. Висячие группы процессов

Механизм прерывания процессов (либо возобновления их работы после приостановки) при исчезновении их сеанса довольно сложен. Представьте себе сеанс со многими группами процессов в нем (см. рис. 10.1). Сеанс запущен на терминале, и обычная системная оболочка является его лидером.

Когда лидер сеанса (оболочка) завершается, ее группы процессов оказываются в сложной ситуации. Если они активно работают, то лишаются возможности использовать стандартные потоки stdin и stdout, поскольку терминал закрыт. Если они приостановлены, то вероятно, никогда не будут запущены снова, поскольку пользователь терминала не имеет возможности перезапустить их, к тому же то, что они не могут быть запущены, означает также, что они не могут быть и прерваны.

В этой ситуации каждая такая группа процессов получает название висячей (orphaned). Стандарт POSIX определяет ее как группу процессов, чей родитель является также членом этой группы либо не является членом сеанса этой группы. Другими словами, группа процессов не является висячей до тех пор, пока у нее есть родительский процесс, принадлежащий тому же сеансу, но другой группе.

Хотя оба определения выглядят сложными, концепция достаточно проста. Если группа процессов приостановлена, и не существует процесса, который бы принудил ее возобновиться, то эта группа становится висячей[33].

Когда завершает работу командная оболочка, все ее дочерние процессы становятся дочерними по отношению к процессу init, оставаясь при этом в своих исходных сеансах. Предполагая, что все программы в сеансе являются потомками оболочки, все группы процессов этого сеанса становятся висячими[34]. Когда группа процессов превращается в висячую, каждый процесс этой группы получает сигнал SIGHUP, что обычно прерывает программу.

Программы, которые не прерываются по сигналу SIGHUP, получают сигнал SIGCONT, который продолжает выполнение приостановленных процессов. Такая последовательность прерывает большинство процессов и обеспечивает оставшимся возможность работать (то есть гарантирует, что они не будет в приостановленном состоянии)[35].

Как только процесс становится висячим, он принудительно отключается от своего управляющего терминала (позволяя новому пользователю при необходимости применять этот терминал). Если продолжающие работать программы пытаются получить доступ к терминалу, эти попытки вызывают ошибки, устанавливающие errno в значение EIO. Процессы остаются в том же сеансе, и идентификатор сеанса не используется для новых идентификаторов процессов до тех пор, пока не завершатся все процессы данного сеанса.

10.7. Введение в ladsh

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

• Простые встроенные команды.

• Запуск внешних команд.

• Перенаправление ввода-вывода (>, | и так далее).

• Управление заданиями.

Полный исходный текст окончательной версии этой оболочки, ladsh4.с, представлен в приложении Б. По мере добавления в ladsh новых средств, изменения исходного текста описываются в тексте книги. Чтобы уменьшить количество изменений, которые мы вносим между версиями, некоторые ранние версии несколько более сложны, чем было бы нужно. Эти небольшие усложнения, однако, далее в книге упрощают разработку оболочки, поэтому будьте терпеливы. Просто пока поверьте, что эти фрагменты кода необходимы; все они будут объяснены позднее.

10.7.1. Запуск внешних программ с помощью ladsh

Вот первая (и самая простая) версия ladsh, называемая ladsh1.

  1: /*ladsh1.c*/

  2:

  3: #include <ctype.h>

  4: #include <errno.h>

  5: #include <fcntl.h>

  6: #include <signal.h>

  7: #include <stdio.h>

  8: #include <stdlib.h>

  9: #include <string.h>

 10: #include <sys/ioctl.h>

 11: #include <sys/wait.h>

 12: #include <unistd.h>

 13:

 14: #define MAX_COMMAND_LEN 250 /* максимальная длина отдельной

 15:                                командной строки */

 16: #define JOB_STATUS_FORMAT "[%d]%-22s%.40s\n"

 17:

 18: struct jobSet {

 19:  struct job *head; /* заголовок списка запущенных заданий */

 20:  struct job *fg;   /* текущее задание переднего плана */

 21: };

 22:

 23: struct childProgram {

 24:  pid_t Pid;   /* 0 на выходе */

 25:  char **argv; /* имя программы с аргументами */

 26: };

 27:

 28: struct job {

 29:  int job Id;       /* номер задания */

 30:  int numProgs;     /* общее кол-во программ в задании */

 31:  int runningProgs; /* кол-во работающих программ */

 32:  char *text;       /* имя задания */

 33:  char *cmdBuf;     /* буфер различных argv */

 34:  pid_t pgrp;       /* идентификатор группы процессов задания */

 35:  struct childProgram *progs; /* массив программ в задании */

 36:  struct job *next; /* для слежения за фоновыми программами */

 37: };

 38:

 39: void freeJob(struct job *cmd) {

 40:  int i;

 41:

 42:  for (i=0; i<cmd->numProgs; i++) {

 43:   free (cmd->progs[i].argv);

 44:  }

 45:  free(cmd->progs);

 46:  if (cmd->text) free(cmd->text);

 47:   free(cmd->cmdBuf);

 48:  }

 49:

 50:  int getCommand(FILE *source, char *command) {

 51:  if (source == stdin) {

 52:   printf("#");

 53:   fflush(stdout);

 54:  }

 55:

 56:  if (!fgets(command, MAX_COMMAND_LEN, source)) {

 57:   if (source==stdin) printf("\n");

 58:   return 1;

 59:  }

 60:

 61:  /* удалить завершающий перевод строки */

 62:  command[strlen(command) - 1] = '\0';

 63:

 64:  return 0;

 65: }

 66:

 67: /* Возвратить cmd->numProgs как 0, если нет никаких команд (то есть пустая

 68:    строка). Если найдена правильная команда, commandPtr устанавливается в

 69:    указатель на начало следующей команды (если исходная команда имеет более

 70:    одного задания, ассоциированного с ней) или NULL, если

 71:    больше нет команд.*/

 72: int parseCommand(char **commandPtr, struct job *job, int *isBg) {

 73:  char *command;

 74:  char *returnCommand = NULL;

 75:  char *src, *buf;

 76:  int argc = 0;

 77:  int done = 0;

 78:  int argvAlloced;

 79:  char quote = '\0';

 80:  int count;

 81:  struct childProgram *prog;

 82:

 83:  /* Пропустить ведущие пробелы */

 84:  while(**commandPtr && isspace(**commandPtr)) (*commandPtr)++;

 85:

 86:  /* здесь обрабатываются пустые строки и ведущие символы '#' */

 87:  if (!**commandPtr || (**commandPtr=='#')) {

 88:   job->numProgs = 0;

 89:   *commandPtr = NULL;

 90:   return 0;

 91:  }

 92:

 93:  *isBg = 0;

 94:  job->numProgs = 1;

 95:  job->progs = malloc(sizeof(*job->progs));

 96:

 97:  /* Мы устанавливаем элементы argv в указатели внутри строки.

 98:     Память освобождается freeJob().

 99:

100:     Получение чистой памяти позволяет далее иметь дело с

101:     NULL-завершающимися вещами и делает все остальное немного

102:     яснее (к тому же, это добавляет эффективности) */

103:  job->cmdBuf = command = calloc(1, strlen(*commandPtr) + 1);

104:  job->text = NULL;

105:

106:  prog = job->progs;

107:

108:  argvAlloced = 5;

109:  prog->argv = malloc(sizeof(*prog->argv) * argvAlloced);

110:  prog->argv[0] = job->cmdBuf;

111:

112:  buf = command;

113:  src = *commandPtr;

114:  while (*src && !done) {

115:   if (quote==*src) {

116:    quote='\0';

117:   } else if (quote) {

118:    if (*src == '\\') {

119:     src++;

120:     if (!*src) {

121:      fprintf(stderr,

122:       "ожидается символ после\\\n");

123:      freeJob(job);

124:      return 1;

125:     }

126:

127:     /* в оболочке, "\'" должно породить \' */

128:     if (*src != quote) *buf++='\\';

129:    }

130:    *buf++ = *src;

131:   } else if (isspace(*src)) {

132:    if (*prog->argv[argc]) {

133:     buf++, argc++;

134:     /* +1 здесь оставляет место для NULL,

135:        которым завершается argv */

136:     if ((argc+1) == argvAlloced) {

137:      argvAlloced += 5;

138:      prog->argv = realloc(prog->argv,

139:       sizeof(*prog->argv)*argvAlloced);

140:     }

141:     prog->argv[argc]=buf;

142:    }

143:   } else switch(*src) {

144:   case '"':

145:   case '\'':

146:    quote = *src;

147:    break;

148:

149:   case '#' : /* комментарий */

150:    done=1;

151:    break;

152:

153:   case '&': /* фоновый режим */

154:    *isBg = 1;

155:   case ';': /* множественные команды */

156:    done=1;

157:    return Command = *commandPtr + (src - *commandPtr) + 1;

158:    break;

159:

160:   case '\\' :

161:    src++;

162:    if (!*src) {

163:     freeJob(job);

164:     fprintf(stderr, "ожидается символ после \\\n");

165:     return 1;

166:    }

167:    /* двигаться дальше */

168:   default:

169:    *buf++=*src;

170:   }

171:

172:   src++;

173:  }

174:

175:  if (*prog->argv[argc]) {

176:   argc++;

177:  }

178:  if (!argc) {

179:   freeJob(job);

180:   return 0;

181:  }

182:  prog->argv[argc]=NULL;

183:

184:  if (!returnCommand) {

185:   job->text = malloc(strlen(*commandPtr) + 1);

186:   strcpy(job->text,*commandPtr);

187:  } else {

188:   /* Это оставляет хвостовые пробелы, что несколько излишне */

189:

190:   count = returnCommand - *commandPtr;

191:   job->text = malloc(count + 1);

192:   strncpy(job->text,*commandPtr,count);

193:   job->text[count] = '\0';

194:  }

195:

196:  *commandPtr = returnCommand;

197:

198:  return 0;

199: }

200:

201: int runCommand(struct jobnewJob, struct jobSet *jobList,

202:  intinBg) {

203:  struct job *job;

204:

205:  /* обходной путь "вручную" - мы не используем fork(),

206:     поэтому не можем легко реализовать фоновый режим */

207:  if (!strcmp(newJob.progs[0].argv[0], "exit")) {

208:   /* это должно вернуть реальный код возврата */

209:   exit(0);

210:  } else if(!strcmp(newJob.progs[0].argv[0], "jobs")) {

211:   for (job = jobList->head; job; job = job->next)

212:    printf(JOB_STATUS_FORMAT, job->jobId, "Работаю",

213:     job->text);

214:   return 0;

215:  }

216:

217:  /* у нас пока только одна программа на дочернее задание,

218:     потому это просто */

219:  if (!(newJob.progs[0].pid = fork())) {

220:   execvp(newJob.progs[0].argv[0],newJob.progs[0].argv);

221:   fprintf(stderr, "exec() для %s потерпела неудачу: %s\n",

222:    newJob.progs[0].argv[0],

223:   strerror(errno));

224:   exit(1);

225:  }

226:

227:  /* поместить дочернюю программу в отдельную группу процессов */

228:  setpgid(newJob.progs[0].pid,newJob.progs[0].pid);

229:

230:  newJob.pgrp = newJob.progs[0].pid;

231:

232:  /* найти идентификатор для задания */

233:  newJob.jobld = 1;

234:  for (job = jobList->head; job; job = job->next)

235:   if (job->jobId >= newJob.jobId)

236:    newJob.jobId = job->jobId+1;

237:

238:  /* задание для списка заданий */

239:  if (!jobList->head) {

240:   job = jobList->head = malloc(sizeof(*job));

241:  } else {

242:   for (job = jobList->head; job->next; job = job->next);

243:   job->next = malloc(sizeof(*job));

244:   job = job->next;

245:  }

246:

247:  *job = newJob;

248:  job->next = NULL;

249:  job->runningProgs = job->numProgs;

250:

251:  if (inBg) {

252:   /* мы не ждем завершения фоновых заданий - добавить

253:      в список фоновых заданий и оставить в покое */

254:

255:   printf("[%d]%d\n", job->jobId,

256:    newJob.progs[newJob.numProgs-1].pid);

257:  } else {

258:   jobList->fg=job;

259:

260:   /* переместить новую группу процессов на передний план */

261:

262:   if (tcsetpgrp(0,newJob.pgrp))

263:    perror("tcsetpgrp");

264:  }

265:

266:  return 0;

267: }

268:

269: void removeJob(struct jobSet *jobList, struct job *job) {

270:  struct job *prevJob;

271:

272:  freeJob(job);

273:  if (job == jobList->head) {

274:   jobList->head=job->next;

275:  } else {

276:   prevJob = jobList->head;

277:   while (prevJob->next != job) prevJob = prevJob->next;

278:   prevJob->next=job->next;

279:  }

280:

281:  free(job);

282: }

283:

284: /* Проверить, завершился ли какой-то из фоновых процессов -

285:    если да, выяснить, почему и определить, завершилось ли задание */

286: void checkJobs(struct jobSet *jobList) {

287:  struct job *job;

288:  pid_t childpid;

289:  int status;

290:  int progNum;

291:

292:  while ((childpid = waitpid(-1, &status, WNOHANG))>0) {

293:   for (job = jobList->head;job;job = job->next) {

294:    progNum = 0;

295:    while (progNum<job->numProgs &&

296:     job->progs[progNum].pid != childpid)

297:     progNum++;

298:    if (progNum<job->numProgs) break;

299:   }

300:

301:   job->runningProgs--;

302:   job->progs[progNum].pid = 0;

303:

304:   if (!job->runningProgs) {

305:    printf(JOB_STATUS_FORMAT,job->jobId,"Готово",

306:     job->text);

307:    removeJob(jobList, job);

308:   }

309:  }

310:

311:  if (childpid == -1 && errno!= ECHILD)

312:   perror("waitpid");

313:  }

314:

315:  int main(int argc, const char **argv) {

316:   char command [MAX_COMMAND_LEN + 1];

317:   char *nextCommand = NULL;

318:   struct jobSetjobList = {NULL, NULL};

319:   struct jobnewJob;

320:   FILE *input = stdin;

321:   int i;

322:   int status;

323:   int inBg;

324:

325:   if (argc>2) {

326:    fprintf(stderr,"Непредвиденные аргументы; использование: ladsh1 "

327:     "<команды>\n");

328:    exit(1);

329:   } else if (argc == 2) {

330:    input = fopen(argv[1], "r");

331:    if (!input) {

332:     perror("fopen");

333:     exit(1);

334:    }

335:   }

336:

337:   /* не обращать внимания на этот сигнал; он только вводит

338:      в заблуждение и не имеет особого значения для оболочки */

339:   signal(SIGTTOU, SIG_IGN);

340:

341:   while(1) {

342:   if (!jobList.fg) {

343:    /* нет заданий переднего плана */

344:

345:    /* проверить, завершились ли какие-то фоновые процессы */

346:    checkJobs(&jobList);

347:

348:    if (!nextCommand) {

349:     if (getCommand(input, command)) break;

350:     nextCommand=command;

351:    }

352:

353:    if (!parseCommand(&nextCommand, &newJob, &inBg) &&

354:     newJob.numProgs) {

355:     runCommand(newJob,&jobList,inBg);

356:    }

357:   } else {

358:    /* задание выполняется на переднем плане; ждать завершения */

359:    i = 0;

360:    while (!jobList.fg->progs[i].pid) i++;

361:

362:    waitpid(jobList.fg->progs[i].pid,&status,0);

363:

364:    jobList.fg->runningProgs--;

365:    jobList.fg->progs[i].pid=0;

366:

367:    if (!jobList.fg->runningProgs) {

368:     /* дочернее завершилось */

369:

370:     removeJob(&jobList, jobList.fg);

371:     jobList.fg = NULL;

372:

373:     /* переместить оболочку на передний план */

374:     if (tcsetpgrp(0, getpid()))

375:      perror("tcsetpgrp");

376:    }

377:   }

378:  }

379:

380:  return 0;

381: }

Эта версия не делает ничего, кроме запуска внешней программы с аргументами, поддержки комментариев стиля # (все, что следует за символом #, игнорируется), и позволяет программам выполняться в фоновом режиме. Она работает как интерпретатор простых сценариев оболочки, написанных в нотации #!, но ничего сверх этого не делает. Она разработана в качестве имитации обычного интерпретатора оболочки, используемого в системах Linux, несмотря на то, что в значительной степени упрощена.

Прежде всего, взглянем на структуры данных, которые здесь используются. На рис. 10.2 показаны структуры данных, используемые в ladsh1.с для отслеживания запускаемых дочерних процессов, на примере применения программы grep в фоновом режиме и links — в режиме переднего плана, struct jobSet описывает набор функционирующих заданий. Он содержит связный список заданий и указатель на текущее задание, выполняемое на переднем плане. Если такового нет, то указатель равен NULL, ladsh1.с использует struct jobSet для того, чтобы отслеживать задания, выполняемые в данный момент в фоновом режиме.

Рис. 10.2. Структуры данных, описывающие задания для ladsh1.с

struct childProgram описывает отдельную выполняемую программу. Это не совсем то же самое, что задание — в конце концов, каждое задание может состоять из нескольких программ, связанных по программным каналам. Для каждой дочерней программы ladsh отслеживает pid, имя программы и аргументы командной строки. Первый элемент argv, argv[0], содержит имя запущенной программы, которое передается также потомку в виде первого аргумента.

Множество программ объединяется в одно задание с помощью struct job. Каждое задание имеет уникальный идентификатор в оболочке, соответствующее количество программ, составляющих задание (хранимых в progs, указателе на массив struct childProgram), а также указатель на другое (следующее) задание, что позволяет объединять их вместе в связный список (который описывает struct jobSet). Задание также отслеживает, сколько отдельных программ составляет его, и сколько их них все еще выполняются (поскольку не все компоненты задания могут завершаться одновременно). Остальные два члена — text и cmdBuf — служат в качестве буферов для хранения различных строк, которые используются структурами struct childProgram, содержащимися в задании.

Большая часть struct jobSet состоит из динамически распределенной памяти, которая должна быть освобождена по завершении задания. Первая функция в ladsh1.с, freeJob(), освобождает память, использованную заданием.

Следующая функция, getCommand(), получает команду, введенную пользователем, и возвращает строку. Если команды читаются из файла, то никакого приглашения не выводится (вот почему код сравнивает входной файловый поток со stdin).

parseCommand() разбивает строку команды в структуру struct job для использования в ladsh. Первый аргумент — это указатель на указатель на команду. Если в строке множество команд, он переставляется на начало следующей команды. Он устанавливается в NULL, когда завершается разбор последней команды в строке. Это позволяет parseCommand() разбирать только одну команду при каждом вызове и дает возможность вызывающей функции просто разбирать строку за несколько вызовов. Следует отметить, что несколько программ, объединенных каналами, не рассматриваются как отдельные команды — независимыми друг от друга считаются только команды, разделенные символами ; или &. Поскольку parseCommand() — это просто пример разбора строк, мы не будем углубляться в детали ее работы.

Функция runCommand() отвечает за запуск отдельного задания. Она принимает структуру struct job, описывающую запускаемое задание, список заданий, выполняющихся в данный момент, а также флаг, указывающий, должно ли задание выполняться в фоновом режиме или же на переднем плане.

Пока ladsh не поддерживает каналов, поэтому каждое задание может состоять только из одной программы (хотя большая часть инфраструктуры, поддерживающей каналы, уже присутствует в ladsh1.с). Если пользователь запускает exit, происходит немедленный выход из программы. Это пример встроенной команды, которую выполняет сама оболочка для обеспечения правильного поведения. Другая встроенная команда — jobs — также здесь реализована.

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

219: if (!(newJob.progs[0].pid = fork())) {

220:  execvp(newJob.progs[0].argv[0], newJob.progs[0].argv);

221:  fprintf(stderr, "exec() для %s потерпела неудачу: %s\n",

222:   newJob.progs[0].argv[0],

223:  strerror(errno));

224:  exit(1);

225: }

Во-первых, с помощью fork() порождается дочерний процесс. Родитель сохраняет идентификатор pid дочернего процесса в newJob.progs[0].pid, тогда как дочерний процесс сохраняет там 0 (помните, что родитель и потомок имеют разные образы памяти, хотя изначально они и содержат одинаковую информацию). В результате управление в дочернем процессе входит в тело оператора if, в то время как родитель пропускает его. Дочерний немедленно запускает новую программу с помощью вызова execvp(). Если ему этот вызов не удается, печатается сообщение об ошибке и работа завершается. Это все необходимо, чтобы породить простой дочерний процесс.

После порождения дочернего процесса родитель помещает его в его собственную группу и записывает задание в список запущенных заданий. Если процесс должен выполняться на переднем плане (не в фоне), родитель вносит дочерний процесс в группу процессов переднего плана управляющего терминала, на котором работает командная оболочка.

Следующая функция, checkJobs(), ищет фоновые задания, которые были завершены, и соответствующим образом чистит список работающих заданий. Для каждого процесса, который был завершен (помните, что waitpid() возвращает только информацию о завершенных процессах, если только не было указано WUNTRACED), оболочка делает следующие вещи.

1. Ищет задание, частью которого является процесс.

2. Помечает программу как завершенную (устанавливая сохраненный pid равным 0) и уменьшает количество работающих программ в задании на единицу.

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

Процедура main() из ladsh1.с контролирует поток управления оболочки. Если при ее запуске ей передан аргумент, он трактуется как имя файла, из которого нужно читать последовательность команд. В противном случае в качестве источника команд используется stdin. Затем программа игнорирует сигнал SIGTTOU. Это элемент "магии" управления заданиями, который обеспечивает, что все происходит гладко. Смысл этого будет пояснен в главе 15. Пока что это только скелет.

Остаток функции main() составляет главный цикл программы. Условие выхода из цикла не предусмотрено. Программа завершается вызовом exit() внутри функции runCommand().

Переменная nextCommand указывает на исходное (не разобранное) строковое представление следующей команды, которая должна быть выполнена, либо NULL, если команда должна быть прочитана из входного файла, коим обычно является stdin. Когда никакое задание не выполняется на переднем плане, ladsh вызывает checkJobs() для проверки выполняющихся фоновых заданий, читает следующую команду из входного файла, если nextCommand равно NULL, затем разбирает и выполняет следующую команду.

Когда выполняется задание переднего плана, ladsh1.с ожидает завершения одного из процессов задания переднего плана. Когда все процессы задания переднего плана завершены, задание исключается из списка запущенных заданий и ladsh1.с читает следующую команду, как описано выше.

10.8. Создание клонов

Хотя fork() является традиционным способом создания новых процессов в Unix, Linux также предлагает системный вызов call(), позволяющий процессам дублироваться с указанием ресурсов, которые родительский процесс должен разделять со своими потомками.

int clone(int flags);

Это ненамного отличается от fork(). Единственная разница в наличии параметра flags. Он должен быть установлен равным сигналу, который посылается родительскому процессу, когда потомок завершает работу (обычно это SIGCHLD), объединенному логическим "или" с любым сочетанием перечисленных ниже флагов, определенных в <sched.h>.

CLONE_VM Два процесса разделяют пространство виртуальной памяти (включая стек).
CLONE_FS Разделяется информация файловой системы (такая как текущий каталог).
CLONE_FILES Разделяются открытые файлы.
CLONE_SIGHAND Обработчики сигналов разделяются двумя процессами.

Когда ресурсы разделяется двумя процессами, оба они видят эти ресурсы идентично. Если указан CLONE_SIGHAND, то когда один процесс заменяет обработчик определенного сигнала, оба начинают использовать новый обработчик (подробности об обработчиках сигналов представлены в главе 12). Когда используется CLONE_FILES, разделяются не только наборы открытых файлов, но также текущие позиции в каждом файле. Значения возврата для clone() те же самые, что и у fork().

Если для доставки родительскому процессу специфицирован сигнал, отличный от SIGCHLD, то семейство функций wait() по умолчанию не будет возвращать информацию об этих процессах. Если вы хотите получать информацию об этих процессах, как и в случае процессов, использующих нормальный механизм SIGCHLD, то флаг __WCLONE должен быть объединен с помощью логического "или" с параметром flags вызова wait(). Хотя такое поведение может показаться странным, оно обеспечивает большую гибкость. Если бы функция wait() возвращала информацию о клонированных процессах, было бы сложнее построить стандартные библиотеки потоков вокруг clone(), потому что wait() должна возвращать информацию о других потоках, а также о дочерних процессах.

Хотя и не рекомендуется, чтобы приложения непосредственно использовали clone(), доступно множество библиотек пространства пользователя, которые применяют clone() и предоставляют полностью POSIX-совместимую реализацию потоков. Библиотека glibc включает libthread — наиболее популярную реализацию потоков. Теме программирования потоков POSIX посвящено несколько хороших книг, среди которых [4] и [23].

Глава 11 Простое управление файлами

Файлы — это наиболее распространенная абстракция ресурсов, используемая в мире Unix. Такие ресурсы, как память, дисковое пространство, устройства и каналы межпроцессного взаимодействия (IPC), могут быть представлены в виде файлов. Поддерживая унифицированную абстракцию для этих ресурсов, Unix уменьшает количество программных интерфейсов, которые обязан знать программист. Ниже перечислены ресурсы, доступные через файловые операции.

• Обычные файлы. Это то, о чем большинство пользователей компьютеров думают как о файлах. Они служат репозиториями данных, которые могут расти до необходимых размеров, и обеспечивают произвольный доступ. Файлы Unix являются байт-ориентированными — любое другое логическое представление является результатом программных преобразований; ядро ничего не знает о них.

• Каналы (pipes). Простейший механизм IPC в Unix. Обычно один процесс пишет информацию в канал в то время как другой читает из него. Каналы — это то, что командные оболочки используют для перенаправления ввода-вывода (например, ls -LR | grep notes или ls | more), и многие программы применяют каналы для того, чтобы передавать свой ввод программам, запущенным в виде их подпроцессов. Существуют два типа каналов: именованные и неименованные. Неименованные каналы создаются по мере необходимости и исчезают, как только читатель и писатель на концах канала закрывают его. Неименованные каналы называются так, потому что они не существуют в файловой системе и потому не имеют файловых имен[36]. Именованные каналы обладают именами файлов, и имя файла используется для того, чтобы позволить двум независимым процессам общаться через канал (подобно тому, как работают сокеты доменов Unix (см. главу 17)). Каналы также известны как FIFO (first-in-first-out), потому что данные упорядочены в манере "первым вошел — первым вышел".

• Каталоги. Специальные файлы, которые содержат списки файлов, хранящихся внутри них. Старые реализации Unix позволяли программам читать и писать их в той же манере, что и обычные файлы. Чтобы обеспечить большую степень абстракции, добавлен специальный набор системных вызовов для обеспечения манипуляций каталогами, хотя каталоги по-прежнему открываются и закрываются подобно обычным файлам. Эти функции рассматриваются в главе 14.

• Файлы устройств. Большинство физических устройств представлены в виде файлов. Есть два типа файлов устройств: блочные устройства и символьные устройства. Файлы блочных устройств представляют аппаратные устройства[37], которые не могут быть прочитаны побайтно; они должны читаться блоками определенного размера. В Linux блочные устройства принимают специальное управление от ядра[38]и могут содержать файловые системы[39]. Дисковые приводы, включая CD-ROM и RAM-диски, являются наиболее часто используемыми блочными устройствами. Символьные устройства могут быть прочитаны по одному символу за раз, и ядро не представляет для них никаких средств кэширования или упорядочивания. Модемы, терминалы, принтеры, звуковые карты и мыши — все это символьные устройства. Традиционно к каждому из них привязана некая сущность в каталоге /dev, что позволяет пользовательским процессам получать доступ к ресурсам устройств как к файлам.

• Символические ссылки. Специальный тип файла, который содержит путь к другому файлу. Когда открывается символическая ссылка, система распознает ее как ссылку, читает ее значение и открывает файл, на который она ссылается, вместо самой ссылки. Когда используется значение, сохраняемое в символической ссылке, говорят, что система следует по ссылке. Если не указано другое, предполагается, что системные вызовы следуют по ссылкам, которые переданы им.

• Сокеты. Подобно каналам, сокеты представляют собой каналы IPC. Они более гибки, чем каналы, и могут создавать IPC-каналы между процессами, запущенными на разных машинах. Сокеты обсуждаются в главе 17.

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

Единственной уникальной отличительной чертой файла является его inode (от information node — информационный узел). Информационный узел файла содержит всю информацию о файле, включая права доступа, ассоциированные с ним, его текущий размер, количество имен, которые он имеет (оно может быть равно нулю, одному, двадцати или больше). Существуют два типа информационных узлов, in-core inode (информационный узел в ядре) — единственный тип, о котором нам нужно заботиться; каждый открытый файл в системе имеет его. Ядро отслеживает такие узлы в памяти, и они одинаковы для файловых систем всех типов. Другой тип узлов — on-disk inode (информационный узел на диске). Каждый файл в файловой системе имеет такой узел, и его точная структура зависит от типа файловой системы, в которой хранится файл.

Когда процесс открывает файл в файловой системе, on-disk inode загружается в память и превращается в in-core inode. Когда последний модифицируется, он трансформируется обратно в on-disk inode и сохраняется в файловой системе[40].

in-core inode и on-disk inode не содержат абсолютно одинаковую информацию. Так, например, только in-core inode отслеживает, сколько процессов в системе в данный момент используют файл, ассоциированный с ним.

Когда in-core inode и on-disk inode синхронизируются ядром, большинство системных вызовов завершаются обновлением этих узлов. Когда такое происходит, мы просто будем говорить об обновлении узла; это подразумевает, что изменением затронуты как in-core inode, так и on-disk inode. Некоторые файлы (такие как неименованные каналы), не имеют on-disk inode. В этом случае обновляется только in-core inode.

Имя файла существует только в каталоге, который связывает имя с on-disk inode. Вы можете воспринимать об именах файлов, как об указателях на дисковые узлы для файлов, ассоциированных с ними. Дисковый узел содержит в счетчике ссылок количество имен файлов, которые на него ссылаются. Когда файл удаляется, счетчик ссылок уменьшается на единицу, и если достигает 0, и ни один процесс не держит его открытым, то занятое файлом пространство освобождается. Если же другие процессы держат файл открытым, дисковое пространство освобождается тогда, когда последний из них закрывает файл.

Все это делает доступными следующие возможности.

• Можно иметь множество процессов, имеющих доступ к файлу, который не существует в файловой системе (такому, например, как канал).

• Можно создать файл на диске, удалить его вход в каталоге и продолжать выполнять чтение и запись файла.

• Можно изменить /tmp/foo и немедленно увидеть изменения в /tmp/bar, если оба имени файла ссылаются на один узел.

Система Unix всегда работала описанным образом, хотя эти операции и могут привести в замешательство новых пользователей и программистов. До тех пор, пока вы помните, что имя файла — это всего лишь указатель на дисковый узел, а сам узел — реальный ресурс, с вами все будет в порядке.

11.1. Режим файла

Каждый файл в системе имеет как тип (вроде неименованного канала или символьного устройства), так и набор прав доступа, определяющих, какие процессы могут иметь доступ к файлу. Тип файла и права доступа комбинируются в 16-битное значение (тип short в С), называемое режимом файла (file mode).

Младшие 12 бит режима файла представляют права, регламентирующие доступ к файлу, или модификаторы доступа. Они служат для множества функций. Наиболее важной функцией является возможность изменять идентификатор эффективного пользователя и идентификаторы групп файла при его выполнении.

Режим файла обычно записывается в виде шести восьмеричных разрядов. Представленные в восьмеричном виде, три младших разряда содержат модификаторы доступа файла, а два старших разряда указывают на его тип. Например, файл с режимом 0041777 имеет тип 04, модификатор прав 1 и биты доступа 0777[41]. Аналогично, файл с режимом 0100755 имеет тип 010, не имеет установленного модификатора доступа, а правами доступа к нему являются 0755.

11.1.1. Права доступа к файлу

Каждый из этих трех разрядов доступа представляет права для разных классов пользователей. Первый разряд — это права владельца файла, второй — права пользователей, входящих в группу, к которой относится файл, а последний разряд представляет права доступа для всех остальных пользователей. Каждый восьмеричный разряд образован из трех бит, представляющих права на чтение, на запись и на выполнение — от более значащего к менее значащему биту. Термин мировой доступ (world permission) обычно используется для обозначения прав, представленных всем трем классам пользователей.

Попробуем немного конкретизировать последний абзац с помощью нескольких примеров. Команда Linux chmod дает возможность пользователю специфицировать режим доступа в восьмеричном виде и затем применить его к одному или более файлам. Если имеется файл somefile, который мы хотим сделать доступным для записи только его владельцу, а всем пользователям (включая владельца) разрешить его чтение, мы должны использовать режим 0644 (помните, это восьмеричные цифры). Ведущая цифра 6 — это в двоичном виде 110, а это означает, что тип пользователя, к которому она относится (в данном случае — владелец), имеет право как читать, так и писать в файл; 4 в двоичном виде выглядит как 010, что дает остальным пользователям (членам группы и прочим) права только для чтения.

$ chmod 0644 somefile

$ ls -l somefile

-rw-r--r-- 1 ewt devel 31 Feb 15 15:12 somefile

Если мы хотим позволить любому члену группы devel писать в файл, то должны использовать режим 0664.

$ chmod 0664 somefile

$ ls -l somefile

-rw-rw-r-- 1 ewt devel 31 Feb 15 15:12 somefile

Если somefileсценарий оболочки (программы, которые используют #! в начале для указания командного интерпретатора), который мы хотим запускать на выполнение, необходимо сообщить системе, что файл является исполняемым, включив бит выполнения — в данном случае мы позволяем владельцу читать, писать и запускать файл, а членам группы devel — читать и запускать этот файл. Всем другим пользователям запрещено манипулировать файлом любым образом.

$ chmod 0750 somefile

$ ls -l somefile

-rwxr-x--- 1 ewt devel 31 Feb 15 15:12 somefile

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

Большинство системных каталогов на машинах Linux имеют права доступа 0755 и принадлежат пользователю root. Это дает возможность пользователям системы просматривать файлы в каталоге и получать доступ к ним по имени, но разрешает запись в каталоги только пользователю root. Анонимные ftp-сайты, которые позволяют любому пользователю отправлять файлы, но не дают возможность им загружать их до тех пор, пока администратор не просмотрит их содержимое, обычно устанавливают права на входящие каталоги в значение 0722. Это позволяет всем пользователям создавать новые файлы в каталоге, не предоставляя им возможность ни видеть содержимое каталога, ни получать доступа к файлам.

Дополнительную информацию о правах доступа к файлам можно найти в любой книге по Linux или Unix.

11.1.2. Модификаторы прав доступа к файлам

Модификаторы прав доступа файлов — это также битовые маски, значения которых представляют биты setuid, setgid и sticky-бит ("липкий" бит). Если бит setuid установлен для исполняемого файла, то эффективный идентификатор пользователя процесса устанавливается равным идентификатору владельца файла, когда программы выполняется (в главе 10 можно найти информацию о том, почему это удобно). Бит setgid ведет себя аналогичным образом, но устанавливает эффективный идентификатор группы в значение группы файла. Бит setuid не имеет значения для неисполняемых файлов, но если бит setgid устанавливается для неисполняемого файла, любая блокировка, выполняемая над файлом, носит обязательный, а не рекомендательный характер (см. главу 13). В Linux биты setuid и setgid игнорируются для сценариев оболочки, поскольку устанавливать setuid для сценариев было бы опасно.

Ни setuid, ни setgid не имеют очевидного смысла для каталогов. И setuid действительно не имеет семантики установки для каталогов. Если же для каталога установлен бит setgid, то все новые файлы, созданные в этом каталоге, будут принадлежать к той же группе, которая владеет самим каталогом. Это облегчает применение каталогов для организации совместной работы пользователей.

Sticky-бит — последний значащий бит в разряде модификатора доступа к файлу, имеет интересную историю, связанную с его наименованием. Старые реализации Unix должны были загружать в память всю программу целиком, прежде чем начать выполнять ее. Это означало, что крупные программы отнимали значительное время на запуск, что было довольно-таки неприятно. Если же программа имела установленный sticky-бит, то операционная система пыталась сохранить ее "привязанной" в памяти настолько долго, насколько возможно, даже когда эта программа не запущена, чтобы уменьшить время запуска. Хотя это было немного некрасиво, но работало достаточно хорошо с часто используемыми программами, такими как компилятор С. Современные реализации Unix, включая Linux, используют загрузку по требованию — кусочек за кусочком, что сделало sticky-бит излишним, поэтому Linux игнорирует его для обычных файлов.

Sticky-бит по-прежнему используется для каталогов. Обычно любой пользователь с правами записи в каталог может удалить любой файл в этом каталоге. Однако если sticky-бит каталога установлен, файлы могут быть удалены только пользователем-владельцем либо пользователем root. Такое поведение удобно, если каталог служит репозиторием для файлов, созданных многими пользователями, например, /tmp.

Последний раздел режима файла указывает тип файла. Он содержится в старших восьмеричных разрядах и не является битовой маской. Вместо этого значение этих разрядов равно специфическому типу файлов (04 означает каталог, 06 — блочное устройство). Тип файла устанавливается при его создании. Он никогда не может быть изменен, кроме как посредством удаления файла.

Включаемый файл <sys/stat.h> представляет символические константы для всех этих битов доступа, что делает код более читабельным. Пользователи Unix и Linux обычно чувствуют себя увереннее с восьмеричными представлениями режимов файла, поэтому обычно в программах используются восьмеричные представления непосредственно. В табл. 11.1 перечислены символические имена прав и модификаторов доступа к файлам.


Таблица 11.1. Константы прав доступа к файлам

Имя Значение Описание
S_ISUID 0004000 Программа является setuid-программой.
S_ISGID 0002000 Программа является setgid-программой.
S_ISVTX 0001000 Sticky-бит.
S_IRWXU 00700 Владелец файла имеет права на чтение, запись и выполнение.
S_IRUSR 00400 Владелец файла имеет права на чтение.
S_IWUSR 00200 Владелец файла имеет права на запись.
S_IXUSR 00100 Владелец файла имеет права на выполнение.
S_IRWXG 00070 Группа файла имеет права на чтение, запись и выполнение.
S_IRGRP 00040 Группа файла имеет права на чтение.
S_IWGRP 00020 Группа файла имеет права на запись.
S_IXGRP 00010 Группа файла имеет права на выполнение.
S_IRWXO 00007 Прочие пользователи имеют права на чтение, запись и выполнение.
S_IROTH 00004 Прочие пользователи имеют права на чтение.
S_IWOTH 00002 Прочие пользователи имеют права на запись.
S_IXOTH 00001 Прочие пользователи имеют права на выполнение.

11.1.3. Типы файлов

Старшие четыре бита режима файла указывают тип файла. В табл. 11.2 перечислены константы, имеющие отношение к типам файлов. Объединение с помощью битовой операции "И" любых этих констант с режимом файла порождает ненулевое значение, если бит установлен.


Таблица 11.2. Константы типов файлов

Имя Значение (восьмеричное) Описание
S_IFMT 00170000 Это значение, побитно объединенное с режимом с помощью операции "И", дает тип файла (который эквивалентен одному из остальных значений S_IF).
S_IFSOCK 0140000 Файл является сокетом.
S_IFLNK 0120000 Файл является символической ссылкой.
S_IFREG 0100000 Файл является обычным файлом.
S_IFBLK 0060000 Файл представляет блочное устройство.
S_IFDIR 0040000 Файл является каталогом.
S_IFCHR 0020000 Файл представляет символьное устройство.
S_IFIFO 0010000 Файл представляет коммуникационный канал "первый вошел — первый вышел".

Описанные ниже макросы принимают в качестве аргумента режим файла и возвращают true или false.

S_ISLINK(m) Истинно, если файл является символической ссылкой.
S_ISREC(m) Истинно, если файл является обычным файлом.
S_ISDIR(m) Истинно, если файл является каталогом.
S_ISCHR(m) Истинно, если файл представляет символьное устройство.
S_ISBLK(m) Истинно, если файл представляет блоковым устройство.
S_ISFIFO(m) Истинно, если файл является каналом "первый вошел — первый вышел"
S_ISSOCK(m) Истинно, если файл является сокетом.

11.1.4. Маска umask процесса

Права доступа, назначаемые вновь созданным файлам, зависят как от настроек системы, так и от предпочтений конкретного пользователя. Чтобы помочь индивидуальным программам, которые нуждаются в предположениях об использовании файла, система дает возможность пользователям отключить отдельные привилегии для вновь создаваемых файлов (и каталогов, которые являются специальными файлами). Каждый процесс имеет маску umask, определяющую отключенные биты привилегий для создания файлов. Это позволяет процессу специфицировать достаточно либеральные права (обычно это касается общих прав на чтение и запись) и обеспечивать права, которые пользователь предпочитает. Если определенный файл особо важен, процесс создания может включать назначение более ограниченных прав, чем обычно, потому что umask никогда не влияет на менее строгие ограничения прав, а только на более строгие.

Текущая установка umask для процесса выполняется системным вызовом umask().

#include <sys/stat.h>


int umask(int newmask);

Возвращается старое значение и устанавливается новое значение umask процесса. Для файла могут быть указаны только права на чтение, запись и исполнение — вы не можете использовать umask для запрещения установки setuid, setgid или sticky-бита. Команда umask представлена в большинстве командных процессоров и позволяет пользователю устанавливать umask для самой командной оболочки и всех его последующих дочерних процессов.

В качестве примера, команда touch создает новые файлы с правами 0666 (общие права на чтение и запись). Так как пользователю подобное редко подходит, он может заставить команду touch отключать общие и групповые права записи для файла с помощью команды umask 022, как показано ниже.

$ umask 022

$ touch foo

$ ls -l foo

-rw-r--r-- 1 ewt ewt 0 Feb 24 21:24 foo

Если он предпочитает давать права на запись группе, то может вместо этого назначит umask 002.

$ umask 002

$ touch foo

$ ls -l foo

-rw-rw-r-- 1 ewt ewt 0 Feb 24 21:24 foo

Если же он хочет, чтобы его файлы были доступны только ему, это обеспечит umask 077.

$ umask 077

$ touch foo

$ ls -l foo

-rw------- 1 ewt ewt 0 Feb 24 21:24 foo

umask процесса влияет на системные вызовы open(), creat(), mknod() и mkdir().

11.2. Основные файловые операции

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

11.2.1. Файловые дескрипторы

Когда процесс получает доступ к файлу (что обычно называют открытием файла), то ядро возвращает ему файловый дескриптор, который затем используется процессом для всех операций с файлом. Файловые дескрипторы — это маленькие положительные целые числа, которые служат индексами массива открытых файлов, создаваемого ядром для каждого процесса.

Первые три файловых дескриптора для процессов (0, 1 и 2) имеют стандартное назначение. Первый, 0, известен как стандартный ввод (stdin) и является местом, откуда программы должны получать свой интерактивный ввод. Файловый дескриптор 1 называется стандартным выводом (stdout), и большая часть вывода программ должна быть направлена в него. Сообщения об ошибках должны направляться в стандартный поток ошибок (stderr), который имеет файловый дескриптор 2. Стандартная библиотека С следует этим правилам, поэтому gets() и printf() используют stdin и stdout соответственно, и это соглашение дает возможность командным оболочкам правильно перенаправлять ввод и вывод процессов.

Заголовочный файл <unistd.h> представляет макросы STDIN_FILENO, STDOUT_FILENO и STDERR_FILENO, которые вычисляются как файловые дескрипторы stdin, stdout и stderr соответственно. Использование этих символических имен делает код более читабельным.

Многие из файловых операций, которые манипулируют файловыми узлами inode, доступны в двух формах. Первая форма принимает в качестве аргумента имя файла. Ядро использует этот аргумент для поиска inode файла и выполняет соответствующую операцию над ним (обычно это включает следование символическим ссылкам). Вторая форма принимает файловый дескриптор в качестве аргумента и выполняет операцию над inode, на который он ссылается. Эти два набора системных вызовов используют похожие имена, но системные вызовы, работающие с файловыми дескрипторами, имеют префикс f. Например, системный вызов chmod() изменяет права доступа для файла, ссылка на который осуществляется по имени; fchmod() устанавливает права доступа к файлу, ссылаясь на него по указанному файловому дескриптору.

Чтобы меньше тратить слов, мы представим обе версии системных вызовов, если они существуют, а обсуждать будет только первую из их (та, которая использует имена файлов).

11.2.2. Закрытие файлов

Одной из операций, которые одинаковы для файлов всех типов, является закрытие файла. Ниже показано, как закрыть файл.

#include <unistd.h>


int close(int fd);

Очевидно, что это базовая операция. Однако есть один важный момент, касающийся закрытия файлов, о котором следует помнить — она может завершиться сбоем. Некоторые системы (в первую очередь, следует вспомнить сетевые файловые системы вроде NFS) не пытаются поместить последнюю порцию записываемых данных в файл до тех пор, пока он не будет закрыт. Если такая операция вызовет сбой (например, по причине недоступности удаленного хоста), то close() вернет ошибку. Если ваше приложение пишет данные, но не синхронизирует записи (см. обсуждение O_SYNC в следующем разделе), то вы всегда должны проверять результат закрытия файла. Если close() дает сбой, то это значит, что обновленный файл поврежден самым непредсказуемым образом! К счастью подобное случается достаточно редко.

11.2.3. Открытие файлов в файловой системе

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

#include <fcntl.h>

#include <unistd.h>


int open(char *pathname, int flags, mode_t mode);

int creat(char *pathname, mode_t mode);

Функция open() возвращает файловый дескриптор, указывающий на pathname. Если возвращенное значение меньше нуля, значит, произошла ошибка (как всегда, errno содержит код ошибки). Аргумент flags описывает тип доступа, который нужен вызывающему процессу, а также управляет различными атрибутами открытия и манипулирования файлом. Режим доступа всегда должен быть указан, и он может быть одним из следующих: O_RDONLY, O_RDWR либо O_WRONLY, что запрашивает доступ, соответственно, только по чтению, по чтению и записи либо только по записи. С этим режимом может быть объединены логическим "И" следующие значения для управления прочей семантикой файлов.

O_CREAT Если файл еще не существует, создать его как обычный файл.
O_EXCL Этот флаг должен использоваться только с O_CREAT. Если он указан, то open() дает сбой в случае существования файла. Этот флаг позволяет реализовать простую блокировку, но не надежен при использовании в сетевых файловых системах типа NFS (подробно о блокировке файлов рассказывается в главе 13).
O_NOCTTY Открываемый файл не становится управляющим терминалом процесса (см. главу 10). Этот флаг имеет значение только тогда, когда процесс, не имеющий управляющего терминала, открывает устройство tty. Если же он указан в любом другом случае, этот флаг игнорируется.
O_TRUNC Если файл уже существует, его содержимое отбрасывается, и его размер устанавливается равным 0.
O_APPEND Все операции записи выполняются в конец файла, хотя произвольный доступ по чтению также разрешен.
O_NONBLOCK Файл открывается в неблокирующем режиме. Операции с нормальными файлами всегда блокируются, потому что они работают с локальными жесткими дисками, имеющими предсказуемое время отклика, но операции на некоторых типах файлов требуют непредсказуемого времени для завершения. Например, чтение из канала, в котором нет данных, блокирует процесс чтения до тех пор, пока данные в нем не появятся. Если же специфицирован флаг O_NONBLOCK, вызов read() вместо блокирования вернет ноль байт. Файлы, на операции с которыми может понадобиться непредсказуемый объем времени, называются медленными файлами. (Примечание. O_NDELAY — оригинальное имя O_NONBLOCK, теперь устаревшее.)
O_SYNC Обычно ядро перехватывает операции записи и сбрасывает их на физическое устройство тогда, когда это удобно. Хотя такая реализация значительно повышает производительность, появляется также возможность потери данных, чем в том случае, когда они немедленно пишутся на диск. Если при открытии файла указан флаг O_SYNC, то все изменения в файле сохраняются на диске перед тем, как ядро возвращает управления процессу, выполняющему запись. Это очень важно для некоторых приложений, таких как системы управления базами данных, в которых принудительная запись используется для предотвращения повреждения данных в случае сбоя системы.

Параметр mode указывает права доступа для файла, если он создается и если он модифицируется текущей установкой umask процесса. Если не указано O_CREAT, то mode игнорируется.

Функция creat() в точности эквивалентна следующему вызову:

open(pathname, O_CREAT | O_WRONLY | O_TRUNC, mode)

Мы не используем creat() в этой книге, потому что находим функцию open() более простой для чтения и понимания.

11.2.4. Чтение, запись и перемещение

Хотя есть несколько способов читать и писать файлы, мы обсудим здесь только простейшие из них[42]. Чтение и запись почти идентичны, поэтому рассмотрим их одновременно.

#include <unistd.h>

size_t read(int fd, void * buf, size_t length);

size_t read(int fd, const void * buf, size_t length);

Обе функции принимают файловый дескриптор fd, указатель на буфер buf и длину буфера length, read() читает из файлового дескриптора и помещает полученные данные в буфер; write() пишет length байт из буфера в файл. Обе функции возвращают количество переданных байт, или -1 в случае ошибки (это означает, что ничего не было прочитано или записано).

Теперь, когда мы описали эти системные вызовы, рассмотрим простой пример, создающий файл hw в текущем каталоге и записывающий в него строку "Добро пожаловать!".

 1: /* hwwrite.с */

 2:

 3: #include <errno.h>

 4: #include <fcntl.h>

 5: #include <stdio.h>

 6: #include <stdlib.h>

 7: #include <unistd.h>

 8:

 9: int main(void) {

10:  int fd;

11:

12:  /* открыть файл, создавая его, если он не существовал, и удаляя

13:     его содержимое в противном случае */

14:  if ((fd = open("hw", O_TRUNC | O_CREAT | O_WRONLY, 0644)) < 0) {

15:   perror("open");

16:   exit(1);

17:  }

18:

19:  /* магическое число 18 - это кол-во символов, которые

20:     будут записаны */

21:  if (write(fd, "Добро пожаловать!\n", 18) != 18) {

22:   perror("write");

23:   exit(1);

24:  }

25:

26:  close(fd);

27:

28:  return 0;

29: }

Ниже показано, что получится, если запустить hwwrite.

$ cat hw

cat: hw: No such file or directory

cat: hw: Файл или каталог не существует

$ ./hwwrite

$ cat hw

Добро пожаловать!

$

Для изменения этой программы, чтобы она читала файл, нужно просто изменить open(), как показано ниже, и заменить write() статической строки на read() в буфер.

open("hw", O_RDONLY);

Файлы Unix можно разделить на две категории: просматриваемые (seekable) и непросматриваемые (nonseekable)[43]. Непросматриваемые файлы представляют собой каналы, работающие в режиме "первый вошел — первый вышел" (FIFO), которые не поддерживают произвольное чтение или запись, их данные не могут быть перечитаны или перезаписаны. Просматриваемые файлы позволяют читать и писать в произвольное место файла. Каналы и сокеты являются не просматриваемыми файлами; блоковые устройства и обычные файлы являются просматриваемыми.

Поскольку FIFO — это непросматриваемые файлы, то, очевидно, что read() читает их с начала, a write() пишет в конец. С другой стороны, просматриваемые файлы не имеют очевидной точки для этих операций. Вместо этого здесь вводится понятие "текущего" положения, которое перемещается вперед после операции. Когда просматриваемый файл изначально открывается, текущее положение устанавливается в его начало, со смещением 0. Если затем из него читается 10 байт, то текущее положение перемещается в точку со смещением 10 от начала, а запись 5 байт переписывает данные, начиная с одиннадцатого байта в файле (то есть, со смещения 10, где расположена текущая позиция после чтения). После такой записи текущая позиция находится в позиции, смещенной на 15 относительно начала файла — сразу после перезаписанных данных.

Если текущая позиция совпадает с концом файла и процесс пытается читать их этого файла, то read() возвращает 0 вместо ошибки. Если же данные записываются в конец файла, то он растет с тем, чтобы вместить дополнительные данные, и его текущая позиция устанавливается в конец файла. Каждый файловый дескриптор отслеживает независимую текущую позицию[44] (она не хранится в файловом inode), поэтому если файл открыт множество раз множеством процессов, или несколько раз одним и тем же процессом, то чтения и записи, выполняемые через один дескриптор, никак не влияют на позиции чтения и записи, выполненные через другой дескриптор. Конечно, множественные операции записи могут повредить файл другими способами, поэтому блокировка определенного рода в такой ситуации может понадобиться.

Файлы, открытые с флагом O_APPEND ведут себя несколько иначе. Для таких файлов текущая позиция перемещается в конец файла перед тем, как ядро осуществит в него запись. После записи текущая позиция перемещается в конец записанных данных, как обычно. Для файлов, работающих в режиме только для добавления, это гарантирует, что текущая позиция файла всегда будет находиться в его конце немедленно после вызова write().

Приложения, которые хотят читать и писать данные с произвольного места файла, должны установить текущую позицию перед выполнением операции чтения или записи данных, используя lseek().

#include <unistd.h>


int lseek(int fd, off_t offset, int whence);

Текущая позиция для файла fd перемещается на offset байт относительно whence, где whence принимает одно из следующих значений:

SEEK_SET[45] Начало файла.

SEEK_CUR Текущая позиция в файле.

SEEK_END Конец файла.

Для SEEK_CUR и SEEK_END значение offset может быть отрицательным. В этом случае текущая позиция перемещается в сторону начала файла (от whence), а не в сторону конца. Например, приведенный ниже код перемещает текущую позицию на 5 байт назад от конца файла.

lseek(fd, -5, SEEK_END);

Системный вызов lseek() возвращает новую текущую позицию в файле относительно его начала, либо -1 в случае ошибки. То есть lseek(fd, 0, SEEK_END) — это просто способ определения размера файла, но следует убедиться, что вы сбросили текущую позицию, прежде чем читать из fd.

Хотя текущая позиция не разделяется другими процессами, которые одновременно имеют доступ к файлу[46], это не значит, что множество процессов могут безопасно осуществлять совместную запись в файл. Пусть имеется следующая последовательность.

Процесс A                Процесс B

lseek(fd, 0, SEEK_END);

                        lseek(fd, 0, SEEK_END);

                        write (fd, buf, 10);

write(fd, buf, 5);

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

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

Части файлов, которые "создаются" подобным образом, называют "дырками" (holes). Чтение из такой "дырки" в файле возвращает буфер, полный двоичных нулей, а запись в них может завершиться ошибкой по причине отсутствия свободного пространства на диске. Все это значит, что вызов lseek() не должен применяться для резервирования дискового пространства для позднейшего использования, поскольку такое пространство может быть и не выделено. Если ваше приложение нуждается в выделении некоторого дискового пространства для последующего использования, вы должны применять write(). Файлы с "дырками" часто используют для хранения редко расположенных в них данных, таких как файлы, представляющие хеш-таблицы.

Для простой демонстрации "дырок" в файлах, основанной на командной оболочке, рассмотрим следующий пример (/dev/zero — это символьное устройство, которое возвращает столько двоичных нулей, сколько процесс пытается прочитать из него).

$ dd if=/dev/zero of=foo bs=1k count=10

10+0 records in

10+0 records out

$ ls -l foo

-rw-rw-r-- 1 ewt ewt 10240 Feb 6 21:50 foo

$ du foo

10 foo

$ dd if=/dev/zero of=bar bs=1k count=1 seek=9

1+0 records in

1+0 records out

$ ls -l bar

-rw-rw-r-- 1 ewt ewt 10240 Feb 6 21:50 foo

$ du bar

1 bar

$

Хотя оба файла — и foo, и bar — имеют длину в 10 Кбайт, файл bar занимает только 1 Кбайт дискового пространства, потому что остальные 9 Кбайт были пропущены seek(), когда файл был создан или записан.

11.2.5. Частичное чтение и запись

Хотя обе функции — и read(), и write() — принимают параметр, указывающий, сколько байт нужно прочитать или записать, ни одна из них не гарантирует, что обработает указанное количество байт, даже если не случается никаких ошибок. Простейший пример этого — попытки чтения из обычного файла, который уже позиционирован в конце. Система не может прочитать ни одного байта, но это в то же время не является ошибкой. Вместо этого read() возвращает 0 байт. Точно так же, если текущая позиция находилась в 10 байт от конца файла, и была выполнена попытка прочитать из файла более 10 байт, то прочитано будет ровно 10 байт и вызов read() вернет число 10. Опять-таки это не рассматривается как ошибочная ситуация.

Поведение read() также зависит от того, был ли файл открыт с флагом O_NONBLOCK. Для файлов многих типов O_NONBLOCK не влияет ни на что. Файлы, для которых система может гарантировать завершенность операции в пределах разумного периода времени, всегда блокирует чтение и запись; такие файлы часто называют быстрыми файлами. Это множество файлов включает локальные блочные устройства и обычные файлы. Для других типов файлов, таких как каналы, и символьных устройств вроде терминалов процесс может ожидать другого процесса (или человека), чтобы тот либо выполнил чтение, либо освободил ресурсы системы при обработке запроса на write(). В обоих случаях система не имеет способа знать — будет ли вообще возможно дождаться завершения системного вызова. Когда такие файлы открываются с флагом O_NONBLOCK, то для каждой операции с файлом система просто делает максимум того, что удается сделать немедленно, а затем возвращает управление вызывающему процессу.

Неблокирующий ввод-вывод — это важная тема, и больше примеров вы найдете в главе 13. После стандартизации системного вызова poll(), однако, необходимость в нем (особенно при чтении) минимизирована. Если вам нужно интенсивно использовать неблокирующий ввод-вывод, попробуйте пересмотреть свою программу в терминах poll(), чтобы увидеть, нельзя ли ее сделать более эффективной.

Чтобы показать конкретный пример чтения и записи файлов, приведем простую реализацию cat. Она копирует стандартный поток ввода (stdin) на стандартный вывод (stdout) до тех пор, пока есть что копировать.

 1: /* cat.с */

 2:

 3: #include <stdio.h>

 4: #include <unistd.h>

 5:

 6: /* Пока есть данные на стандартном входе (fd0), копировать их в

 7:    стандартный выход (fd1). Выйти, когда не будет доступных данных. */

 8:

 9: int main(void) {

10:  char buf[1024];

11:  int len;

12:

13:  /* len будет >= 0, пока доступны данные

14:     и read() успешен */

15:  while ((len = read(STDIN_FILENO, buf, sizeof(buf))) > 0) {

16:   if (write(1, buf, len) != len) {

17:    perror("write");

18:    return 1;

19:   }

20:  }

21:

22:  /* len будет <= 0; если len = 0, больше нет

23:     доступных данных. Иначе - ошибка. */

24:  if (len < 0) {

25:   perror("read");

26:   return 1;

27:  }

28:

29:  return 0;

30: }

11.2.6. Сокращение файлов

Хотя обычные файлы автоматически растут при записи данных в их конец, у системы нет способа автоматически усекать файлы, когда данные в конце не нужны. К тому же, как система может узнать, что данные стали излишними? Это находится в компетенции процесса — извещать систему о том, когда файл можно сократить до определенной точки.

#include <unistd.h>


int truncate(const char *pathname, size_t length);

int ftruncate(int fd, size_t length);

Размер файла устанавливается равным length, и все данные, находящиеся за новым концом файла, теряются.

Если length больше текущего размера файла, то файл увеличивается до заданного размера (по возможности используя "дырки"), хотя такое поведение и не гарантируется POSIX, поэтому на него нельзя полагаться при написании переносимых программ.

11.2.7. Синхронизация файлов

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

Есть несколько механизмов, которые может использовать приложение, чтобы дождаться записи данных на физический носитель. Флаг O_SYNC, описанный ранее в этой главе, при каждой операции записи в файл вызывает блокирование вызывающего процесса до тех пор, пока носитель не будет действительно обновлен. Хотя это, конечно, работает, все же такой подход не является достаточно аккуратным. Обычно приложения не нуждаются в том, чтобы все операции были синхронизированы, гораздо чаще они нуждаются в том, чтобы гарантировать, что некий набор операций завершился перед тем, как может быть начат другой набор операций. Системные вызовы fsync() и fdatasync() обеспечивают такую семантику.

#include <unistd.h>


int fsync(int fd);

int fdatasync(int fd);

Оба системных вызова приостанавливают приложение до тех пор, пока в файл fd не будут записаны все данные, fsync() также ожидает обновления информации в inode файла, подобной времени доступа (информация inode для файлов перечислена в табл. 11.3). Однако ни один из этих вызовов не гарантирует записи на неразрушимое устройство хранения. Современные дисковые приводы имеют большие собственные кэши, поэтому сбой питания может привести к тому, что некоторые данные, сохраненные в кэше, будут потеряны.

11.2.8. Прочие операции

Файловая модель Linux достаточно хорошо поддерживает стандартизацию большинства файловых операций через обобщенные функции наподобие read() и write() (например, запись в программный канал выполняется так же, как запись в файл на диске). Однако некоторые устройства поддерживают операции, которые плохо моделируются такой абстракцией. Например, терминальные устройства, представленные как устройства символьные, нуждаются в представлении метода изменения скорости терминала, и приводы CD-ROM, представленные как блочные устройства, нуждаются в том, чтобы знать, кода они должны воспроизводить аудиодорожки, чтобы помочь увеличить производительность работы программистов.

Все эти разнообразные операции доступны через единственный системный вызов — ioctl() (сокращение для "I/O control" — управление вводом-выводом), прототип которого показан ниже.

#include <sys/ioctl.h>


int ioctl(int fd, int request, ...);

Хотя часто он применяется следующим образом:

int ioctl (int fd, int request, void *arg);

Всякий раз когда используется ioctl(), его первый аргумент — это файл, с которым выполняются манипуляции, а второй аргумент указывает операцию, которая должна быть выполнена. Последний аргумент обычно представляет собой указатель на нечто, но на что именно, а так же точная семантика возвращаемого кода зависит от типа файла fd и типа запрошенной операции. Для некоторых операций arg — длинное целое вместо указателя; в этих случаях обычно применяется приведение типов. В нашей книге есть множество примеров применения ioctl(), и вам нет нужды заботиться об ioctl() до тех пор, пока вы не доберетесь до них.

11.3. Запрос и изменение информации inode

11.3.1. Поиск информации inode

В начале этой главы информационный узел файла (inode) был представлен как структура данных, которая отслеживает информацию о файле, независимо от представления ее для процесса. Например, размер файла является константой в любой момент времени — он не изменяется для разных процессов, которые имеют доступ к этому файлу (сравните это с текущей позицией в файле, которая уникальна для каждого вызова open(), а не свойство самого файла). Linux предлагает три способа чтения информации inode.

#include <sys/stat.h>


int stat(const char *pathname, struct stat *statbuf);

int lstat (const char *pathname, struct stat *statbuf);

int fstat(int fd, struct stat *statbuf);

Первая версия, stat() возвращает информацию inode для файла, на который осуществляется ссылка через pathname, следуя всем символическим ссылкам, которые она представляет. Если вы не хотите следовать символическим ссылкам (например, чтобы проверить, не является ли само имя такой ссылкой), то используйте вместо этого lstat(). Последняя версия, fstat(), возвращает inode, на который ссылается текущий открытый файловый дескриптор. Все три системных вызова заполняют структуру struct stat, на которую указывает параметр statbuf, информацией о файловом inode. В табл. 11.3 описана информация, доступная в struct stat.


Таблица 11.3. Члены структуры struct stat

Тип Поле Описание
dev_t st_dev Номер устройства, на котором находится файл.
ino_t st_ino Номер файлового on-disk inode. Каждый файл имеет номер on-disk inode, уникальный в пределах устройства, на котором он расположен. То есть пара (st_dev, st_ino) представляет собой уникальный идентификатор файла.
mode_t st mode Режим файла. Сюда включена информация о правах доступа и типе файла.
nlink_t st_nlink Количество путевых имен, ссылающихся на данный inode. Сюда не включаются символические ссылки, потому что они ссылаются на другие имена, а не на inode.
uid_t st_uid Идентификатор пользователя, владеющего файлом.
gid_t st_gid Идентификатор группы, владеющей файлом.
dev_t st_rdev Если файл — символьное или блочное устройство, это задает старший (major) и младший (minor) номера файла. Чтобы получить информацию о членах и макросах, которые манипулируют этим значением, обратитесь к обсуждению mknod() далее в этой главе.
off_t st size Размер файла в байтах. Это определено только для обычных файлов.
unsigned long st_blksize Размер блока в файловой системе, хранящей файл.
unsigned long st_blocks Количество блоков, выделенных файлу. Обычно st_blksize * st_blocks — это немного больше, чем st_size, потому что некоторое пространство в конечном блоке не используется. Однако для файлов с "дырками" st_blksize * st_blocks может быть заметно меньше, чем st_size.
time_t st_atime Время последнего доступа к файлу. Обновляется при каждом открытии файла или модификации его inode.
time_t st_mtime Время последней модификации файла. Обновляется при изменении данных файла.
time_t st_ctime Последнее время изменения файла или его inode, включая владельца, группу, счетчик связей и так далее.

11.3.2. Простой пример stat()

Рассмотрим простую программу, которая отображает информацию из lstat() для каждого имени файла, переданного в аргументе. Она иллюстрирует, как использовать значения, возвращенные семейством функций stat().

 1: /* statsamp.с */

 2:

 3: /* Для каждого имени файла, переданного в командной строке, отображаем

 4:    всю информацию, которую возвращает lstat() для файла. */

 5:

 6: #include <errno.h>

 7: #include <stdio.h>

 8: #include <string.h>

 9: #include <sys/stat.h>

10: #include <sys/sysmacros.h>

11: #include <sys/types.h>

12: #include <time.h>

13: #include <unistd.h>

14:

15: #define TIME_STRING_BUF 50

16:

17: /* Пользователь передает buf (минимальной длины TIME_STRING_BUF) вместо

18:    использования статического для функции буфера, чтобы избежать применения

19:    локальных статических переменных и динамической памяти. Никаких ошибок

20:    происходить не должно, поэтому никакой проверки ошибок не делаем. */

21: char *time String (time_t t, char *buf) {

22:  struct tm *local;

23:

24:  local = localtime(&t);

25:  strftime(buf, TIME_STRING_BUF, "%c", local);

26:

27:  return buf;

28: }

29:

30: /* Отобразить всю информацию, полученную от lstat() по имени

31:    файла как единственному параметру. */

32: int statFile(const char *file) {

33:  struct stat statbuf;

34:  char timeBuf[TIME_STRING_BUF];

35:

36:  if (lstat(file, &statbuf)) {

37:   fprintf(stderr, "не удалось lstat %s: %s\n", file,

38:    strerror(errno));

39:   return 1;

40:  }

41:

42:  printf("Имя файла : %s\n", file);

43:  printf("На устройстве: старший %d/младший %d Inode номер: %ld\n" ,

44:   major(statbuf.st_dev), minor(statbuf.st_dev),

45:   statbuf.st_ino);

46:  printf ("Размер : %-101d Тип: %07o"

47:   "Права доступа : %05o\n", statbuf.st_size,

48:   statbuf.st_mode & S_IFMT, statbuf.st_mode &~(S_IFMT));

49:  printf("Владелец : %d Группа : %d"

50:   " Количество ссылок : %d\n",

51:   statbuf.st_uid, statbuf.st_gid, statbuf.st_nlink);

52:  printf("Время создания : %s\n",

53:   timeString(statbuf.st_ctime, timeBuf));

54:  printf("Время модификации : %s\n",

55:   timeString(statbuf.st_mtime, timeBuf));

56:  printf("Время доступа : %s\n",

57:   timeString (statbuf.st_atime, timeBuf));

58:

59:  return 0;

60: }

61:

62: int main(int argc, const char **argv) {

63:  int i;

64:  int rc = 0 ;

65:

66:  /* Вызвать statFile() для каждого имени файла,

67:     переданного в командной строке. */

68:  for (i = 1; i < argc; i++) {

69:   /* Если statFile() сбоит, rc будет содержать не ноль.*/

70:   rc |= statFile(argv[i]);

71:

72:   /* это печатает пробел между позициями,

73:      но не за последней */

74:   if ((argc - i) > 1) printf ("\n");

75:  }

76:

77:  return rc;

78: }

11.3.3. Простое определение прав доступа

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

#include <unistd.h>


int access(const char *pathname, int mode);

mode — это маска, которая содержит одно или более перечисленных ниже значений.

F_OK Файл существует. Это требует прав на выполнение по всем каталогам, составляющим путь, поэтому может закончиться сбоем, даже если файл существует.
R_OK Процесс может читать файл.
W_OK Процесс может писать файл.
X_OK Процесс может исполнять файл (или искать в каталоге).

access() возвращает 0, если указанный режим доступа разрешен, в противном случае возвращает ошибку EACCESS.

11.3.4. Изменение прав доступа к файлу

Права доступа и модификаторы прав доступа к файлу изменяются с помощью системного вызова chmod().

#include <sys/stat.h>


int chmod(const char *pathname, mode_t mode);

int fchmod(int fd, mode_t mode);

Хотя chmod() позволяет указать путь, помните, что права доступа к файлу определяет inode, а не имя файла. Если у файла есть множество жестких ссылок, то изменение прав доступа по одному из имен файла изменяет права доступа к нему везде, где он встречается в файловой системе. Параметр mode может быть любой комбинацией прав доступа и модификаторов прав доступа, объединенных по логическому "И". Хотя это достаточно нормально — специфицировать по несколько этих значений за раз, общей практикой для программ является указание новых прав доступа непосредственно в восьмеричном виде. Только пользователь root и владелец файла могут изменять права доступа к файлу — все остальные, кто попытается это сделать, получат ошибку EPERM.

11.3.5. Смена владельца и группы файла

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

#include <unistd.h>


int chown(const char *pathname, uid_t owner, gid_t group);

int fchown(int fd, uid_t owner, gid_t group);

Параметры owner и group указывают нового владельца и группу для файла. Если любой из них равен -1, соответствующее значение не изменяется. Только пользователь root имеет право сменить владельца файла. Когда владелец файла меняется или файл записывается, то бит setuid для этого файла всегда очищается из соображений безопасности. Как root, так и владелец файла могут менять группу, которая владеет файлом, но при условии, что владелец сам является членом этой группы. Если у файла установлен бит выполнения для группы, то бит setgid очищается из тех же соображений безопасности. Если же бит выполнения для группы не установлен, то у файла включена принудительная блокировка и режим предохраняется.

11.3.6. Изменение временных меток файла

Владелец файла может изменять mtime и atime файла на любое желаемое значение. Это делает такие метки бесполезными для целей аудита, но позволяет инструментам архивирования вроде tar и cpio сбрасывать временные метки файлов в то значение, когда они были архивированы. Метка ctime изменяется, когда обновляются mtime и atime, поэтому tar и cpio не могут восстановить их.

Существуют два способа изменения этих меток: utime() и utimes(). utime() появилась в System V, после чего была адаптирована POSIX, в то время как utimes() пришла из BSD. Обе функции эквивалентны; они отличаются только способом, каким указываются новые временные метки.

#include <utime.h>

int utime(const char *pathname, struct utimbuf *buf);


#include <sys/time.h>

int utimes(const char *pathname, struct timeval *tvp);

Версия POSIX, utime(), принимает struct utimbuf, которая определена в <utime.h>, как показано ниже.

struct utimbuf {

 time_t асtime;

 time_t modtime;

};

utimes() из BSD вместо этого передает новое значение atime и mtime через struct timeval, которая определена в <sys/time.h>.

struct timeval {

 long tv_sec;

 long tv_usec;

};

Элемент tv_sec содержит новое значение atime; tv_usec содержит новое значение mtime для utimes().

Если каждой из функций вторым параметром передать NULL, то обе временные метки должны быть установлены в текущее время. Новые значения atime и mtime устанавливаются в секундах, прошедших с начала эры (так же, как значение, возвращаемое time()), как определено в главе 18.

11.3.7. Расширенные атрибуты Ext3

Главная файловая система, используемая в Linux — это Third Extended File System (третья расширенная файловая система)[47], обычно упоминаемая как ext3. Хотя она поддерживает все традиционные функциональные средства файловых систем Unix, такие как значение отдельных бит в режиме файла, она также позволяет хранить некоторые дополнительные атрибуты для каждого файла. В табл. 11.4 описаны поддерживаемые в настоящее время дополнительные атрибуты. Эти флаги могут быть установлены и просмотрены с помощью программ chattr и lsattr.


Таблица 11.4. Расширенные атрибуты файла

Атрибут Определение
EXT3_APPEND_FL Если файл открыт для записи, должен быть указан флаг O_APPEND.
EXT3_IMMUTABLE_FL Файл не может быть модифицирован или удален ни одним пользователем, включая root.
EXT3_NODUMP Файл должен быть проигнорирован командой dump.
EXT3_SYNC_FL Файл должен обновляться синхронно, как если бы при открытии был указан флаг O_SYNC

Поскольку расширенные атрибуты ext3 выходят за пределы стандартного интерфейса файловых систем, они не могут модифицироваться с помощью chmod(), как все остальные атрибуты. Вместо этого используется ioctl(). Вспомним, как определен вызов ioctl().

#include <sys/ioctl.h>

#include <linux/ext3_fs.h>


int ioctl(int fd, int request, void *arg);

Файл, атрибуты которого меняются, должен быть открыт, как для fchmod(). Запрос (параметр request) на получение текущего состояния флагов — EXT3_IOC_GETFLAGS, а для установки их — EXT3_IOC_SETFLAGS. В обоих случаях arg должен быть указателем на int. Если используется EXT3_IOC_GETFLAGS, то long устанавливается в текущее значение программных флагов. Если применяется EXT3_IOC_SETFLAGS, то новое значение файловых флагов берется из int, на который указывает arg.

Это дополнение и неизменяемые флаги могут быть изменены только пользователем root, поскольку это связано с операциями, которые может выполнять только root.

Другие флаги могут быть модифицированы либо пользователем root, либо владельцем файла.

Приведем пример небольшой программы, которая отображает флаги для любого файла, переданного в командной строке. Она работает только с файлами из файловой системы ext3[48]. Вызов ioctl() завершится неудачей, если применить его к файлам из любой другой файловой системы.

 1: /* checkflags.c */

 2:

 3: /* Для каждого имени файла, переданного в командной строке, отобразить

 4:    информацию об атрибутах этого файла в файловой системе ext3. */

 5:

 6: #include <errno.h>

 7: #include <fcntl.h>

 8: #include <linux/ext3_fs.h>

 9: #include <stdio.h>

10: #include <string.h>

11: #include <sys/ioctl.h>

12: #include <unistd.h>

13:

14: int main(int argc, const char **argv) {

15:  const char **filename = argv + 1;

16:  int fd;

17:  int flags;

18:

19:  /* Пройти по каждому имени файла, переданному в командной строке. Последний

20:     указатель в argv[] равен NULL, поэтому такие циклы while() корректны. */

21:  while(*filename) {

22:   /* В отличие от нормальных атрибутов, атрибута ext3 можно опрашивать только

23:      если есть файловый дескриптор (имя файла не годится).

24:      Для выполнения запроса атрибутов ext3 нам не нужен доступ на запись,

25:      поэтому O_RDONLY подойдет. */

26:   fd = open(*filename, O_RDONLY);

27:   if (fd<0) {

28:    fprintf(stderr, "не открывается %s: %s\n", *filename,

29:     strerror(errno));

30:    return 1;

31:   }

32:

33:   /* Этот вызов получает атрибуты, и помещает их в flags */

34:   if (ioctl(fd, EXT3_IOC_GETFLAGS, &flags)) {

35:    fprintf(stderr, "ioctl завершился ошибкой на %s: %s\n", *filename,

36:     strerror(errno));

37:    return 1;

38:   }

39:

40:   printf("%s: ", *filename++);

41:

42:   /* Проверить каждый атрибут, и отобразить сообщение для каждого,

43:      который включен. */

44:   if (flags & EXT3_APPEND_FL) printf("Append");

45:   if (flags & EXT3_IMMUTABLE_FL) printf("Immutable");

46:   if (flags & EXT3_SYNC_FL) printf("Sync");

47:   if (flags & EXT3_NODUMP_FL) printf("Nodump");

48:

49:   printf("\n");

50:   close(fd);

51:  }

52:

53:  return 0;

54: }

Ниже приведена похожая программа, которая устанавливает расширенные атрибуты ext3 для указанного списка файлов. Первый параметр должен быть списком флагов, которые нужно установить. Каждый флаг представляется в списке в виде одной буквы: А — только для добавления (append only), I — неизменяемый (immutable), S — синхронизированный (sync), N — недампированный (nodump). Эта программа не модифицирует существующие флаги файла; она только устанавливает флаги, переданные в командной строке.

 1: /* setflags.c */

 2:

 3: /* Первый параметр этой программы — строка, состоящая из

 4:    0 (допускается пустая) или более букв из набора I, A, S,

 5:    N. Эта строка указывает, какие из атрибутов ext3 должны

 6:    быть включены для файлов, указанных в остальных

 7:    параметрах командной строки — остальные атрибуты выключаются

 8:    буквы обозначают соответственно: immutable, append-only, sync и nodump.

 9:

10:    Например, команда "setflags IN file1, file2" включает

11:    флаги immutable и nodump для файлов file1 и file2, но отключает

12:    флаги sync и append-only для этих файлов. */

13:

14: #include <errno.h>

15: #include <fcntl.h>

16: #include <linux/ext3_fs.h>

17: #include <stdio.h>

18: #include <string.h>

19: #include <sys/ioctl.h>

20: #include <unistd.h>

21:

22: int main(int argc, const char **argv) {

23:  const char **filename = argv + 1;

24:  int fd;

25:  int flags = 0;

26:

27:  /* Убедиться, что указаны устанавливаемые флаги, вместе

28:     с именами файлов. Позволить установить "0", как признак

29:     того, что все флаги должны быть сброшены. */

30:  if (argc<3){

31:   fprintf(stderr, "Использование setflags: [0][I][A][S][N]"

32:    "<filenames>\n");

33:   return 1;

34:  }

35:

36:  /* каждая буква представляет флаг; установить

37:     флаг, которые указаны */

38:  if (strchr(argv[1], 'I') ) flags |= EXT3_IMMUTABLE_FL;

39:  if (strchr(argv[1], 'A') ) flags |= EXT3_APPEND_FL;

40:  if (strchr(argv[1], 'S') ) flags |= EXT3_SYNC_FL;

41:  if (strchr(argv[1], 'N') ) flags |= EXT3_NODUMP_FL;

42:

43:  /* пройти по всем именам в argv[] */

44:  while (*(++filename)) {

45:   /* В отличие от нормальных атрибутов, атрибута ext3 можно опрашивать,

46:      только если есть файловый дескриптор (имя файла не годится).

47:      Для выполнения запроса атрибутов ext3 нам не нужен доступ на запись,

48:      поэтому O_RDONLY подойдет. */

49:   fd = open(*filename, O_RDONLY);

50:   if (fd < 0) {

51:    fprintf(stderr, "невозможно открыть %s:%s\n", *filename,

52:     strerror(errno));

53:    return 1;

54:   }

55:

56:   /* Установить атрибуты в соответствии с переданными

57:      флагами. */

58:   if (ioctl(fd, EXT3_IOC_SETFLAGS, &flags)) {

59:    fprintf(stderr, "Сбой ioctl в %s:%s\n", *filename,

60:     strerror(errno));

61:    return 1;

62:   }

63:   close(fd);

64:  }

65:

66:  return 0;

67: }

11.4. Манипулирование содержимым каталогов

Вспомните, что компоненты каталогов (имена файлов) — это ни что иное, как указатели на дисковые информационные узлы (on-disk inodes); почти вся важная информация, касающаяся файла, хранится в его inode. Вызов open() позволяет процессу создавать компоненты каталогов, которые являются обычными файлами, но для создания файлов других типов и для манипулирования компонентами каталогов могут понадобиться другие функции. Функции, которые позволяют создавать, удалять и выполнять поиск каталогов, описаны в главе 14; файлы сокетов — в главе 17. В настоящем разделе раскрываются символические ссылки, файлы устройств и FIFO.

11.4.1. Создание входных точек устройств и именованных каналов

Процессы создают файлы устройств и именованных каналов в файловой системе с помощью вызова mknod().

#include <fcntl.h>

#include <unistd.h>


int mknod(const char *pathname, mode_t mode, dev_t dev);

pathname — это имя файла, который нужно создать, mode — это и режим доступа (который модифицируется текущим umask), и тип нового файла (S_IFIFO, S_IFBLK, S_IFCHR). Последний параметр, dev, содержит старший (major) и младший (minor) номера создаваемого устройства. Тип устройства (символьное или блочное) и старший номер устройства сообщают ядру, какой драйвер устройств отвечает за операции с этим файлом устройства. Младший номер используется внутри драйвером устройства, чтобы различать отдельные устройства среди многих, которыми он управляет. Только пользователю root разрешено создавать файлы устройств; именованные же каналы могут создавать все пользователи.

Заголовочный файл <sys/sysmacros.h> представляет три макроса для манипулирования значениями типа dev_t. Макрос makedev() принимает старшие номера в первом аргументе, младшие — во втором и возвращает значение dev_t, ожидаемое mknod(). Макросы major() и minor() принимают значение типа dev_t в качестве единственного аргумента и возвращают, соответственно, старший и младший номер устройства.

Программа mknod, доступная в Linux, предоставляет пользовательский интерфейс к системному вызову mknod() (подробности см. в man 1 mknod). Ниже приведена упрощенная реализация mknod для иллюстрации системного вызова mknod(). Следует отметить, что программа создает файл с режимом доступа 0666 (предоставляя право на чтение и запись всем пользователям) и зависит от системной установки umask процесса для получения прав доступа.

 1: /* mknod.с */

 2:

 3: /* Создать устройство или именованный канал, указанный в командной строке.

 4:    См. подробности о параметрах командной строки

 5:    на man-странице mknod(1). */

 6:

 7: #include <errno.h>

 8: #include <stdio.h>

 9: #include <stdlib.h>

10: #include <string.h>

11: #include <sys/stat.h>

12: #include <sys/sysmacros.h>

13: #include <unistd.h>

14:

15: void usage(void) {

16:  fprintf (stderr, "использование: mknod <путь> [b | с | u | p]"

17:   "<старший> <младший>\n");

18:  exit(1);

19: }

20:

21: int main(int argc, const char **argv) {

22:  int major = 0, minor = 0;

23:  const char *path;

24:  int mode = 0666;

25:  char *end;

26:  int args;

27:

28:  /* Всегда необходимы, как минимум, тип создаваемого inode

29:     и путь к нему. */

30:  if (argc < 3) usage();

31:

32:  path = argv[1];

33:

34:  /* второй аргумент указывает тип создаваемого узла */

35:  if (!strcmp(argv[2], "b")) {

36:   mode | = S_IFBLK;

37:   args = 5;

38:  } else if (!strcmp(argv[2] , "с") || !strcmp(argv[2], "u")) {

39:   mode |= S_IFCHR;

40:   args = 5;

41:  } else if(!strcmp(argv[2], "p")) {

42:   mode |= S_IFIFO;

43:   args = 3;

44:  } else {

45:   fprintf(stderr, "неизвестный тип узла %s\n", argv[2]);

46:   return 1;

47:  }

48:

49:  /* args сообщает, сколько аргументов ожидается, поскольку нам нужно

50:    больше информации при создания устройств, чем именованных каналов*/

51:  if (argc != args) usage();

52:

53:  if (args == 5) {

54:   /* получить старший и младший номера файла устройств,

55:      который нужно создать */

56:   major = strtol(argv[3], &end, 0);

57:   if (*end) {

58:    fprintf(stderr,"неверный старший номер %s\n", argv[3]);

59:    return 1;

60:   }

61:

62:   minor = strtol(argv[4], &end, 0);

63:   if (*end) {

64:    fprintf(stderr, "неверный младший номер %s\n", argv[4]);

65:    return 1;

66:   }

67:  }

68:

69:  /* если создается именованный канал, то финальный параметр

70:     игнорируется */

71:  if (mknod(path, mode, makedev(major, minor))) {

72:   fprintf(stderr, "вызов mknod не удался : %s\n", strerror(errno));

73:   return 1;

74:  }

75:

76:  return 0;

77: }

11.4.2. Создание жестких ссылок

Когда множество имен файлов в файловой системе ссылаются на единственный inode, такие файлы называют жесткими ссылками (hard links) на него. Все эти имена должны располагаться на одном физическом носителе (обычно это значит, что они должны быть на одном устройстве). Когда файл имеет множество жестких ссылок, все они равны — нет способа узнать, с каким именем первоначально был создан файл. Одно из преимуществ такой модели заключается в том, что удаление одной жесткой ссылки не удаляет файл с устройства — он остается до тех пор, пока все ссылки на него не будут удалены. Системный вызов link() связывает новое имя файла с существующим inode.

#include <unistd.h>


int link(const char *origpath, const char *newpath);

Параметр origpath ссылается на существующее путевое имя, a newpath представляет собой путь для новой жесткой ссылки. Любой пользователь может создавать ссылку на файл, к которому у него есть доступ по чтению, до тех пор, пока он имеет право записи в каталоге, в котором ссылка создается, и право выполнения в каталоге, в котором находится origpath. Только пользователь root имеет право создавать жесткие ссылки на каталоги, но поступать так — обычно плохая идея, поскольку большинство файловых систем и некоторые утилиты не работают с ними достаточно хорошо — они полностью их отвергают.

11.4.3. Использование символических ссылок

Символические ссылки — это более гибкий тип ссылок, чем жесткие, но они не дают равноправного доступа к файлу, как это делают жесткие. В то время как жесткие ссылки разделяют один и тот же inode, символические ссылки просто указывают на другие имена файлов. Если файл, на который указывает символическая ссылка, удаляется, то она указывает на несуществующий файл, что приводит к появлению висячих ссылок. Использование символических ссылок между подкаталогами — обычная практика, и они могут также пересекать границы физических систем, чего не могут жесткие ссылки.

Почти все системные вызовы, которые обращаются к файлам по путевым именам, автоматически следуют по символическим ссылкам для поиска правильного inode. Ниже перечислены вызовы, которые не следуют по символическим ссылкам.

chown()

lstat()

readlink()

rename()

unlink()

Символически ссылки создаются почти так же, как жесткие, но при этом используется системный вызов symlink().

#include <unistd.h>


int symlink(const char *origpath, const char *newpath);

Если вызов успешен, создается файл newpath как символическая ссылка, указывающая на oldpath (часто говорят, что newpath содержит в качестве своего значения oldpath).

Поиск значения символической ссылки немного сложнее.

#include <unistd.h>


int readlink(const char *pathname, char *buf, size_t bufsiz);

Буфер, на который указывает buf, наполняется содержимым символической ссылки pathname до тех пор, пока хватает длины buf, указанной в bufsize в байтах. Обычно константы PATH_MAX применяется в качестве размера буфера, поскольку она должна быть достаточно большой, чтобы уместить содержимое любой символической ссылки[49]. Одна странность функции readlink() связана с тем, что она не завершает строку, которую записывает в buf, символом '\0', поэтому buf не содержит корректную строку С, даже если readlink() выполняется успешно. Вместо этого она возвращает количество байт, записанных в buf в случае успеха и -1 — при неудаче. Из-за этой особенности код, использующий readlink(), часто выглядит так, как показано ниже.

char buf[PATH_MAX + 1];

int bytes;

if ( (bytes = readlink (pathname, buf, sizeof (buf) - 1)) < 0) {

 perror("ошибка в readlink");

} else {

 buf[bytes]= '\0';

}

11.4.4. Удаление файлов

Удаление файла — это удаление указателя на его inode и удаление содержимого файла, если не остается ни одой жесткой ссылки на него. Если любой процесс держит файл открытым, то inode этого файла предохраняется до тех пор, пока финальный процесс не закроет его, после чего и inode, и содержимое файла уничтожаются. Поскольку нет способа принудительно удалить файл немедленно, эта операция называется разъединением (unlinking) файла, поскольку она удаляет связь между именем файла и inode.

#include <unistd.h>


int unlink(char *pathname);

11.4.5. Переименование файлов

Имя файла может быть изменено на любое другое до тех пор, пока оба имени относятся к одному и тому же физическому носителю (это то же ограничение, что и касается создания жестких ссылок). Если новое имя уже ссылается на файл, то такое имя разъединяется перед тем, как произойдет переименование. Атомарность системного вызова rename() гарантируется. Другие процессы в системе всегда видят существование файла под тем или иным именем, но не под обеими сразу. Поскольку открытые файлы не связаны с именами (а только с inode), то переименование файла, который открыт в других процессах, никак не влияет на их работу. Ниже показано, как выглядит системный вызов для переименования файлов.

#include <unistd.h>


int rename(const char *oldpath, const char *newpath);

После вызова файл, на который ссылалось имя oldpath, получает ссылку newpath вместо oldpath.

11.5. Манипуляции файловыми дескрипторами

Почти все связанные с файлами системные вызовы, о которых мы говорили, за исключением lseek(), манипулируют inode файлов, что позволяет разделять их результаты между процессами, в которых этот файл открыт. Есть несколько системных вызовов, которые вместо этого имеют дело с самим файловыми дескрипторами. Системный вызов fcntl() может использоваться для множества манипуляций с файловыми дескрипторами. fcntl() выглядит следующим образом.

#include <unistd.h>


int fcntl (int fd, int command, long arg);

Для многих команд arg не используется. Ниже мы обсудим большую часть применений fcntl(). Этот вызов используется для блокировки файлов, аренды файлов, неблокирующего ввода-вывода, который рассматривается в главе 13, а также уведомления об изменениях каталогов, представленного в главе 14.

11.5.1. Изменение режима доступа к открытому файлу

Режим добавления (указываемый флагом O_APPEND при открытии файла) и неблокирующий режим (флаг O_NONBLOCK), могут быть включены и отключены уже после того, как файл был открыт, с помощью команды F_SETFL в fcntl(). Параметр arg при этом должен содержать флаги, которые нужно установить — если какой-то из флагов не указан для fd, он отключается.

F_GETFL можно использовать для запроса текущих установленных флагов файла. Это возвращает все флаги, включая режим чтения/записи для открытого файла. F_SETFL позволяет только устанавливать упомянутые выше флаги — любые другие флаги, представленные в аргументе arg, игнорируются.

fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | O_RDONLY);

Такой вызов абсолютно правильный, но он не делает ничего. Включение режима добавления для открытого файлового дескриптора выглядит так, как показано ниже.

fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | O_APPEND);

Следует отметить, что это предохраняет установку O_NONBLOCK. Отключение режима добавления выглядит похоже.

fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) & ~O_APPEND);

11.5.2. Модификация флага "закрыть при выполнении"

Во время системного вызова exec() дескрипторы файлов обычно остаются открытыми для использования в новых программах. В некоторых случаях может потребоваться, чтобы файлы закрывались, когда вызывается exec(). Вместо закрытия их вручную вы можете попросить систему закрыть соответствующий файловый дескриптор при вызове exec() с помощью команд F_GETFD и F_SETFD в fcntl(). Если флаг "закрыть при выполнении" (close-on-exec) установлен, когда применяется F_GETFD, возвращается ненулевое значение, в противном случае возвращается ноль. Флаг "закрыть при выполнении" устанавливается командой F_SETFD; он отключается, если arg равно 0, в противном случае он включается.

Ниже показано, как можно заставить fd закрываться, когда процесс вызывает exec().

fcntl(fd, F_SETFD, 1);

11.5.3. Дублирование файловых дескрипторов

Иногда процессам требуется создать новый файловый дескриптор, который ссылается на ранее открытый файл. Командные оболочки используют эту функциональность для перенаправления стандартного ввода, вывода и потока ошибок по запросу пользователя. Если процессу не важно, какой файловый дескриптор будет использован для новой ссылки, он должен использовать dup().

#include <unistd.h>


int dup(int oldfd);

dup() возвращает файловый дескриптор, который ссылается на тот же inode, что и oldfd, или -1 в случае ошибки, oldfd остается корректным дескриптором, по-прежнему ссылающимся на исходный файл. Новый файловый дескриптор — это всегда наименьший доступный файловый дескриптор. Если процессу нужно получить новый файловый дескриптор с определенным значением (например, 0, чтобы перенаправить стандартный ввод), то он должен использовать dup2().

#include <unistd.h>


int dup2(int oldfd, int newfd);

Если newfd ссылается на уже открытый дескриптор, то он закрывается. Если вызов завершен успешно, он возвращает новый файловый дескриптор и newfd ссылается на тот же файл, что oldfd. Системный вызов fcntl() представляет почти ту же функциональность командой F_DUPFD. Первый аргумент — fd — это уже открытый файловый дескриптор. Новый файловый дескриптор — это первый доступный дескриптор, равный или больший, чем значение последнего аргумента fcntl(). (В этом состоит отличие от работы dup2().) Вы можете реализовать dup2() через fcntl() следующим образом.

int dup2(int oldfd, int newfd) {

 close(newfd); /* ensure new fd is available */

 return fcntl(oldfd, F_DUPFD, newfd);

}

Создание двух файловых дескрипторов, ссылающихся на один и тот же файл — это не то же самое, что открытие файла дважды. Почти все атрибуты дублированных дескрипторов разделяются: они разделяют текущую позицию, режим доступа и блокировки. (Все это записывается в файловой структуре[50], которая создается при каждом открытии файла. Файловый дескриптор ссылается на файловую структуру, и дескриптор, возвращенный dup(), ссылается на одну и ту же структуру.) Единственный атрибут, который может независимо управляться в этих двух дескрипторах — это состояние "закрыть при выполнении". После того, как процесс вызывает fork(), то файлы, открытые в родительском процессе, наследуются дочерним, и эти пары файловых дескрипторов (один в родительском процессе, другой — в дочернем) ведут себя так, будто файловые дескрипторы были дублированы с текущей позицией и другими разделенными атрибутами[51].

11.6. Создание неименованных каналов

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

Оболочки применяют неименованные каналы для выполнения команд вроде ls | head. Процесс ls пишет в тот канал, из которого head читает свой ввод, выдавая ожидаемый пользователем результат.

Создание неименованного канала выполняется по двум файловым дескрипторам, один из которых доступен только для чтения, а второй — только для записи.

#include <unistd.h>


int pipe(int fds[2]);

Единственный параметр-массив включает два файловых дескриптора — fd[0] для чтения и fd[1] для записи.

11.7. Добавление перенаправления для ladsh

Теперь, когда мы рассмотрели основные манипуляции с файлами, мы можем научить ladsh перенаправлению ввода и вывода через файлы и каналы. ladsh2.с, который мы представим здесь, работает с каналами (описанными символом | в командах ladsh, как это делается в большинстве командных оболочек) и перенаправление ввода и вывода в файловые дескрипторы. Мы покажем только модифицированные части кода здесь — полный исходный текст ladsh2.с доступен по упомянутым в начале книги адресам. Изменения в parseCommand() — это простое упражнение по разбору строк, поэтому мы не будем надоедать дискуссией об этом.

11.7.1. Структуры данных

Хотя код в ladsh1.с поддерживает концепцию задания как множества процессов (предположительно, объединенных вместе каналами), он не предоставляет способа указания того, какие файлы использовать для ввода и вывода. Чтобы позволить это, добавляются новые структуры данных и модифицируются существующие.

24:  REDIRECT_APPEND};

25:

26: struct redirectionSpecifier {

27:  enum redirectionTypetype; /* тип перенаправления */

28:  int fd; /*перенаправляемый файловый дескриптор*/

29:  char * filename; /* файл для перенаправления fd */

30: };

31:

32: struct childProgram {

33:  pid_t pid; /* 0 если завершен */

34:  char **argv; /* имя программы и аргументы */

35:  int numRedirections; /* элементы в массиве перенаправлений */

36:  struct redirectionSpecifier *redirections; /* перенаправления ввода-вывода*/

37: } ;

Структура struct redirectionSpecifier сообщает ladsh2.с о том, как установить отдельный файловый дескриптор. Она содержит enum redirectionTypetype, который указывает, является ли это перенаправление перенаправлением ввода, перенаправлением вывода, который должен быть добавлен к существующему файлу, либо перенаправлением вывода, которое заменяет существующий файл. Она также включает перенаправляемый файловый дескриптор и имя файла. Каждая дочерняя программа (struct childProgram) теперь специфицирует нужное ей количество перенаправлений.

Эти новые структуры данных не связаны с установкой каналов между процессами. Поскольку задание определено как множество дочерних процессов с каналами, связывающими их, нет необходимости в более подробной информации, описывающей каналы. На рис. 11.1 показано, как эти новые структуры должны выглядеть для команды tail < input-file | sort > output-file.

Рис. 11.1. Структуры данных, описывающие задание для ladsh2.с

11.7.2. Изменения в коде

Как только в parseCommand() будут правильно отражены структуры данных, то запуск команд в правильном порядке становится довольно простым при достаточном внимании к деталям. Прежде всего, мы добавляем цикл в parseCommand() для запуска дочерних процессов, поскольку теперь их может быть множество. Прежде чем войти в цикл, мы устанавливаем nextin и nextout, которые являются файловыми дескрипторами, используемыми в качестве стандартных потоков ввод и вывода для следующего запускаемого процесса. Для начала мы используем те же stdin и stdout, что и оболочка.

Теперь посмотрим, что происходит внутри цикла. Основная идея описана ниже.

1. Если это финальный процесс в задании, убедиться, что nextout указывает на stdout. В противном случае нужно подключить вывод этого задания к входному концу неименованного канала.

2. Породить новый процесс. Внутри дочернего перенаправить stdin и stdout, как указано с помощью nextin, nextout и всех специфицированных ранее перенаправлений.

3. Вернувшись обратно в родительский процесс, закрыть nextin и nextout, используемые только что запущенным дочерним процессом (если только они не являются потоками ввода и вывода самой оболочки).

4. Теперь настроить следующий процесс в задании для приема его ввода из вывода процесса, который мы только что создали (через nextin).

Вот как эти идеи перевести на С.

365: nextin=0, nextout=1;

366: for (i=0; i<newJob.numProgs; i++) {

367:  if ((i+1) < newJob.numProgs) {

368:   pipe(pipefds);

369:   nextout = pipefds[1];

370:   } else {

371:    nextout = 1;

372:   }

373:

374:   if (!(newJob.progs[i].pid = fork())) {

375:    if (nextin != 0) {

376:     dup2(nextin, 0);

377:     close(nextin);

378:    }

379:

380:    if (nextout != 1) {

381:     dup2(nextout, 1);

382:     close(nextout);

383:    }

384:

385:    /* явное перенаправление перекрывает каналы */

386:    setupRedirections(newJob.progs+i);

387:

388:    execvp(newJob.progs[i].argv[0], newJob.progs[i].argv);

389:    fprintf(stderr, "exec() of %s failed: %s\n",

390:     newJob.progs[i].argv[0],

391:    strerror(errno));

392:    exit(1);

393:   }

394:

395:   /* поместить наш дочерний процесс в группу процессов,

396:      чей лидер - первый процесс канала */

397:   setpgid(newJob.progs[i].pid, newJob.progs[0].pid);

398:

399:   if (nextin != 0) close(nextin);

400:   if (nextout != 1) close (nextout);

401:

402:   /* Если больше нет процессов, то nextin - мусор,

403:      но это не имеет значения */

404:   nextin = pipefds[0];

Единственный код, добавленный в ladsh2.с для обеспечения перенаправлений — это функция setupRedirections(), код которой останется неизменным во всех последующих версиях ladsh. Ее задача состоит в обработке спецификаторов struct redirectionSpecifier для дочерних заданий и соответствующей модификации дочерних файловых дескрипторов. Мы рекомендуем просмотреть код этой функции в приложении Б.

Глава 12 Обработка сигналов

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

Сигналы всегда были неотъемлемой частью Unix. Ядро использует их для извещения процессов о разнообразных событиях, включая перечисленные ниже.

• Уничтожение одного из дочерних процессов.

• Установка предупреждений устаревшим процессам.

• Изменение размеров окна терминала.

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

• Проигнорировать сигнал.

• Позволить ядру запустить специальную часть процесса, прежде чем продолжить выполнение основной его части (это называется перехватом сигнала).

• Позволить ядру выполнить действие по умолчанию, которое зависит от конкретного полученного сигнала.

Концептуально это довольно просто. Однако история развития средств работы с сигналами видна, когда вы сравните различные интерфейсы сигналов, которые поддерживаются различными реализациями Unix. BSD, System V и System 3 поддерживают различные и несовместимые программные интерфейсы сигналов. POSIX определил стандарт, теперь поддерживаемый почти всеми версиями Unix (включая Linux), который был тогда расширен для обработки новой семантики сигнала (вроде формирования очереди сигналов) как части определения сигнала в режиме реального времени POSIX (POSIX Real Time Signal). В этой главе обсуждается исходное выполнение сигналов Unix перед объяснением основ программного интерфейса POSIX и их расширений Real Time Signal, поскольку появление многих возможностей POSIX API было мотивировано недостатками в более ранних реализациях системы сигналов.

12.1. Концепция сигналов

12.1.1. Жизненный цикл сигнала

Сигналы имеют четко определенный жизненный цикл: они создаются, сохраняются до тех пор, пока ядро не выполнит определенное действие на основе сигнала, а затем вызывают совершение этого действия. Создание сигнала называют по-разному: поднятие (raising), генерация или посылка сигнала. Обычно процесс посылает сигнал другому процессу, в то время как ядро генерирует сигналы для отправки процессу. Когда процесс посылает сигнал самому себе, говорят, что он поднимает его. Однако эти термины используются не особо согласованно.

Между временем, когда сигнал отправлен и тем, когда он вызывает какое-то действие, его называют ожидающим (pending). Это значит, что ядро знает, что сигнал должен быть обработан, но пока не имеет возможности сделать это. Как только сигнал поступает в процесс назначения, он называется доставленным. Если доставленный сигнал вызывает выполнение специального фрагмента кода (имеется в виду обработчик сигнала), то такой сигнал считается перехваченным. Есть разные способы, которыми процесс может предотвратить асинхронную доставку сигнала, но все же обработать его (например, с помощью системного вызова sigwait()). Когда такое случается, сигнал называют принятым.

Чтобы облегчить понимание, мы будем использовать эту терминологию на протяжении всей книги[52].

12.1.2. Простые сигналы

Изначально обработка сигналов была проста. Системный вызов signal() использовался для того, чтобы сообщить ядру, как доставить процессу определенный сигнал.

#include <signal.h>


void * signal(int signum, void *handler);

Здесь signum — это сигнал, который нужно обработать, a handler определяет действия, которое должно быть выполнено при доставке сигнала. Обычно handler — это указатель на функцию-обработчик сигнала, которая не принимает параметров и не возвращает значения. Когда сигнал доставлен процессу, ядро как можно скорее запускает функцию-обработчик. Когда функция возвращает управление, ядро возобновляет выполнение процесса с того места, где он был прерван. Системные инженеры распознают в этом механизме обработки сигналов аналог доставки аппаратных прерываний. Прерывания и сигналы очень похожи и у них возникают сходные проблемы.

Доступно множество номеров сигналов. В табл. 12.1 перечислены все сигналы, поддерживаемые в настоящее время Linux, за исключением сигналов реального времени. Они имеют символические имена, начинающиеся с SIG, и мы будем использовать SIGЧТО-ТО, говоря о каком-то из них.

Параметр handler может иметь два специальных значения — SIG_IGN и SIG_DFL (оба определены в <signal.h>). Если указано SIG_IGN, сигнал игнорируется, SIG_DFL сообщает ядру, что нужно выполнить действие по умолчанию, как правило, уничтожив процесс либо проигнорировав сигнал. Два сигнала — SIGKILL и SIGSTOP — не могут быть перехвачены. Ядро всегда выполняет действие по умолчанию для этих сигналов, соответственно, уничтожая процесс и приостанавливая его.

Функция signal() возвращает предыдущий обработчик сигнала (который мог быть SIG_IGN или SIG_DFL). Обработчики сигналов резервируются при создании новых процессов вызовом fork(), и все сигналы, которые установлены в SIG_IGN, игнорируются и после вызова exec()[53]. Все не игнорируемые сигналы после exec() устанавливаются в SIG_DFL.

Все это выглядит достаточно простым, пока вы не спросите себя: что произойдет, если сигнал SIGЧТО-ТО будет отправлен процессу, который уже исполняет обработчик сигнала для SIGЧТО-ТО.

Очевидно, что должно сделать ядро — так это прервать процесс и запустить обработчик сигнала сначала. Это порождает две проблемы. Первая — обработчик сигнала должен работать правильно, если он вызван тогда, когда уже сам работает. Хотя само по себе это и не сложно, но обработчики сигналов, которые манипулируют общепрограммными ресурсами, такими как глобальные структуры данных или файлы, должны быть написаны очень аккуратно. Функции, которые ведут себя правильно, когда вызваны подобным образом, называются реентерабельными функциями[54].

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

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

Первое решение этой проблемы было неудачным. Прежде чем вызывается обработчик сигнала, для программы значение этого обработчика устанавливалось в SIG_DFL, и ожидалось, что правильное его значение будет восстановлено немедленно, как только возможно. Хотя это упрощало написание обработчиков сигналов, но также делало невозможным для программиста обрабатывать сигналы надежным образом. Если два экземпляра одного и того же сигнала поступали быстро друг за другом, то ядро обрабатывало второй из них способом, принятым по умолчанию. Это означало, что сигнал, пришедший вторым, игнорировался (и пропадал навсегда), или же процесс прерывался. Эта реализация известна под названием ненадежных сигналов, потому что не позволяла написать обработчики, ведущие себя надежным, правильным образом.

К сожалению, именно такая модель сигналов используется в ANSI/ISO-стандарте С[55]. Хотя программные интерфейсы надежных сигналов, в которых исправлен этот недостаток, уже широко распространены, стандартизация ненадежных сигналов в ANSI/ISO, видимо, останется навсегда.

12.1.3. Надежные сигналы

Реализация BSD для решения проблемы множества сигналов полагается на простое ожидание завершения работы каждого обработчика сигналов в процессе перед доставкой следующего. Это гарантирует то, что каждый сигнал будет рано или поздно обработан, а также исключает риск переполнения стека. Вспомним, что когда ядро удерживает сигнал для отложенной доставки, сигнал называется ожидающим (pending).

Однако если процессу отправлен сигнал SIGЧТО-ТО, в то время, как SIGЧТО-ТО уже находится в состоянии ожидания, то в этом случае процессу доставляется только первый из них. У процесса нет никакой возможности узнать, сколько раз один и тот же сигнал был отправлен ему, поскольку множество одинаковых сигналов подряд воспринимаются как один. Обычно это не представляет собой проблему. Поскольку сигнал не несет в себе никакой информации помимо собственно номера сигнала, двойная посылка сигнала за очень короткий отрезок времени может быть воспринята как одиночная, потому если программа примет сигнал только однажды, это не имеет особого значения. Это отличается от варианта с обработкой второго сигнала по умолчанию (что делается при ненадежной схеме обработки сигналов)[56].

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

Хотя BSD представляет адаптированную версию модели сигналов POSIX, комитет по стандартизации POSIX упростил ее для системных вызовов, с тем чтобы модифицировать диспозицию групп сигналов, предлагая новые системные вызовы для оперирования наборами сигналов. Наборы сигналов представлены типом данных sigset_t, и для манипулирования ими предусмотрен набор макросов[57].

12.1.4. Сигналы и системные вызовы

Часто сигналы доставляются процессу, который находится состоянии ожидания наступления некоторого внешнего события. Например, текстовый редактор часто ожидает завершения read(), чтобы возвратить ввод терминала. Когда системный администратор посылает процессу сигнал SIGTERM (нормальный сигнал, посылаемый командой kill, позволяющий процессу завершиться чисто), то процесс может обработать его, как описано ниже.

1. Не пытаться перехватить сигнал и быть прерванным ядром (обработка SIGTERM по умолчанию). Это оставляет пользовательский терминал в нестандартной конфигурации, затрудняя ему продолжение работы.

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

3. Перехватить сигнал, установить флаг, обозначающий, что сигнал получен, и каким-то образом обеспечить выход из блокирующего системного вызова (в данном случае read()) с индикацией ошибки — в знак того, что произошло что-то необычное. Нормальный порядок выполнения затем должен проверить флаг и обработать его соответствующим образом.

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

Медленные системные вызовы требуют неопределенного времени для своего завершения. Системные вызовы, которые для завершения своей работы ожидают непредсказуемых ресурсов, таких как другие процессы, сетевые данные либо действия со стороны человека, рассматриваются как медленные. Семейство системных вызовов wait(), например, не возвращают управление до тех пор, пока дочерние процессы не завершатся. Поскольку невозможно узнать, насколько долго продлится это ожидание, считается, что wait() — медленный системный вызов. Системные вызовы доступа к файлам рассматриваются как медленные, если они обращаются к медленным файлам, и быстрые — если к быстрым файлам[58].

Обязанностью процесса является обработка EINTR и перезапуск системных вызовов в случае необходимости. Хотя это обеспечивает всю функциональность, которая требуется людям, намного сложнее написать код, который обрабатывает сигналы. Всякий раз когда read() вызывается на медленном файловом дескрипторе, код должен проверять его возврат на равенство EINTR, и перезапускать вызов, либо он не будет делать то, что ожидается.

Чтобы "упростить" ситуацию, 4.2BSD автоматически перезапускает такие системные вызовы (особенно read() и write()). Поэтому для большинства операций программы более не должны беспокоиться об EINTR, поскольку выполнение системных вызовов продолжится после того, как процесс обработает сигнал. В последних версиях Unix изменен перечень системных вызовов, которые автоматически перезапускаются, a 4.3BSD позволяет вам выбрать, какие системные вызовы перезапускать. Стандарт обработки сигналов POSIX не указывает, какое поведение должно применяться, но все популярные системы согласны в том, как обрабатывать этот случай. По умолчанию системные вызовы не перезапускаются, но для каждого сигнала процесс может установить флаг, который указывает, что система должна перезапускать системные вызовы, прерванные этим сигналом.

12.2. Программный интерфейс сигналов Linux и POSIX

12.2.1. Посылка сигналов

Посылка сигналов от одного процесса другому обычно осуществляется с помощью системного вызова kill(). Этот системный вызов подробно обсуждался в главе 10. Вариантом kill() является tkill(), который не предназначен для прямого использования в программах.

int tkill(pid_t pid, int signum);

Существуют два отличия между kill() и tkill()[59]. Первое: pid должен быть положительным числом; tkill() не может использоваться для отправки сигналов группам процессов, как это может kill(). Другое отличие позволяет обработчикам сигналов определять, применялся ли вызов kill() или tkill() для генерации сигнала: подробности см. далее в главе.

Функция raise(), которая представляет собой способ генерации сигналов, указанный ANSI/ISO, использует системный вызов tkill() для генерации сигналов в системах Linux.

int raise(int signum);

Функция raise() посылает текущему процессу сигнал, указанный в signum[60].

12.2.2. Использование sigset_t

Большинство функций сигналов POSIX принимают набор сигналов в качестве одного из своих параметров (или части одного из параметров). Тип данных sigset_t служит для представления набора сигналов и определен в <signal.h>. POSIX определяет пять функций для манипулирования наборами сигналов.

#include <signal.h>


int sigemptyset(sigset_t *set);

int sigfillset(sigset_t *set);

int sigaddset(sigset_t *set, int signum);

int sigdelset(sigset_t *set, int signum);

int sigismember(const sigset_t *set, int signum);

int sigemptyset(sigset_t *set); Делает пустым набор сигналов, на который указывает set (никаких сигналов в set представлено не будет).
int sigfillset(sigset_t *set); Включает все доступные сигналы в set.
int sigaddset(sigset_t *set, int signum); Добавляет сигнал signum в набор set.
int sigdelset(sigset_t *set, int signum); Удаляет сигнал signum из набора set.
int sigismember(const sigset_t *set, int signum); Возвращает не 0, если сигнал signum содержится в set. В противном случае возвращает 0.

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

12.2.3. Перехват сигналов

Вместо использования функции signal() (чья семантика в процессе эволюции стала неправильной) POSIX-программы регистрируют обработчики сигналов с помощью sigaction().

#include <signal.h>


int sigaction(int signum, struct sigaction *act, struct sigaction *oact);

Этот системный вызов устанавливает обработчик сигнала signum, как определено с помощью act. Если oact не равен NULL, он принимает расположение обработчика перед вызовом sigaction(). Если act равен NULL, текущая установка обработчика остается неизменной, позволяя программе получить текущее расположение, не изменяя его. sigaction() возвращает 0 в случае успеха и ненулевое значение в случае ошибки. Ошибки случаются только если один или несколько параметров, переданных sigaction(), не верны.

Обработка сигнала ядром полностью описывается структурой struct sigaction.

#include <signal.h>

struct sigaction {

 __sighandler_t sa_handler;

 sigset_t sa_mask;

 int sa_flags;

};

sa_handler — это указатель на функцию со следующим прототипом:

void handler(int signum);

Здесь signum устанавливается равным номеру сигнала, который является причиной вызова функции, sa_handler может указывать на функцию этого типа либо быть равным SIG_IGN или SIG_DFL.

Программа также специфицирует набор сигналов, которые должны блокироваться во время функционирования обработчика сигнала. Если обработчик предназначен для обработки нескольких различных сигналов (что легко сделать благодаря параметру signum), это средство существенно для предотвращения возникновения условия состязаний. sa_mask — это набор сигналов, включающий все сигналы, которые должны блокироваться при вызове обработчика. Однако доставленный сигнал блокируется независимо от того, что содержит sa_mask — если вы не хотите, чтобы он блокировался, укажите это флагом sa_flags — членом структуры struct sigaction.

Член sa_flags позволяет процессу модифицировать различные поведения сигнала. Он содержит один или более флагов, объединенных битовой операцией "ИЛИ"[61].

SA_NOCLDSTOP Обычно SIGCHLD генерируется, когда один из потомков процесса прерван или приостановлен (то есть всякий раз, когда wait4() должен вернуть информацию о состоянии процесса). Если флаг SA_NOCLDSTOP указан для сигнала SIGCHLD, то сигнал генерируется лишь в случае прерывания дочернего процесса; приостановка дочернего процесса не приводит к генерации каких-либо сигналов. SA_NOCLDSTOP не оказывает влияния ни на какой другой сигнал.
SA_NODEFER Когда вызывается обработчик сигнала, сигнал автоматически не блокируется. Применение этого флага приводит к ненадежным сигналам, и он должен использоваться только для эмуляции ненадежных сигналов в приложениях, зависящих от такого поведения. Это идентично флагу SA_NOMASK в System V.
SA_RESETHAND Когда присылается сигнал, обработчик сбрасывается в SIG_DFL. Этот флаг позволяет эмулировать функцию ANSI/ISO signal() в библиотеке пользовательского пространства. Идентично флагу SA_ONESHOT в System V.
SA_RESTART Когда сигнал посылается процессу во время выполнения медленного системного вызова, системный вызов перезапускается после возврата управления из обработчика. Если флаг не указан, то системный вызов в этом случае возвращает ошибку и устанавливает errno равным EINTR.

12.2.4. Манипулирование маской сигналов процесса

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

Пример немного прояснит эту проблему. Ниже показан простой обработчик SIGHUP, изменяющий значение строки, на которую указывает глобальная переменная someString.

void handleHup(int signum) {

 free(someString);

 someString = strdup("другая строка");

}

В реальных программах новое значение someString вероятно, будет читаться из внешнего источника (такого как FIFO), но некоторые концепции актуальны и так. Теперь предположим, что основная часть программы копирует строку (этот код аналогичен реализации strcpy(), хотя и не очень оптимизирован), когда поступает сигнал SIGHUP.

src = someString;

while(*src)

*dest++ = *src++;

Когда главная часть программы возобновит выполнение, src будет указывать на память, которая была освобождена обработчиком сигналов. Излишне говорить, что это очень плохая идея[62].

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

Набор сигналов, которые процесс блокирует, часто называют маской сигнала этого процесса. Маска сигналов процесса задается типом sigset_t и содержит сигналы, заблокированные в данный момент. Функция sigprocmask() позволяет процессу управлять его текущей маской сигналов.

#include <signal.h>


int sigprocmask(int what, sigset_t *set, sigset_t *oldest);

Первый параметр, what, описывает, как должна выполняться манипуляция. Если set равно NULL, то what игнорируется.

SIG_BLOCK Сигналы в set добавляются к текущей маске сигналов.
SIG_UNBLOCK Сигналы в set исключаются из текущей маски сигналов.
SIG_SETMASK Блокируются сигналы из набора set, остальные разблокируются.

Во всех трех случаях параметр oldset типа sigset_t указывает на исходную маску сигналов, если только он не равен NULL — в этом случае oldset игнорируется. Следующий вызов ищет текущую маску сигналов для запущенных процессов.

sigprocmask(SIG_BLOCK, NULL, ¤tSet);

Системный вызов sigprocmask позволяет исправить код, представленный выше, который мог вызвать состояние состязаний. Все, что потребуется сделать — это блокировать SIGHUP перед копированием строки и разблокировать после копирования. Следующее усовершенствование делает код более безопасным.

sigset_t hup;

sigemptyset(&hup);

sigaddset(&hup, SIGHUP);

sigprocmask(SIG_BLOCK, &hyp, NULL);

src = someString;

while(*src)

 *dest++ = *src++;

sigprocmask(SIG_UNBLOCK, &hup, NULL);

Сложность обеспечения безопасности обработчика сигналов от состояния состязаний должно заставить вас писать обработчики, насколько возможно, простыми.

12.2.5. Нахождение набора ожидающих сигналов

Очень легко найти сигналы, находящиеся в состоянии ожидания (сигналы, которые должны быть доставлены, но в данный момент заблокированы).

#include <signal.h>


int sigpending(sigset_t *set);

Эта функция записывает по адресу, указанному set, набор сигналов, которые в данный момент находятся в состоянии ожидания.

12.2.6. Ожидание сигналов

Когда программа построена преимущественно вокруг сигналов, часто необходимо, чтобы она ожидала появления какого-то сигнала, прежде чем продолжать работу. Системный вызов pause() предоставляет простую возможность для этого.

#include <unistd.h>


int pause(void);

Функция pause() не возвращает управления до тех пор, пока сигнал не будет доставлен процессу. Если зарегистрирован обработчик для этого сигнала, то он запускается до того, как pause() вернет управление, pause() всегда возвращает -1 и устанавливает errno равным EINTR.

Системный вызов sigsuspend() предлагает альтернативный метод ожидания вызова сигнала.

#include <signal.h>


int sigsuspend(const sigset_t *mask);

Как и pause(), sigsuspend() временно приостанавливает процесс до тех пор, пока не будет получен сигнал (и обработан связанным с ним обработчиком, если таковой предусмотрен), возвращая -1 и устанавливая errno в EINTR.

В отличие от pause(), sigsuspend() временно устанавливает маску сигналов процесса в значение, находящееся по адресу, указанному в mask, на период ожидания появления сигнала. Как только сигнал поступает, маска сигналов восстанавливается в то значение, которое она имела до вызова sigsuspend(). Это позволяет процессу ожидать появления определенного сигнала за счет блокирования всех остальных сигналов[63].

12.3. Доступные сигналы

Linux предоставляет в распоряжение процессов сравнительно немного сигналов, и все они собраны в табл. 12.1.


Таблица 12.1. Сигналы

Сигнал Описание Действие по умолчанию
SIGABRT Доставляется вызовом abort(). Прервать, сбросить дамп
SIGALRM Истек срок действия alarm(). Прервать
SIGBUS Ошибка, зависящая от оборудования. Прервать, сбросить дамп
SIGCHLD Дочерний процесс прерван. Игнорировать
SIGCONT Выполнение процесса продолжается после приостановки. Игнорировать
SIGFPE Арифметическая ошибка. Прервать, сбросить дамп
SIGHUP Закрыт процесс, управляющий терминалом. Прервать
SIGILL Обнаружена недопустимая инструкция. Прервать
SIGINT Пользователь послал символ прерывания (^C). Прервать
SIGIO Принят асинхронный ввод-вывод. Прервать
SIGKILL Не перехватываемое прерывание процесса. Прервать
SIGPIPE Процесс пишет в канал при отсутствии читателя. Прервать
SIGPROF Закончился сегмент профилирования. Прервать
SIGPWR Обнаружен сбой питания. Прервать
SIGQUIT Пользователь послал символ выхода (^\). Прервать, сбросить дамп
SIGSEGV Нарушение памяти. Прервать, сбросить дамп
SIGSTOP Приостановка процесса без его прерывания. Процесс приостановить
SIGSYS Неверный системный вызов. Прервать, сбросить дамп
SIGTERM Перехватываемый запрос на прерывание процесса. Прервать
SIGTRAP Получена инструкция точки прерывания. Прервать, сбросить дамп
SIGTSTP Пользователь послал символ приостановки (^Z). Процесс приостановить
SIGTTIN Фоновый процесс читает с управляющего терминала. Процесс приостановить
SIGTTOU Фоновый процесс пишет на управляющий терминал. Процесс приостановить
SIGURG Условие срочного ввода-вывода. Игнорировать
SIGUSR1 Определяемый процессом сигнал. Прервать
SIGUSR2 Определяемый процессом сигнал. Прервать
SIGVTALRM Таймер, установленный с помощью setitimer(), устарел. Прервать
SIGWINCH Размер управляющего терминала изменился. Игнорировать
SIGXCPU Достигнуто ограничение ресурсов центрального процессора. Прервать, сбросить дамп
SIGXFSZ Достигнуто ограничение размера файла. Прервать, сбросить дамп

Предусмотрены четыре действия по умолчанию, которые ядро может предпринять при поступлении сигнала: игнорировать его, приостановить процесс (он остается жив и может быть перезапущен позднее), прервать процесс либо прервать процесс и сбросить дамп памяти ядра[64]. Ниже приведено более подробное описание каждого из перечисленных в табл. 12.1 сигналов.

SIGABRT Функция abort() посылает сигнал процессу, который ее вызвал, прерывая процесс со сбросом файла дампа ядра. Под Linux библиотека С вызывает abort(), когда происходит сбой утверждения (assertion). Примечание. Утверждения описаны в книгах по С начального уровня, например, [15].
SIGALRM Вызывается, когда предупреждение, установленное alarm(), устаревает. Предупреждения (alarms) — это основа функции sleep(), описанной в главе 18.
SIGBUS Когда процесс нарушает ограничения, накладываемые оборудованием, но не связанные с защитой памяти, посылается этот сигнал. Обычно это случается на традиционных платформах Unix, когда выполняется попытка "невыровненного" доступа, но ядро Linux исправляет такие попытки и продолжает выполнять процесс. Выравнивание памяти обсуждается в главе 7.
SIGCHLD Этот сигнал посылается процессу, когда один из его дочерних процессов устаревает или остановлен. Это позволяет процессу избежать появления "зомби" за счет вызова одной из функций wait() из обработчика сигнала. Если родитель всегда ожидает завершения дочерних процессов, прежде чем продолжить работу, этот сигнал может быть проигнорирован. Это отличается от сигнала SIGCHLD, представленного в ранних версиях System V. SIGCHLD устарел и более не должен применяться.
SIGCONT Этот сигнал перезапускает приостановленный процесс. Также он может быть вызван процессом, позволяющим выполнить действие после перезапуска. Большинство редакторов перехватывают этот сигнал и обновляют терминал после перезапуска. В главе 15 дана более подробная информация об останове и перезапуске процесса.
SIGFPE Этот сигнал посылается, когда процесс вызывает арифметическое исключение. Все исключения плавающей точки, такие как переполнение и потеря значимости, вызывают этот сигнал, как это происходит при делении на 0.
SIGHUP Когда терминал отсоединяется, лидер сеанса, ассоциированного с терминалом, получает этот сигнал, если только на терминале не выставлен флаг CLOCAL. Если лидер сеанса завершается, SIGHUP отправляется лидеру каждой группы процессов в данном сеансе. Большинство процессов прерываются при получении SIGHUP, поскольку это значит, что пользователя уже нет в системе. Многие процессы-демоны интерпретируют SIGHUP как запрос на закрытие и повторное открытие журнальных файлов, а также на перечитывание конфигурационных файлов.
SIGILL Процесс пытается запустить некорректную аппаратную команду.
SIGINT Этот сигнал посылается всем процессам в группе процессов переднего плана, когда пользователь нажимает клавиатурную комбинацию прерывания (обычно ^C).
SIGIO Произошло асинхронное событие ввода-вывода. Асинхронный ввод-вывод редко используется и в этой книге не описан. По вопросам асинхронного ввода-вывода обращайтесь к соответствующим источникам, например, [35].
SIGKILL Этот сигнал генерируется только вызовом kill() и разрешает пользователю безусловно прервать процесс.
SIGPIPE Процесс выполнил запись в канал, который не имеет читателя.
SIGPROF Завершилось действие таймера профилирования. Это сигнал обычно используется профилировщиками, которые проверяют другие характеристики процесса времени выполнения. Профилировщики обычно используются для оптимизации времени выполнения программ, помогая программистам находить узкие места. Простейшим профилировщиком является утилита gprof, входящая в состав всех дистрибутивов Linux.
SIGPWR Система обнаружила надвигающуюся потерю питания. Обычно этот сигнал отправляется процессу init демоном, отслеживающим источники питания машины, позволяя корректно завершить работу до отключения питания.
SIGQUIT Этот сигнал посылается всем процессам в группе процессов переднего плана, когда пользователь нажимает клавиатурную комбинацию завершения (обычно ^/).
SIGSEGV Этот сигнал посылается, когда процесс пытается прочитать неотображаемую память, выполнить страницу памяти, которая не была отображена с привилегиями на выполнение, или же выполнить запись в память, к которой не имеет прав доступа на запись.
SIGSTOP Этот сигнал генерируется только вызовом kill(), и дает возможность пользователю безусловно остановить процесс. Более подробно о приостановке процессов можно почитать в главе 15.
SIGSYS Когда программа пытается выполнить несуществующий системный вызов, ядро прерывает программу с помощью этого сигнала. Это никогда не должно происходить в программах, которые осуществляют системные вызовы посредством системой библиотеки С.
SIGTERM Этот сигнал генерируется только вызовом kill() и дает возможность пользователю элегантно прервать процесс. Процесс должен прекратиться насколько возможно быстро, немедленно после получения сигнала.
SIGTRAP Когда программа проходит через точку прерывания, этот сигнал посылается процессу. Обычно он перехватывается процессом отладчика, который установил точку прерывания.
SIGTSTP Этот сигнал посылается всем процессам в группе процессов переднего плана, когда пользователь нажимает клавиатурную комбинацию прерывания (обычно ^Z).
SIGTTIN Этот сигнал посылается фоновому процессу, который пытается осуществить чтение из контролируемого им терминала. Об управлении заданиями подробнее читайте в главе 15.
SIGTTOU Этот сигнал посылается фоновому процессу, который пытается осуществить запись на контролируемый им терминал. Об управлении заданиями подробнее читайте в главе 15.
SIGURG Этот сигнал посылается, когда по сокету принимается экстренное сообщение. Экстренные данные — тема, касающаяся сетевых технологий, которая выходит за рамки освещаемых в настоящей книге. В [33] это рассматривается более подробно.
SIGUSR1 Для этого сигнала нет предопределенного назначения; процессы могут использовать его для собственных нужд.
SIGUSR2 Для этого сигнала нет предопределенного назначения; процессы могут использовать его для собственных нужд.
SIGVTALRM Отправляется, когда истекает период действия таймера, установленного вызовом settimer(). Информацию о применении таймеров можно найти в главе 18.
SIGWINCH Когда окно терминала изменяет размер, например, когда пользователь растягивает окно xterm, все процессы в группе процессов переднего плана получают этот сигнал. В главе 16 представлена информация об определении текущего размера управляющего терминала.
SIGXCPU Процесс превысил свой мягкий лимит использования ресурсов процессора. Этот сигнал посылается раз в секунду до тех пор, пока данный процесс не превысит жесткий лимит использования ресурсов процессора. Как только это произойдет, процесс прерывается сигналом SIGKILL. Информацию о лимитах ресурса процессора можно найти в главе 10.
SIGXFSZ Когда программа превышает лимит максимального размера файла, ей посылается этот сигнал, что обычно уничтожает процесс. Если сигнал перехвачен, то системный вызов, который послужил причиной превышения лимита на размер файла, возвращает ошибку EFBIG. Информацию о лимитах ресурса процессора можно найти в главе 10.

12.3.1. Описание сигналов

Иногда приложения нуждаются в описании сигнала для отображения пользователю или помещения в журнал. Существуют три способа сделать это (см. главу 9). К сожалению, ни один из них не стандартизован.

Самый старый метод предусматривает применение sys_siglist — массива строк, описывающих каждый сигнал, проиндексированного номерами самих сигналов. Он включает описания всех сигналов за исключением сигналов реального времени. Применение sys_siglist более переносимо, чем прочие методы, описанные ниже. В системах BSD предусмотрена функция psignal(), которая является сокращенным способом отображения сообщений. Вот как выглядит версия psignal().

#include <signal.h>

#include <stdio.h>


void psignal(int signum, const char *msg) {

 printf("%s: %s\n", msg, sys_siglist[signum]);

}

Следует отметить, что эта функция использует тот же список сигналов, что и sys_siglist, поэтому сигналы реального времени также исключаются.

Библиотека GNU С, используемая Linux, предлагает еще один метод — strsignal(). Эта функция не входит ни в какой стандарт, поэтому для доступа к файлу прототипа нужно определить _GNU_SOURCE.

#define _GNU_SOURCE

#include <signal.h>


char *strsignal(int signum);

Подобно sys_siglist, strsignal() также представляет описание сигнала по номеру signum. Он использует sys_siglist для большинства сигналов и конструирует описания для сигналов реального времени. Например, SIGRTMIN + 5 будет описан как "Real-time signal 5". Пример использования strsignal() можно найти в строках 639–648 и 717 файла ladsh4.с, приведенного в приложении Б.

12.4. Написание обработчиков сигналов

Хотя обработчик сигнала выглядит подобно обычной функции С, он не вызывается так, как она. Вместо того чтобы быть частью нормальной последовательности вызовов программы, обработчик вызывается ядром. Ключевое различие между этими двумя вещами заключается в том, что обработчик может быть вызван почти в любое время, даже во время выполнения отдельного оператора С! Есть только несколько ограничений того, когда система может вызвать обработчик сигнала, на который вы полагаетесь.

1. Семантика некоторых сигналов ограничивает, когда они могут быть посланы. Так, например, SIGCHLD обычно посылается программам, у которых нет дочерних процессов[65]. Большинство сигналов, подобных SIGHUP, посылаются в непредсказуемые моменты.

2. Если процесс находится в процессе обработки некоторого сигнала, то обработчик сигнала не вызывается повторно для обработки того же сигнала, если только не была задана опция SA_NODEFER. Процесс также может блокировать дополнительные сигналы, если сигнал, который обрабатывается, указан в члене sa_mask структуры struct sigaction.

3. Процесс может блокировать сигналы, когда выполняется часть кода, используя sigprocmask(). Ранее в этой главе был дан пример использования этого средства для обеспечения атомарного обновления структур данных.

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

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

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

Если вам требуется доступ к глобальным данным из обработчика сигналов (что и делает большинство обработчиков), оставляйте структуры данных простыми. Хотя достаточно просто безопасно модифицировать отдельный элемент данных, такой как int, более сложные структуры обычно требуют блокировки сигналов. Любые глобальные переменные, которые могут быть модифицированы обработчиками сигналов, должны быть объявлены с ключевым словом volatile. Это сообщает компилятору, что переменная может быть изменена вне нормального потока программы, и он не должен пытаться оптимизировать доступ к этой переменной.

Другая вещь, с которой нужно соблюдать осторожность в обработчиках сигналов — это вызов других функций, потому что они тоже могут изменять глобальные данные! Библиотека С stdio пытается облегчить это и не допускает вызовов своих функций из обработчиков сигналов. В табл. 12.2 перечислены функции, которые гарантированно являются безопасными для вызова из обработчиков сигналов[66]; вызовов всех прочих функций следует избегать.


Таблица 12.2. Реентерабельные функции

abort() accept() access()
aio_error() aio_return() aio_suspend()
alarm() bind() cfgetispeed()
cfgetospeed() cfsetispeed() cfsetospeed()
chdir() chmod() chown()
close() connect() creat()
dup() dup2() execle()
execve() _exit() fchmod()
fchown() fcntl() fdatasync()
fork() fpathconf() fstat()
fsync() getegid() geteuid()
getgid() getgroups() getpeername()
getpgrp() getpid() getppid()
getuid() kill() link()
listen() lseek() lstat()
mkdir() mkfifo() open()
pathconf() pause() pipe()
poll() posix_trace_event() pselect()
raise() read() readlink()
recv() recvfrom() recvmsg()
rename() rmdir() select()
sem_post() send() sendmsg()
sendto() setgid() setpgid()
setsid() setsockopt() setuid()
shutdown() sigaction() sigaddset()
sigdelset() sigemptyset() sigfillset()
sigismember() signal() sigpause()
sigpending() sigprocmask() sigqueue()
sigset() sigsuspend() sleep()
socket() socketpair() stat()
symlink() sysconf() tcdrain()
tcflow() tcflush() tcgetattr()
tcgetpgrp() tcsendbreak() tcsetattr()
tcsetpgrp() time() timer_getoverrun()
timer_gettime() timer_settime() times()
umask() uname() unlink()
utime() wait() wait3()
wait4() waitpid() write()

12.5. Повторное открытие журнальных файлов

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

dd /var/log

mv messages messages.old

killall -HUP syslogd

Logrotate (ftp://ftp.redhat.com/pub/redhat/code/logrotate/) — одна из программ, которая использует преимущество такого метода для выполнения безопасной ротации журналов.

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

Затем обработчик сигнала SIGHUP в своем вызове устанавливает эту переменную, и главная часть программы проверяет эту переменную насколько можно часто. Ниже приведен пример соответствующей программы.

 1: /*sighup.c*/

 2:

 3: #include <errno.h>

 4: #include <signal.h>

 5: #include <stdio.h>

 6: #include <string.h>

 7: #include <unistd.h>

 8:

 9: volatile int reopenLog = 0; /* volatile - поскольку модифицируется

10:                                обработчиком сигнала */

11:

12: /* записать строку в журнал */

13: void logstring(int logfd, char *str) {

14:  write(logfd, str, strlen(str));

15: }

16:

17: /* когда приходит SIGHUP, сделать запись об этом и продолжить */

18: void hupHandler(int signum) {

19:  reopenLog = 1;

20: }

21:

22: int main() {

23:  int done = 0;

24:  struct sigaction sa;

25:  int rc;

26:  int logfd;

27:

28:  logfd = STDOUT_FILENO;

29:

30:  /* Установить обработчик сигнала SIGHUP. Использовать memset() для

31:     инициализации структуры sigaction чтобы обеспечить очистку

32:     всего. */

33:  memset(&sa, 0, sizeof(sa));

34:  sa.sa_handler = hupHandler;

35:

36:  if (sigaction(SIGHUP, &sa, NULL)) perror("sigaction");

37:

38:  /* Записывать сообщение в журнал каждые две секунды, и

39:     повторно открывать журнальный файл по требованию SIGHUP */

40:  while (!done) {

41:   /*sleep() возвращает не ноль, если не спит достаточно долго*/

42:   rc = sleep(2);

43:   if (rc) {

44:    if (reopenLog) {

45:     logstring(logfd,

46:      "* повторное открытие журналов по запросу SIGHUP\n");

47:     reopenLog = 0;

48:    } else {

49:     logstring(logfd,

50:      "* sleep прервано неизвестным сигналом "

51:      "--dying\n");

52:     done=1;

53:    }

54:   } else {

55:    logstring(logfd, "Периодическое сообщение\n");

56:   }

57:  }

58:

59:  return 0;

60: }

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

12.6. Сигналы реального времени

Учитывая некоторые ограничения модели сигналов POSIX, например, недостающую возможность присоединения к сигналам никаких данных и вероятность того, что множество сигналов сольются в одной доставке, было разработано расширение POSIX Real Time Signals (сигналы реального времени POSIX)[67]. Системы, которые поддерживают сигналы реального времени, включая Linux, также поддерживают описанный ранее традиционный механизм сигналов POSIX. Для обеспечения наивысшего уровня переносимости между системами, мы советуем использовать стандартные интерфейсы POSIX, если только не возникает необходимости в некоторых дополнительных средствах, предоставляемых расширением реального времени.

12.6.1. Очередность и порядок сигналов

Два из ограничений стандартной модели сигналов POSIX заключаются в том, что когда сигнал перебивает сигнал, это не приводит к множественной доставке этих сигналов, и отсутствуют гарантии упорядоченной доставки множества разнородных сигналов (если вы пошлете SIGTERM, а следом SIGKILL, то нет способа узнать, какой из них придет первым). Расширение POSIX Real Time Signals добавляет новый набор сигналов, которые не подпадают под упомянутые ограничения.

Существует множество доступных сигналов реального времени, и они не используются ядром ни для каких предопределенных целей. Все сигналы между SIGRTMIN и SIGRTMAX являются сигналами реального времени, хотя точные номера их в POSIX не специфицированы (на момент написания этой книги Linux предоставляет 32 таких сигнала, но в будущем их количество может увеличиться).

Сигналы реального времени всегда ставятся в очередь; каждый такой сигнал, посланный приложению, доставляется ему (если только приложение не прервано перед тем, как такой сигнал будет доставлен). Упорядочение сигналов реального времени также хорошо определено. Сигналы с меньшими номерами всегда доставляются перед сигналами с большими номерами, и когда множество сигналов с одинаковым номером поставлены в очередь, то они доставляются в порядке постановки. Порядок доставки сигналов, не относящихся к расширению реального времени, не определен, как и порядок доставки смеси сигналов реального времени и не относящихся к ним.

Ниже показан пример кода, иллюстрирующий постановку сигналов в очередь и их упорядочивание.

 1: /* queued.с */

 2:

 3: /* получить определение strsignal() из string.h */

 4: #define _GNU_SOURCE1

 5:

 6: #include <sys/signal.h>

 7: #include <stdlib.h>

 8: #include <stdio.h>

 9: #include <string.h>

10: #include <unistd.h>

11:

12: /* Глобальные переменные для построения списка сигналов */

13: int nextSig = 0;

14: int sigOrder[10];

15:

16: /* Перехватить сигнал и записать, что он был обработан */

17: void handler(int signo) {

18:  sigOrder[nextSig++] = signo;

19: }

20:

21: int main() {

22:  sigset_t mask;

23:  sigset_t oldMask;

24:  struct sigaction act;

25:  int i;

26:

27:  /* Обрабатываемые в программе сигналы */

28:  sigemptyset(&mask);

29:  sigaddset(&mask, SIGRTMIN);

30:  sigaddset(&mask, SIGRTMIN+1);

31:  sigaddset(&mask, SIGUSR1);

32:

33:  /* Отправить сигнал handler() и сохранять их блокированными,

34:     чтобы handler() был сконфигурирован во избежание

35:     состязаний при манипулировании глобальными переменными */

36:  act.sa_handler = handler;

37:  act.sa_mask = mask;

38:  act.sa_flags = 0;

39:

40:  sigaction(SIGRTMIN, &act, NULL);

41:  sigaction(SIGRTMIN+1, &act, NULL);

42:  sigaction(SIGUSR1, &act, NULL);

43:

44:  /* Блокировать сигналы, с которыми мы работаем, чтобы

45:     была видна очередность и порядок */

46:  sigprocmask(SIG_BLOCK, &mask, &oldMask);

47:

48:  /* Генерировать сигналы */

49:  raise(SIGRTMIN+1);

50:  raise(SIGRTMIN);

51:  raise(SIGRTMIN);

52:  raise(SIGRTMIN+1);

53:  raise(SIGRTMIN);

54:  raise(SIGUSR1);

55:  raise(SIGUSR1);

56:

57:  /* Разрешить доставку этих сигналов. Все они будут доставлены

58:     прямо перед возвратом этого вызова (для Linux; это

59:     НЕПЕРЕНОСИМОЕ поведение). */

60:  sigprocmask(SIG_SETMASK, &oldMask, NULL);

61:

62:  /* Отобразить упорядоченный список перехваченных сигналов */

63:  printf("Принятые сигналы:\n");

64:  for (i = 0; i < nextSig; i++)

65:   if (sigOrder[i] < SIGRTMIN)

66:    printf("\t%s\n", strsignal(sigOrder[i]));

67:   else

68:    printf("\tSIGRTMIN + %d\n", sigOrder[i] - SIGRTMIN);

69:

70:  return 0;

71: }

Эта программа посылает себе некоторое количество сигналов и выводит на дисплей порядок их получения. Когда сигналы отправляются, она блокирует их, чтобы предотвратить немедленную доставку. Также она блокирует сигналы всякий раз, когда вызывается обработчик, устанавливая значение члена sa_mask структуры struct sigaction при настройке обработчика для каждого сигнала. Это предотвращает возможное состояние состязаний при обращении к глобальным переменным nextSig и sigOrder изнутри обработчика.

Запуск этой программы выдаст показанные ниже результаты.

Принятые сигналы:

        User defined signal1

        SIGRTMIN + 0

        SIGRTMIN + 0

        SIGRTMIN + 0

        SIGRTMIN + 1

        SIGRTMIN + 1

Это показывает, что все сигналы реального времени были доставлены, в то же время, был доставлен только один экземпляр сигнала SIGUSR1. Вы также видите изменение порядка сигналов реального времени — все сигналы SIGRTMIN были доставлены перед SIGRTMIN + 1.

12.7. Дополнительные сведения о сигналах

Сигналы, которые мы обсуждали до сих пор, не несли в себе никаких данных; появление сигнала — это единственная информация, которую получает приложение. В некоторых случаях было бы неплохо знать, что послужило причиной отправки сигнала (как, например, неправильная адресация памяти, генерирующая SIGSEGV), или же иметь возможность включить данные в сигналы, генерируемые приложением. Расширение реального времени Real Time Signals позволяет решить обе эти задачи.

12.7.1. Получение контекста сигнала

Информация о том, как и почему был сгенерирован сигнал, называется контекстом[68] сигнала. Приложения, которые должны видеть этот контекст, используют обработчики сигналов, отличающиеся от нормальных. Они включают два дополнительных параметра — указатель на siginfo_t, предоставляющий контекст сигнала, и указатель на void*, который может быть использован некоторыми низкоуровневыми системными библиотеками[69]. Вот как выглядит полный прототип такого обработчика.

void handler(int signum, siginfo_t *siginfo, void *context);

Приложение должно указать ядру на необходимость передачи полной информации о контексте, устанавливая флаг SA_SIGINFO члена sa_mask структуры struct sigaction, применяемой для регистрации обработчика сигнала. Член sa_handler также не используется, потому что он является указателем на функцию с другим прототипом. Вместо этого новый член, sa_sigaction, указывает на обработчик сигнала с правильным прототипом. Чтобы снизить потребление памяти, sa_handler и sa_sigaction разрешено использовать один и тот же участок памяти, поэтому только один из двух должен применяться в одно и то же время. Чтобы сделать это прозрачным, библиотека С определяет struct sigaction следующим образом.

#include <signal.h>


struct sigaction {

 union {

  __sighandler_t sa_handler;

  __sigaction_t sa_sigaction;

 } __sigaction_handler;

 sigset_t sa_mask;

 unsigned long sa_flags;

};

#define sa_handler __sigaction_handler.sa_handler

#define sa_sigaction __sigaction_handler.sa_sigaction

Использование представленной комбинации объединений и макросов позволяет этим двум членам разделять одну и ту же память без необходимости усложнения с точки зрения приложений.

Структура siginfo_t содержит информацию о том, где и почему был сгенерирован сигнал. Всем сигналам доступны два члена: sa_signo и si_code. Какие другие члены доступны — зависит от конкретного сигнала, и эти члены разделяют память подобно тому, как это делают члены sa_handler и sa_sigaction структуры struct sigaction. Член sa_signo содержит номер доставленного сигнала и всегда равен значению первого параметра, переданного обработчику сигнала, в то время как si_code указывает, почему сигнал был сгенерирован, и изменяется в зависимости от номера сигнала. Для большинства сигналов он может принимать перечисленные ниже значения.[70]

SI_USER

Приложение пространства пользователя вызвало kill() для отправки сигнала. Примечание. Функция sigsend(), включенная в Linux для совместимости с некоторыми системами Unix, также выдает SI_USER.

SI_QUEUE

Приложение пространства пользователя вызвало sigqueue() для от правки сигнала, что обсуждается в самом конце этой главы.

SI_TKILL

Приложение пространства пользователя вызвало tkill(). В то время как ядро Linux использует SI_TKILL, его значение не специфицировано в текущей версии библиотеки С.

Если вам нужно проверить SI_TKILL, используйте следующий сегмент кода для определения этого значения:

#ifndef SI_TKILL

#define SI_TKILL -6

#endif

SI_TKILL не специфицирован ни в каком стандарте (хотя допускается ими), поэтому его следует применять осторожно в переносимых программах.

SI_KERNEL

Сигнал сгенерирован ядром.

Когда SIGILL, SIGFPE, SIGSEGV, SIGBUS и SIGCHLD посылаются ядром, то si_code вместо si_kernel принимает значения, перечисленные в табл. 12.3[71].


Таблица 12.3. Значения si_code для специальных сигналов

Сигнал si_code Описание
SIGILL ILL_ILLOPC Неправильный код операции (opcode).
ILL_ILLOPC Неправильный операнд.
ILL_ILLOPC Неправильный режим адресации.
ILL_ILLOPC Неправильная ловушка (trap).
ILL_ILLOPC Привилегированный код операции.
ILL_ILLOPC Привилегированный регистр.
ILL_ILLOPC Внутренняя ошибка стека.
ILL_ILLOPC Ошибка сопроцессора.
SIGFPE FPE_INTDIV Деление целого на ноль.
FPE_INTOVF Переполнение целого.
FPE_FLTDIV Деление числа с плавающей точкой на ноль.
FPE_FLTOVF Переполнение числа с плавающей точкой.
FPE_FLTUND Потеря значимости числа с плавающей точкой.
FPE_FLTRES Неточный результат числа с плавающей точкой.
FPE_FLTINV Неверная операция с плавающей точкой.
FPE_FLTSUB Число с плавающей точкой вне диапазона.
SIGSEGV SEGV_MAPPER Адрес не отображается на объект.
SEGV_ACCERR Неверные права доступа для адреса.
SIGBUS BUS_ADRALN Неверное выравнивание адреса.
BUS_ADRERR Несуществующий физический адрес.
BUS_OBJERR Специфичный для объекта сбой оборудования.
SIGCHLD CLD_EXITED Дочерний процесс завершен.
CLD_KILLED Дочерний процесс уничтожен.
CLD_DUMPED Дочерний процесс уничтожен с выводом дампа памяти в файл.
CLD_TRAPPED Дочерний процесс достиг точки останова.
CLD_STOPPED Дочерний процесс приостановлен.

Чтобы помочь прояснить разные значения, которые может принимать si_code, рассмотрим пример, в котором SIGCHLD генерируется четырьмя разными способами: kill(), sigqueue(), raise() (использует системный вызов tkill()) и созданием дочернего процесса, который немедленно прерывается.

 1: /* sicode.с */

 2:

 3: #include <sys/signal.h>

 4: #include <stdlib.h>

 5: #include <stdio.h>

 6: #include <unistd.h>

 7:

 8: #ifndef SI_TKILL

 9: #define SI_TKILL -6

10: #endif

11:

12: void handler(int signo, siginfo_t *info, void *f ) {

13:  static int count = 0;

14:

15:  printf("перехвачен сигнал, отправленный ");

16:  switch(info->si_code) {

17:  case SI_USER:

18:   printf("kill()\n"); break;

19:  case SI_QUEUE:

20:   printf("sigqueue()\n"); break;

21:  case SI_TKILL:

22:   printf("tkill() или raise()\n"); break;

23:  case CLD_EXITED:

24:   printf ("ядро сообщает, что дочерний процесс завершен\n"); exit(0);

25:  }

26:

27:  if (++count == 4) exit(1);

28: }

29:

30: int main() {

31:  struct sigaction act;

32:  union sigval val;

33:  pid_t pid = getpid();

34:

35:  val.sival_int = 1234;

36:

37:  act.sa_sigaction = handler;

38:  sigemptyset(&act.sa_mask);

39:  act.sa_flags = SA_SIGINFO;

40:  sigaction(SIGCHLD, &act, NULL);

41:

42:  kill(pid, SIGCHLD);

43:  sigqueue(pid, SIGCHLD, val);

44:  raise(SIGCHLD);

45:

46:  /* Чтобы получить SIGCHLD от ядра, мы создаем дочерний процесс

47:     и немедленно завершаем его. Обработчик сигнала выйдет после

48:     получения сигнала от ядра, поэтому мы просто засыпаем

49:     на время и позволяем программе прерваться подобным образом. */

50:

51:  if (!fork()) exit(0);

52:  sleep(60);

53:

54:  return 0;

55: }

Если si_code равно SI_USER, SI_QUEUE или SI_TKILL, то доступны два дополнительных члена siginfo_t: si_pid и si_uid, которые представляют идентификатор процесса, пославшего сигнал и действительный идентификатор пользователя этого процесса.

Когда ядром посылается SIGCHLD, доступны члены si_pid, si_status, si_utime и si_stime. Первый из них, si_pid, задает идентификатор процесса, состояние которого изменилось[72]. Информация о новом состоянии доступна как в si_code (как показано в табл. 12.3) и в si_status, что идентично целому значению состояния, возвращаемому семейством функций wait().

Последние два члена, si_utime и si_stime, определяют период времени, которое потрачено дочерним приложением на работу в пользовательском режиме и в режиме ядра, соответственно (это подобно тому, что возвращают вызовы wait3() и wait4() в структуре struct rusage). Это время измеряется в тиках часов, заданных целым числом. Количество тиков в секунду задает макрос _SC_CLK_TCK, определенный в <sysconf.h>.

SIGSEGV, SIGBUS, SIGILL и SIGFPE — все они представляют si_addr, специфицирующий адрес, который вызвал сбой, описанный si code.

Ниже приведен простой пример проверки контекста сигнала. Он устанавливает обработчик сигнала для SIGSEGV, который печатает контекст сигнала и прерывает процесс. Нарушение сегментации генерируется попыткой обращения к NULL.

 1: /* catch-segv.c */

 2:

 3: #include <sys/signal.h>

 4: #include <stdlib.h>

 5: #include <stdio.h>

 6:

 7: void handler(int signo, siginfo_t *info, void *f) {

 8:  printf("перехват");

 9:  if (info->si_signo == SIGSEGV)

10:   printf("segv accessing %p", info->si_addr);

11:  if (info->si_code == SEGV_MAPERR)

12:   printf("SEGV_MAPERR");

13:  printf("\n");

14:

15:  exit(1);

16: }

17:

18: int main() {

19:  struct sigactin act;

20:

21:  act.sa_sigaction = handler;

22:  sigemptyset(&act.sa_mask);

23:  act.sa_flags = SA_SIGINFO;

24:  sigaction(SIGSEGV, &act, NULL);

25:

26:  *((int *)NULL) = 1 ;

27:

28:  return 0;

29: }

12.7.2. Отправка данных с сигналом

Механизм siginfo_t также позволяет сигналам, которые посылают программы, присоединять к себе один элемент данных (этот элемент может быть указателем, что позволяет неявно передавать любой необходимый объем данных). Чтобы отправить данные, используется union sigval.

#include <signal.h>


union sigval {

 int sival_int;

 void *sival_ptr;

};

Любой из членов объединения — sival_int или sival_ptr — может быть установлен в требуемое значение, которое включается в siginfo_t, доставляемое вместе с сигналом. Чтобы сгенерировать сигнал с union sigval, должна использоваться функция sigqueue().

#include <signal.h>


void *sigqueue(pid_t pid, int signum, const union sigval value);

В отличие от kill(), pid должен быть корректным идентификатором процесса (отрицательные значения не допускаются), signum указывает номер посылаемого сигнала. Подобно kill(), sigqueue() допускает нулевое значение signum нулю, чтобы проверить, позволяет ли вызывающий процесс посылать целевому сигналы, в действительности не выполняя такой посылки. Последний параметр, value, представляет собой элемент данных, передаваемый вместе с сигналом.

Чтобы принять union sigval, процесс, перехватывающий сигнал, должен использовать SA_SIGINFO при регистрации обработчика сигналов с помощью sigaction(). Когда член si_code структуры siginfo_t равен SI_QUEUE, то siginfo_t представляет член si_value, который содержит значение value, переданное sigqueue.

Ниже приведен пример отправки элемента данных с сигналом. Он устанавливает в очередь три сигнала SIGRTMIN с разными элементами данных. Он демонстрирует, что сигналы доставляются в том же порядке, что были отправлены, как мы и ожидаем при работе с сигналами реального времени[73]. Более сложный пример, использующий сигналы для отслеживания изменений в каталогах, можно найти в главе 14.

 1: /* sigval.с */

 2:

 3: #include <sys/signal.h>

 4: #include <stdlib.h>

 5: #include <stdio.h>

 6: #include <string.h>

 7: #include <unistd.h>

 8:

 9: /* Захватить сигнал и зарегистрировать факт его обработки */

10: void handler(int signo, siginfo_t *si, void *context) {

11:  printf("%d\n", si->si_value.sival_int);

12: }

13:

14: int main() {

15:  sigset_t mask;

16:  sigset_t oldMask;

17:  struct sigaction act;

18:  int me = getpid();

19:  union sigval val;

20:

21:  /* Отправить сигналы handler() и сохранять все сигналы заблокированными,

22:     чтобы handler() был сконфигурирован для перехвата с исключением

23:     состязаний при манипулировании глобальными переменными */

24:  act.sa_sigaction = handler;

25:  act.sa_mask = mask;

26:  act.sa_flags = SA_SIGINFO;

27:

28:  sigaction(SIGRTMIN, &act, NULL);

29:

30:  /* Блокировать SIGRTMIN, чтобы можно было увидеть очередь и упорядочение*/

31:  sigemptyset(&mask);

32:  sigaddset(&mask, SIGRTMIN);

33:

34:  sigprocmask(SIG_BLOCK, &mask, &oldMask);

35:

36:  /* Сгенерировать сигналы */

37:  val.sival_int = 1;

38:  sigqueue(me, SIGRTMIN, val);

39:  val.sival_int++;

40:  sigqueue(me, SIGRTMIN, val);

41:  val.sival_int++;

42:  sigqueue(me, SIGRTMIN, val);

43:

44:  /* Разрешить доставку сигналов */

45:  sigprocmask(SIG_SETMASK, &oldMask, NULL);

46:

47:  return 0;

48: }

Глава 13 Расширенная обработка файлов

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

13.1. Мультиплексирование входных и выходных данных

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

Браузеру легче всего обработать эти файлы, считывая и обрабатывая данные из них (системный вызов read() в сетевом подключении, так же, как и в канале, возвращает доступные в настоящий момент данные и блокирует их только в случае неготовности). Этот подход эффективен, пока все подключения доставляют данные достаточно регулярно.

Если одно из сетевых подключений является медленным, начинают возникать проблемы. Когда браузер снова считывает из этого файла, он перестает работать, в то время как read() блокируется в ожидании поступления данных. Не стоит и упоминать, что подобное поведение не является удобоваримым для пользователя браузера.

Для иллюстрации этих проблем рассмотрим короткую программу, считывающую из двух файлов, p1 и p2. Для ее испытания откройте три сеанса работы с X-терминалом (или воспользуйтесь тремя виртуальными консолями). Создайте каналы под именами p1 и p2 (с помощью команды mknod), затем запустите cat > p1 и cat > p2 в двух терминалах, одновременно запустив mpx-blocks в третьем. После этого набирайте любой текст в каждом окно cat и смотрите, как он появляется. Помните, что две команды cat не будут записывать данные в каналы до конца строки.

 1: /* mpx-blocks.с */

 2:

 3: #include <fcntl.h>

 4: #include <stdio.h>

 5: #include <unistd.h>

 6:

 7: int main(void) {

 8:  int fds[2];

 9:  char buf[4096];

10:  int i;

11:  int fd;

12:

13:  if ((fds[0] = open("p1", O_RDONLY) ) < 0) {

14:   perror("open p1");

15:   return 1;

16:  }

17:

18:  if ( (fds[1] = open("p2", O_RDONLY)) < 0) {

19:   perror("open p2");

20:   return 1;

21:  }

22:

23:  fd = 0;

24:  while (1) {

25:   /* если данные доступны, прочитать и отобразить их */

26:   i = read (fds[fd], buf, sizeof (buf) - 1);

27:   if (i < 0) {

28:    perror("read");

29:    return 1;

30:   } else if (!i) {

31:    printf("канал закрыт\n");

32:    return 0;

33:   }

34:

35:   buf[i] = '\0';

36:   printf ("чтение: %s", buf);

37:

38:   /* читать из другого файлового дескриптора */

39:   fd = (fd + 1) % 2;

40:  }

41: }

Хотя программа mpx-blocks может считывать одновременно из обоих каналов, это не является особо эффективным. Она считывает из каждого канала по очереди. После запуска программа читает из первого файла, пока в нем доступны данные, второй файл игнорируется вплоть до возврата из read() для первого файла. Как только произошел возврат, первый файл игнорируется вплоть до чтения данных из второго файла. Этот метод не поддерживает гладкое мультиплексирование данных. На рис. 13.1 показана программа mpx-blocks во время выполнения.

Рис. 13.1. Примеры запуска мультиплексной передачи

13.1.1. Неблокируемый ввод-вывод

Как упоминалось в главе 11, неблокируемый файл можно определить с помощью системного вызова fcntl. Если медленный файл неблокируемый, read() сразу же возвращается. Если данные недоступны, она просто возвращает 0. Неблокируемый ввод- вывод предоставляет простое решение мультиплексирования, предотвращая блокирование файловых операций.

Показанная ниже модифицированная версия mpx-blocks пользуется преимуществом неблокируемого ввода-вывода для более гладкого переключения между p1 и p2.

 1: /* mpx-nonblock.c */

 2:

 3: #include <errno.h>

 4: #include <fcntl.h>

 5: #include <stdio.h>

 6: #include <unistd.h>

 7:

 8: int main(void) {

 9:  int fds[2];

10:  char buf[4096];

11:  int i;

12:  int fd;

13:

14:  /* открыть оба канала в неблокирующем режиме */

15:  if ((fds[0] = open("p1", O_RDONLY | O_NONBLOCK)) < 0) {

16:   perror("open p1");

17:   return 1;

18:  }

19:

20:  if ((fds[1] = open("p2", O_RDONLY | O_NONBLOCK)) < 0) {

21:   perror("open p2");

22:   return 1;

23:  }

24:

25:  fd = 0;

26:  while (1) {

27:   /* если данные доступны, прочитать и отобразить их */

28:   i = read(fds[fd], buf, sizeof (buf) - 1);

29:   if ((i < 0) && (errno ! = EAGAIN)) {

30:    perror("read");

31:    return 1;

32:   } else if (i > 0) {

33:    buf[i] = '\0';

34:    printf("чтение: %s", buf);

35:   }

36:

37:   /* читать из другого файлового дескриптора */

38:   fd = (fd + 1) % 2;

39:  }

40: }

Важное различие между mpx-nonblock и mpx-blocks состоит в том, что программа mpx-nonblock не закрывается, когда один из каналов, из которого она считывает, закрыт. Неблокируемый read() из канала без записывающих устройств возвращает 0 байт, из канала с таковыми, но без доступных данных read() возвращает EAGAIN.

Простое переключение неблокируемого ввода-вывода между дескрипторами файлов достается высокой ценой. Программа всегда опрашивает два файловых дескриптора для ввода — она никогда не блокируется. Постоянная работа программы приносит системе массу проблем, поскольку операционная система не может перевести процесс в режим ожидания (попробуйте запустить 10 копий mpx-nonblock в своей системе и посмотрите, как это скажется на ее производительности).

13.1.2. Мультиплексирование с помощью poll()

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

#include <sys/poll.h>


int poll(struct pollfd * fds, int numfds, int timeout);

Последние два параметра очень просты; numfds задает количество элементов в массиве, на который указывает первый параметр, a timeout определяет, насколько долго poll() должна ожидать события. Если в качестве тайм-аута задается 0, poll() никогда не входит в состояние тайм-аута.

Первый параметр, fds, описывает, какие файловые дескрипторы следует контролировать, и для каких типов ввода-вывода. Это указатель на массив структур struct pollfd.

struct pollfd {

 int fd;        /* файловый дескриптор */

 short events;  /* ожидаемые события ввода-вывода */

 short revents; /* происшедшие события ввода-вывода */

};

Первый элемент, fd, является контролируемым файловым дескриптором, а элемент events описывает, какие типы событий подлежат мониторингу. Последний представляет собой один или несколько перечисленных флагов, объединенных с помощью логического "ИЛИ".

POLLIN Нормальные данные доступны для считывания из файлового дескриптора.
POLLPRI Приоритетные (внешние) данные доступны для считывания.
POLLOUT Файловый дескриптор может принимать записываемые на него данные.

Элемент revents структуры struct pollfd заполняется системным вызовом poll() и отражает состояние файлового дескриптора fd. Это похоже на элемент events, но вместо определения интересующих приложение событий ввода-вывода он определяет доступные такие типы. Например, если приложение контролирует канал как для чтения, так и для записи (events установлено в POLLIN | POLLOUT), после успешного вызова poll() в revents устанавливается бит POLLIN, если канал готов для чтения, и бит POLLOUT, если в канале имеется пространство для записи дополнительных данных. Если верно и то, и другое, устанавливаются оба бита.

Существует несколько битов, которые ядро может установить в revents, но которые невозможно установить в events.

POLLERR В дескрипторе файла имеется ожидающая ошибка; выполнение системного вызова на файловом дескрипторе приведет к установке errno в подходящий код.
POLLHUP Файл был отключен; в него больше невозможно ничего записывать (хотя могут остаться данные для считывания). Это происходит в случае отключения терминала либо закрытия удаленного конца канала или сокета.
POLLNVAL Файловый дескриптор недоступен (он не относится к открытому файлу).

Возвращаемое значение poll() равно нулю в случае тайм-аута вызова, -1 в случае ошибки (например, fds — неверный указатель; ошибки в самих файлах вызывают установку POLLERR), или же положительное число, описывающее количество файлов с ненулевыми элементами revents.

В отличие от неэффективного метода мультиплексирования входных и выходных данных из каналов, используемого ранее, poll() довольно легко решает ту же проблему. Применяя poll() к файловым дескрипторам одновременно для обоих каналов, мы знаем, что когда poll() возвращается, один из каналов готов для чтения либо закрыт. Мы проверяем элемент revents для обоих файловых дескрипторов, чтобы узнать, какие действия предпринять, и по завершении возвращаемся в вызов poll(). Теперь большая часть времени тратится на блокирование вызова poll(), а не на постоянную проверку файловых дескрипторов, использующих неблокируемый ввод-вывод, что значительно уменьшает нагрузку на систему. Ниже показан код mpx-poll.

 1: /* mpx-poll.с */

 2:

 3: #include <fcntl.h>

 4: #include <stdio.h>

 5: #include <sys/poll.h>

 6: #include <unistd.h>

 7:

 8: int main(void) {

 9:  struct pollfdfds[2];

10:  char buf [4096];

11:  int i, rc;

12:

13:  /* открыть оба канала */

14:  if ( (fds[0].fd = open("p1", O_RDONLY | O_NONBLOCK)) < 0) {

15:   perror("open p1");

16:   return 1;

17:  }

18:

19:  if ((fds[1].fd = open("p2", O_RDONLY | O_NONBLOCK)) < 0) {

20:   perror("open p2");

21:   return 1;

22:  }

23:

24:  /* начать чтение из обоих файловых дескрипторов */

25:  fds[0].events = POLLIN;

26:  fds[1].events = POLLIN;

27:

28:  /* пока наблюдаем за одним из fds[0] или fds[1] */

29:  while (fds[0].events || fds[1].events ) {

30:   if (poll(fds, 2, 0) < 0) {

31:    perror("poll");

32:    return 1;

33:   }

34:

35:   /* проверить, какой из файловых дескрипторов

36:      готов для чтения из него */

37:   for (i = 0; i < 2; i++) {

38:    if (fds[i].revents) {

39:     /* fds[i] готов для чтения, двигаться дальше... */

40:     rc = read(fds[i].fd, buf, sizeof(buf) - 1);

41:     if (rc < 0) {

42:      perror("read");

43:      return 1;

44:     } else if (!rc) {

45:      /* этот канал закрыт, не пытаться

46:         читать из него снова */

47:      fds[i].events = 0;

48:     } else {

49:      buf[rc] = '\0';

50:      printf("чтение : %s", buf);

51:     }

52:    }

53:   }

54:  }

55:

56:  return 0;

57: }

13.1.3. Мультиплексирование с помощью select()

Системный вызов poll() был изначально представлен как часть Unix-дерева System V. Усилиями разработчиков BSD та же основная проблема была решена похожим способом — предоставлением системного вызова select().

#include <sys/select.h>


int select(int numfds, fd_set * readfds, fd_set * writefds,

 fd_set * exceptfds, struct timeval * timeout);

Три промежуточных параметра — readfds, writefds и exceptfds — определяют, за какими файловыми дескрипторами необходимо следить. Каждый параметр — это указатель на fd_set, структуру данных, позволяющую процессу определить произвольное количество файловых дескрипторов[74]. Ею манипулируют с помощью перечисленных ниже макросов.

FD_ZERO(fd_set * fds); Очищает fds — в наборе не содержатся файловые дескрипторы. Этот макрос используется для инициализации структур fd_set.
FD_SET(intfd, fd_set * fds); Добавляет fd к fd_set.
FD_CLR(intfd, fd_set * fds); Удаляет fd из fd_set.
FD_ISSET(int fd, fd_set * fds); Возвращает true, если fd содержится в установленном fds.

Первый набор файловых дескрипторов select(), readfds, содержит перечень файловых дескрипторов, вызывающих возврат вызова select(), когда они готовы для чтения[75] или (для каналов и сокетов) когда процесс на другом конце файла закрыл его. Когда любой файловый дескриптор в writefds готов к записи, select() возвращается, exceptfds содержит файловые дескрипторы для слежения за исключительными условиями. В Linux (так же, как и в Unix) это происходит только при поступлении внешних данных в сетевое подключение. В качестве любого из них можно указать NULL, если тот или иной тип события вас не интересует.

Окончательный параметр, timeout, определяет, насколько долго (в миллисекундах) вызову select() необходимо ожидать какого-либо события. Это указывает на struct timeval, которая выглядит следующим образом.

#include <sys/time.h>


struct timeval {

 int tv_sec; /* секунды */

 int tv_usec; /* микросекунды */

};

Первый элемент — tv_sec — это количество оставшихся секунд, a tv_usec — это количество оставшихся микросекунд. Если значением timeout является NULL, select() блокируется до следующего события. Если он указывает на struct timeval, содержащую 0 в обоих элементах, вызов select() не блокируется. Он обновляет наборы файловых дескрипторов, чтобы определить, какой файловый дескриптор в настоящее время готов для чтения или записи, а затем немедленно возвращается.

Первый параметр, numfds, вызывает наибольшие трудности. Он задает количество файловых дескрипторов (начиная с файлового дескриптора 0), которое может быть определено с помощью fd_sets. Еще один (и, возможно, более легкий) способ поведения numfds намного лучше максимального файлового дескриптора select()[76].

Поскольку Linux обычно позволяет каждому процессу иметь до 1024 файловых дескрипторов, numfds избавляет ядро от необходимости просмотра всех 1024 файловых дескрипторов, которые может содержать каждая структура fd_set, что улучшает показатели производительности.

После возврата три структуры fd_set содержат файловые дескрипторы с задержкой входных данных, на которые можно произвести запись или которые находятся в исключительном состоянии. Вызов select() в Linux возвращает общее количество элементов, установленных в трех структурах fd_set, 0 в случае тайм-аута вызова либо -1 в случае ошибки. Однако многие системы Unix считают определенные файловые дескрипторы в возвращаемом значении только один раз, даже если они находятся как в readfds, так и в writefds, поэтому в целях переносимости лучше совершать проверку только тогда, когда возвращаемое значение больше 0. Если возвращаемое значение равно -1, не думайте, что структуры fd_set остаются незатронутыми. Linux обновляет их только в случае, если select() возвращает значение больше 0, однако некоторые системы Unix демонстрируют иное поведение.

Еще одним параметром, связанным с переносимостью, является timeout. Ядра Linux[77] обновляют его, чтобы отобразить количество времени, оставшегося до тайм-аута вызова select(), но большинство других систем Unix его не обновляют[78]. Однако другие системы не обновляют тайм-аут с целью соответствия более привычной реализации.

Для переносимости устраните зависимость от поведения и явно настройте структуру timeout перед вызовом select().

Теперь рассмотрим несколько примеров применения select(). Для начала используем select() без связи с файлами, создав вторичный вызов sleep().

#include <sys/select.h>

#include <sys/stdlib.h>


int usecsleep(int usees) {

 struct timeval tv;

 tv.tv_sec = 0;

 tv.tv_usec = useсs;

 return select(0, NULL, NULL, NULL, &tv);

}

Этот код разрешает переносимые паузы длительностью менее секунды (это обеспечивает также библиотечная функция BSD usleep(), но select() намного более переносима). Например, usecsleep(500000) вызывает паузу минимум на полсекунды.

Вызов select() также используется для решения примера мультиплексирования каналов, с которым мы работали. Решение очень похоже на решение при использовании poll().

 1: /* mpx-select.c */

 2:

 3: #include <fcntl.h>

 4: #include <stdio.h>

 5: #include <sys/select.h>

 6: #include <unistd.h>

 7:

 8: int main(void) {

 9:  int fds[2];

10:  char buf[4096];

11:  int i, rc, maxfd;

12:  fd_set watchset; /* fds для чтения */

13:  fd_set inset; /* обновляется select() */

14:

15:  /* открыть оба канала */

16:  if ((fds[0] = open("p1", O_RDONLY | O_NONBLOCK)) < 0) {

17:   perror("open p1");

18:   return 1;

19:  }

20:

21:  if ((fds[1] = open("p2", O_RDONLY | O_NONBLOCK)) < 0) {

22:   perror("open p2");

23:   return 1;

24:  }

25:

26:  /* начать чтение из обоих файловых дескрипторов */

27:  FD_ZERO(&watchset);

28:  FD_SET(fds[0], &watchset);

29:  FD_SET(fds[1], &watchset);

30:

31:  /* найти максимальный файловый дескриптор */

32:  maxfd = fds[0] > fds[1] ? fds[0] : fds[1];

33:

34:  /* пока наблюдаем за одним из fds[0] или fds[1] */

35:  while (FD_ISSET(fds[0], &watchset) ||

36:   FD_ISSET(fds[1], &watchset)) {

37:   /* здесь копируем watchset, потому что select() обновляет его */

38:   inset = watchset;

39:   if (select(maxfd + 1, &inset, NULL, NULL, NULL) < 0) {

40:    perror("select");

41:    return 1;

42:   }

43:

44:   /* проверить, какой из файловых дескрипторов

45:      готов для чтения из него */

46:   for (i = 0; i < 2; i++) {

47:    if (FD_ISSET(fds[i], &inset )) {

48:     /* fds[i] готов для чтения, двигаться дальше... */

49:     rc = read(fds[i], buf, sizeof (buf) - 1);

50:     if (rc < 0) {

51:      perror("read");

52:      return 1;

53:     } else if (!rc) {

54:      /* этот канал закрыт, не пытаться

55:         читать из него снова */

56:      close(fds[i]);

57:      FD_CLR(fds[i], &watchset);

58:     } else {

59:      buf[rc] = '\0';

60:      printf("чтение: %s", buf);

61:     }

62:    }

63:   }

64:  }

65:

66:  return 0;

67: }

13.1.4. Сравнение poll() и select()

Обладая одинаковой функциональностью, poll() и select() также имеют существенные отличия. Наиболее очевидным отличием является тайм-аут, поддерживающий миллисекундную точность для poll() и микросекундную точность для select(). В действительности же это отличие почти незначительно, поскольку ни один системный вызов не будет подготовлен с точностью до микросекунды.

Более важное отличие связано с производительностью. Интерфейс poll() обладает несколькими свойствами, делающими его намного эффективнее, чем select().

1. При использовании select() ядру необходимо проверить все файловые дескрипторы между 0 и numfds - 1, чтобы убедиться, заинтересовано ли приложение в событиях ввода-вывода для этого файлового дескриптора. Для приложений с большим количеством открытых файлов это может привести к существенным затратам, поскольку ядро проверяет, какие именно файловые дескрипторы являются объектом интереса.

2. Набор файловых дескрипторов передается ядру как битовая карта для select() и как список для poll(). Сложные битовые операции, необходимые для проверки и установки структур данных fd_set, менее эффективны, чем простые проверки, требуемые для struct pollfd.

3. Поскольку ядро переписывает структуры данных, передаваемые select(), приложение вынуждено сбрасывать эти структуры каждый раз перед вызовом select(). С poll() результаты ядра ограничены элементом revents, что устраняет потребность в восстановлении структур данных после каждого вызова.

4. Использование структуры, основанной на множествах (например, fd_set) не масштабируется по мере увеличения количества доступных процессу файловых дескрипторов. Поскольку ее размер статичен, а не динамичен (обратите внимание на отсутствие соответствующего макроса, например, FD_FREE), она не может расширяться или сжиматься в соответствии с потребностями приложения (или возможностями ядра). В Linux максимальный файловый дескриптор, который можно установить в fd_set, равен 1023. Если понадобится больший файловый дескриптор, select() работать не будет.

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

Следующая короткая программа, подсчитывающая количество системных вызовов в секунду, демонстрирует, насколько poll() эффективнее select().

 1: /* select-vs-poll.с */

 2:

 3: #include <fcntl.h>

 4: #include <stdio.h>

 5: #include <sys/poll.h>

 6: #include <sys/select.h>

 7: #include <sys/signal.h>

 8: #include <unistd.h>

 9:

10: int gotAlarm;

11:

12: void catch(int sig) {

13:  gotAlarm = 1;

14: }

15:

16: #define HIGH_FD 1000

17:

18: int main(int argc, const char ** argv) {

19:  int devZero;

20:  int count;

21:  fd_set select Fds;

22:  struct pollfd pollFds;

23:

24:  devZero = open("/dev/zero", O_RDONLY);

25:  dup2(devZero, HIGH_FD);

26:

27:  /* с помощью signal выяснить, когда время истекло */

28:  signal(SIGALRM, catch);

29:

30:  gotAlarm =0;

31:  count = 0;

32:  alarm(1);

33:  while (!gotAlarm) {

34:   FD_ZERO(&selectFds);

35:   FD_SET(HIGH_FD, &selectFds);

36:

37:   select(HIGH_FD + 1, &selectFds, NULL, NULL, NULL);

38:   count++;

39:  }

40:

41:  printf("Вызовов select() в секунду: %d\n", count);

42:

43:  pollFds.fd = HIGH_FD;

44:  pollFds.events = POLLIN;

45:  count = 0;

46:  gotAlarm = 0;

47:  alarm(1);

48:  while (!gotAlarm) {

49:   poll(&pollFds, 0, 0);

50:   count++;

51:  }

52:

53:  printf("Вызовов poll() в секунду: %d\n", count);

54:

55:  return 0;

56: }

Здесь используется устройство /dev/zero, предоставляющее бесконечное количество нулей, что обеспечивает немедленный возврат системных вызовов. Значение HIGH_FD можно изменить, чтобы посмотреть, как деградирует select() по мере роста значений файловых дескрипторов.

В определенной системе при не очень высоком значении HIGH_FD, равном 2, программа показала, что ядро за секунду может обрабатывать в четыре раза больше вызовов poll(), чем вызовов select(). При увеличении HIGH_FD до 1000 эффективность poll() становится в 40 раз выше, чем у select().

13.1.5. Мультиплексирование с помощью epoll

В версии 2.6 ядра Linux был предложен третий метод для мультиплексированного ввода-вывода по имени epoll. Будучи более сложным, чем poll() или select(), epoll ликвидирует узкие места, связанные с производительностью, которые характерны для обоих методов.

Оба системных вызова poll() и select() передают на проверку полный список файловых дескрипторов при каждом вызове. Каждый из этих дескрипторов должен быть обработан системным вызовом, даже если только один из них готов к чтению или записи. Когда проверяются десятки, сотни или тысячи файловых дескрипторов, эти системные вызовы превращаются в узкие места; ядро тратит много времени на выяснение того, какие именно файловые дескрипторы приложению необходимо проверить.

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

Преимущества в плане производительности epoll требуют более сложного, чем у poll() или select(), интерфейса системных вызовов. В то время как poll() использует массив struct pollfd для предоставления набора файловых дескрипторов, a select() с той же целью — три разных структуры fd_set, epoll перемещает эти наборы файловых дескрипторов в ядро, а не хранит их в адресном пространстве программы. На каждый из этих наборов ссылаются с помощью дескриптора epoll, являющегося файловым дескриптором, который можно применять только для системных вызовов epoll. Новые дескрипторы epoll распределяются системным вызовом epoll_create().

#include <sys/epoll.h>


int epoll_create (int numDescriptors);

Единственный параметр numDescriptors — это наилучшее предположение программы о том, на какое количество файловых дескрипторов будет ссылаться заново созданный дескриптор epoll. Это не жесткий предел, это просто подсказка ядру для более точной инициализации его внутренних структур. epoll_create() возвращает дескриптор epoll, а когда программа заканчивает работу с дескриптором, его следует передать close(), чтобы позволить ядру освободить память, используемую этим дескриптором.

Хотя дескриптор epoll является файловым дескриптором, его следует применять только с двумя системными вызовами.

#include <sys/epoll.h>


int epoll_ctl(int epfd, int op, int fd, struct epoll_event * event);

int epoll_wait(int epfd, struct epoll_event * events, int maxevents,

 int timeout);

Большинство этих параметров используют структуру struct epoll_event, которая определяется, как показано ниже.

#include <sys/epoll.h>


struct epoll_event {

 int events;

 union {

  void * ptr;

  int fd;

  unsigned int u32;

  unsigned long long u64;

 } data;

};

Эта структура обслуживает три цели: определяет, какие типы событий следует проверять, определяет типы произошедших событий и ассоциирует отдельный элемент данных с файловым дескриптором. Поле events предназначено для первых двух функций и является одной или несколькими перечисленными далее значениями, объединенными с помощью логического "ИЛИ"[80].

EPOLLIN Определяет, что операция read() не блокируется; данные или уже готовы, или их уже не осталось для считывания.
EPOLLOUT Связанный файл готов для записи.
EPOLLPRI Файл имеет внешние данные, готовые для чтения.

Второй элемент struct epoll_event, data, представляет собой объединение, содержащее целое число (для хранения файлового дескриптора), указатель, а также 32- и 64-битные целые числа[81]. Этот элемент данных хранится в epoll и возвращается в программу всякий раз, когда происходит событие подходящего типа. Элемент data — это единственный способ, с помощью которого программе нужно выяснить, какой файловый дескриптор необходимо обслужить; интерфейс epoll не передает файловый дескриптор программе, в отличие от poll() и select() (если data не содержит файловый дескриптор). Этот метод обеспечивает дополнительную гибкость приложениям, которые отслеживают файлы как нечто, более сложное, чем простые файловые дескрипторы.

Системный вызов epoll_ctl() добавляет файловые дескрипторы к набору, на который ссылается дескриптор epfdepoll, и удаляет их из него.

Второй параметр, op, описывает, каким образом следует модифицировать набор файловых дескрипторов, и является одним из перечисленных ниже.

EPOLL_CTL_ADD Файловый дескриптор fd добавляется к набору файловых дескрипторов набором событий events. Если файловый дескриптор уже присутствует, он возвращает EEXIST. (Несколько потоков могут добавлять тот же файловый дескриптор к набору epoll более одного раза, но это действие ничего не меняет.)
EPOLL_CTL_DEL Файловый дескриптор fd удаляется из контролируемого набора файловых дескрипторов. Параметр events должен указывать на struct epoll_event, но содержимое этой структуры игнорируется. (Это еще раз доказывает, что events должен быть допустимым указателем; он не может быть NULL.)
EPOLL_CTL_MOD Системный вызов struct epoll_event для fd обновляется на основе информации, на которую указывает events. Это позволяет контролировать набор событий и обновлять элемент данных, ассоциируемый с файловым дескриптором, не создавая условий состязания.

Последним системным вызовом epoll является epoll_wait(), который блокирует до тех пор, пока один или несколько контролируемых файловых дескрипторов не будут иметь данные для чтения или же не будут готовы к записи. Первым аргументом является дескриптор epoll, а последний — тайм-аутом в секундах. Если файловые дескрипторы не готовы к обработке до истечения тайм-аута, epoll_wait() возвращает 0.

Два промежуточных параметра определяют буфер для ядра, в который можно копировать структуры struct epoll_event. Параметр events указывает на буфер, maxevents определяет, какое количество структур struct epoll_event помещается в буфер, а возвращаемое значение сообщает программе количество структур, помещенных в этот буфер (пока вызов не попадет в состояние тайм-аута либо не произойдет ошибка).

Каждый системный вызов struct epoll_event сообщает программе полное состояние контролируемого файлового дескриптора. Элемент events может иметь установленные флаги EPOLLIN, EPOLLOUT или EPOLLPRI, а также два новых флага, которые описаны ниже.

EPOLLERR С файлом связано ожидающее состояние ошибки; это случается, если ошибка происходит в сокете, когда приложение не считывает из него или не записывает в него.
EPOLLHUP Файловый дескриптор завис; в главе 10 дана информация о том, когда это обычно происходит.

На первый взгляд это все может показаться сложным, но на самом деле это очень похоже на работу poll(). Вызов epoll_create() — это то же, что и распределение массива struct pollfd, a epoll_ctl() — это то же, что и инициализация элементов этого массива. Главный цикл, обрабатывающий файловые дескрипторы, использует epoll_wait() вместо системного вызова poll(), а close() аналогичен освобождению памяти, занимаемой массивом struct pollfd. Эти параллели помогают переписывать с применением epoll программы мультиплексирования, которые изначально были реализованы с помощью poll() или select().

Интерфейс epoll предлагает еще одну возможность, которую невозможно сравнить с poll() или select(). Поскольку дескриптор epoll в действительности является файловым дескриптором (вот почему его можно передавать close()), имеется возможность контролировать дескриптор epoll как часть еще одного дескриптора epoll либо через poll() или select(). Дескриптор epoll будет готов к чтению из любого места, а вызов epoll_wait() вернет события.

В окончательном решении проблемы мультиплексирования каналов, предложенном в данном разделе, используется epoll. Оно очень похоже на другие примеры, вот только определенная часть кода инициализации перемещена в новую функцию addEvent() для предотвращения нежелательного удлинения программы.

 1: /* mpx-epoll.c */

 2:

 3: #include <fcntl.h>

 4: #include <stdio.h>

 5: #include <stdlib.h>

 6: #include <sys/epoll.h>

 7: #include <unistd.h>

 8:

 9: #include <sys/poll.h>

10:

11: void addEvent(int epfd, char * filename) {

12:  int fd;

13:  struct epoll_event event;

14:

15:  if ((fd = open (filename, O_RDONLY | O_NONBLOCK)) < 0) {

16:   perror("open");

17:   exit(1);

18:  }

19:

20:  event.events = EPOLLIN;

21:  event.data.fd = fd;

22:

23:  if (epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event)) {

24:   perror("epoll_ctl(ADD)");

25:   exit(1);

26:  }

27: }

28:

29: int main(void) {

30:  char buf[4096];

31:  int i, rc;

32:  int epfd;

33:  struct epoll_event events[2];

34:  int num;

35:  int numFds;

36:

37:  epfd = epoll_create(2);

38:  if (epfd < 0) {

39:   perror("epoll_create");

40:   return 1;

41:  }

42:

43:  /* открыть оба канала и добавить их в набор epoll */

44:  addEvent(epfd, "p1");

45:  addEvent(epfd, "p2");

46:

47:  /* продолжать, пока есть один или более файловых дескрипторов

48:     для слежения */

49:  numFds = 2;

50:  while (numFds) {

51:   if ((num = epoll_wait(epfd, events,

52:    sizeof(events) / sizeof(* events),

53:    -1)) <= 0) {

54:   perror("epoll_wait");

55:   return 1;

56:  }

57:

58:  for (i = 0; i < num; i++) {

59:   /* events[i].data.fd готов для чтения */

60:

61:   rc = read(events[i].data.fd, buf, sizeof(buf) - 1);

62:   if (rc < 0) {

63:    perror("read");

64:    return 1;

65:   } else if (!rc) {

66:    /* этот канал закрыт, не пытаться

67:       читать из него снова */

68:    if (epoll_ctl(epfd, EPOLL_CTL_DEL,

69:     events[i].data.fd, &events[i])) {

70:     perror("epoll_ctl (DEL)");

71:     return 1;

72:    }

73:

74:    close(events[i].data.fd);

75:

76:    numFds--;

77:   } else {

78:    buf[rc] = '\0';

79:    printf("чтение: %s", buf);

80:

81:   }

82:  }

83:

84:  close(epfd);

85:

86:  return 0;

87: }

13.1.6 Сравнение poll() и epoll

Методы poll() и epoll существенно отличаются; poll() хорошо стандартизован, но плохо масштабируется, в то время как epoll существует только в Linux, но очень хорошо масштабируется. Приложения, наблюдающие за небольшим количеством файловых дескрипторов и переносимости величин, должны использовать poll(), но любому приложению, которому необходимо контролировать большое количество дескрипторов, лучше применять epoll, даже если ему нужно поддерживать poll() для других платформ.

Отличия в производительности двух методов поразительны. Чтобы продемонстрировать, насколько лучше масштабируется epoll, в коде poll-vs-epoll.с измеряется количество системных вызовов poll() и epoll_wait(), которые можно создать за одну секунду для наборов файловых дескрипторов разных размеров (количество файловых дескрипторов для помещения в набор задается в командной строке). Каждый файловый дескриптор ссылается на считывающую часть канала, и они создаются с помощью dup2().

В табл. 13.1 суммируются результаты запуска poll-vs-epoll.с для установленных размеров диапазоном от одного до 100 000 файловых дескрипторов[82]. В то время как количество системных вызовов в секунду резко падает для poll(), оно остается почти постоянным для epoll[83]. Как поясняет эта таблица, epoll добавляет в систему намного меньше нагрузки, чем poll(), и в результате гораздо лучше масштабируется.


Таблица 13.1. Результаты сравнения poll() и epoll()

Файловые дескрипторы poll() epoll()
1 310063 714848
10 140842 726108
100 25866 726659
1000 3343 729072
5000 612 718424
10000 300 730483
25000 108 717097
50000 38 729746
100000 18 712301

  1: /* poll-vs-epoll.с */

  2:

  3: #include <errno.h>

  4: #include <fcntl.h>

  5: #include <stdio.h>

  6: #include <sys/epoll.h>

  7: #include <sys/poll.h>

  8: #include <sys/signal.h>

  9: #include <unistd.h>

 10: #include <sys/resource.h>

 11: #include <string.h>

 12: #include <stdlib.h>

 13:

 14: #include <sys/select.h>

 15:

 16: int gotAlarm;

 17:

 18: void catch(int sig) {

 19:  gotAlarm = 1;

 20: }

 21:

 22: #define OFFSET 10

 23:

 24: int main(int argc, const char ** argv) {

 25:  int pipeFds[2];

 26:  int count;

 27:  int numFds;

 28:  struct pollfd * pollFds;

 29:  struct epoll_event event;

 30:  int epfd;

 31:  int i;

 32:  struct rlimit lim;

 33:  char * end;

 34:

 35:  if (!argv[1]) {

 36:   fprintf(stderr, "ожидалось число\n");

 37:   return 1;

 38:  }

 39:

 40:  numFds = strtol(argv[1], &end, 0);

 41:  if (*end) {

 42:   fprintf(stderr, "ожидалось число\n");

 43:   return 1;

 44:  }

 45:

 46:  printf("Запуск теста для %d файловых дескрипторов.\n", numFds);

 47:

 48:  lim.rlim_cur = numFds + OFFSET;

 49:  lim.rlim_max = numFds + OFFSET;

 50:  if (setrlimit(RLIMIT_NOFILE, &lim)) {

 51:   perror("setrlimit");

 52:   exit(1);

 53:  }

 54:

 55:  pipe(pipeFds);

 56:

 57:  pollFds = malloc(sizeof (*pollFds) * numFds);

 58:

 59:  epfd = epoll_create(numFds);

 60:  event.events = EPOLLIN;

 61:

 62:  for (i = OFFSET; i < OFFSET + numFds; i++) {

 63:   if (dup2(pipeFds[0], i) != i) {

 64:    printf("сбой в %d: %s\n", i, strerror(errno));

 65:    exit(1);

 66:   }

 67:

 68:   pollFds[i - OFFSET].fd = i;

 69:   pollFds[i - OFFSET].events = POLLIN;

 70:

 71:   event.data.fd = i;

 72:   epoll_ctl(epfd, EPOLL_CTL_ADD, i, &event);

 73:  }

 74:

 75:  /* с помощью signal выяснить, когда время истекло */

 76:  signal(SIGALRM, catch);

 77:

 78:  count = 0;

 79:  gotAlarm = 0;

 80:  alarm(1);

 81:  while (!gotAlarm) {

 82:   poll(pollFds, numFds, 0);

 83:   count++;

 84:  }

 85:

 86:  printf("Вызовов poll() в секунду: %d\n", count);

 87:

 88:  alarm(1);

 89:

 90:  count = 0;

 91:  gotAlarm = 0;

 92:  alarm(1);

 93:  while (!gotAlarm) {

 94:   epoll_wait(epfd, &event, 1, 0);

 95:   count++;

 96:  }

 97:

 98:  printf("Вызовов epoll() в секунду: %d\n", count);

 99:

100:  return 0;

101: }

13.2. Отображение в памяти

Операционная система Linux позволяет процессу отображать файлы в их адресное пространство. Такое отображение создает взаимно однозначное соответствие между данными в файле и в отображаемой области памяти. Отображение в памяти обладает рядом преимуществ.

Высокоскоростной доступ к файлам. Нормальные механизмы ввода-вывода, такие как read() и write(), вынуждают ядро копировать данные через буфер ядра, а не непосредственно между файлом, содержащим устройство, и процессом пространства пользователя. Карты памяти устраняют этот промежуточный буфер, сохраняя копию памяти[84].

Исполняемые файлы можно отображать на память программы, позволяя программе динамически загружать новые исполняемые области. Именно так реализуется динамическая загрузка, описанная в главе 27.

Новую память можно распределить отображением части /dev/zero, специального устройства, состоящего из нулей[85], или же через анонимное отображение. Средство Electric Fence, описанное в главе 7, использует этот механизм для распределения памяти.

Новую память, распределенную посредством карт памяти, можно сделать исполняемой, наполняя ее машинными командами, которые затем запускаются. Это свойство используется оперативными (just-in-time) компиляторами.

Файлы могут рассматриваться как память и читаться с использованием указателей, а не системных вызовов. Это существенно упрощает программы, избавляя от необходимости применения вызовов read(), write() и seek().

Отображение в памяти позволяет процессам совместно использовать области памяти, участвующие в создании и уничтожении процесса. Содержимое памяти хранится в отображаемом файле, делая его независимым от процессов.

13.2.1. Выравнивание по страницам

Системная память делится на порции под названием страницы. Размер страницы изменяется в зависимости от архитектуры, и на некоторых процессорах размер страницы может изменяться ядром. Функция getpagesize() возвращает размер (в байтах) каждой страницы системы.

#include <unistd.h>


size_t getpagesize(void);

Для каждой страницы системы ядро сообщает оборудованию, каким образом каждый процесс может получить доступ к странице (например, записать, выполнить или не выполнять никаких действий). Когда процесс пытается получить доступ к странице способом, нарушающим ограничения ядра, это вызывает ошибку сегментации (SIGSEGV), которая обычно приводит к завершению процесса.

Адрес памяти должен быть выровнен по страницам, если это адрес начала страницы. Иначе говоря, адрес должен быть целым, кратным размеру страницы архитектуры. В системе со страницами в 4 Кбайт адреса 0, 4 096, 16 384 и 32 768 являются выровненными по страницам (конечно, это далеко не весь список), потому что первая, вторая, пятая и девятая страницы системы начинаются с указанных адресов.

13.2.2. Установка отображения в памяти

Новые карты памяти создаются с помощью системного вызова mmap().

#include <sys/mman.h>


caddr_tmmap(caddr_t address, size_t length , int protection, int flags,

 int fd, off_t offset);

Параметр address указывает, где именно в памяти необходимо отображать данные. Обычно address — это NULL, который означает, что для процесса не имеет значения местонахождение новой карты, и позволяет ядру выбрать любой адрес. Если адрес указан, он должен быть выровнен по страницам и в данный момент не использоваться. Если запрашиваемая карта будет конфликтовать с другой картой или не будет выровнена по страницам, mmap() может дать сбой.

Второй параметр, length, сообщает ядру, какую часть файлов следует отображать в памяти. Можно успешно отобразить больше памяти, чем количество данных в наличии у файла, но попытка доступа к нему может привести к SIGSEGV[86].

Процесс проверяет, какие типы доступа разрешены новой области памяти. Это должно быть одно или несколько значений из табл. 13.2, объединенных с помощью битового "ИЛИ", либо PROT_NONE, если доступ к отображаемой области запрещен. Файл может отображаться только для типов доступа, которые также были запрошены при изначальном открытии файла. Например, файл, открытый как O_RDONLY, не может быть отображен для записи с помощью PROT_WRITE.


Таблица 13.2. Флаги защиты mmap()

Флаг Описание
PROT_READ Из отображаемой области можно читать.
PROT_WRITE В отображаемую область можно записывать.
PROT_EXEC Отображаемую область можно выполнять.

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

По этой причине на флаги защиты памяти, передаваемые в mmap(), следует полагаться лишь как на обеспечивающие минимальную защиту.

В flags определяются другие атрибуты отображаемой области. В табл. 13.3 описаны все флаги. Многие флаги, поддерживаемые Linux, нестандартны, но могут быть полезны при особых условиях. В табл. 13.3 приведены различия между стандартными флагами mmap() и дополнительными флагами Linux. Во всех вызовах mmap() должен быть специфицирован MAP_PRIVATE или MAP_SHARED; остальные флаги устанавливать необязательно.


Таблица 13.3. Флаги mmap()

Флаг POSIX? Описание