Linux API. Исчерпывающее руководство

• Некоторые функции, указанные в SUSv3 как необязательные, становятся обязательной частью стандарта в SUSv4. Например, отдельные функции, составлявшие в SUSv3 часть XSI-расширения, в SUSv4 стали частью базового стандарта. Среди функций, ставших обязательными в SUSv4, можно назвать функции, входящие в API сигналов режима реального времени (раздел 22.8), в API POSIX-таймеров (раздел 23.6), в API dlopen (раздел 42.1) и в API POSIX-семафоров (глава 48).

• Кое-какие функции из SUSv3 в SUSv4 помечены как устаревшие. К их числу относятся asctime(), ctime(), ftw(), gettimeofday(), getitimer(), setitimer() и siginterrupt().

• Спецификации некоторых функций, помеченных в SUSv3 как устаревшие, из SUSv4 удалены. Среди них gethostbyname(), gethostbyaddr() и vfork().

• Различные особенности существующих в SUSv3 спецификаций претерпели изменения в SUSv4. Например, к списку функций, от которых требуется обеспечение безопасной обработки асинхронных сигналов, добавились дополнительные функции (см. табл. 21.1).

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

1.3.6. Этапы развития стандартов UNIX

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

Ситуация с сетевыми стандартами была несколько сложнее. Действия по стандартизации в этой области начали предприниматься в конце 1980-х годов. В то время был образован комитет POSIX 1003.12 для стандартизации API сокетов, API X/Open Transport Interface (XTI) (альтернативный API программирования сетевых приложений на основе интерфейса транспортного уровня System V Transport Layer Interface) и различных API, связанных с работой в сети. Становление стандарта POSIX 1003.12 заняло несколько лет, в течение которых он был переименован в POSIX 1003.1g. Этот стандарт был одобрен в 2000 году.

Параллельно с разработкой POSIX 1003.1g в X/Open велась разработка спецификации X/Open Networking Specification (XNS). Первая ее версия, XNS, выпуск 4, была частью первой версии Single UNIX Specification. За ней последовала спецификация XNS, выпуск 5, которая составила часть SUSv2. По сути, XNS, выпуск 5, была такой же, как и текущая на то время предварительная версия (6.6) POSIX.1g. Затем последовала спецификация XNS, выпуск 5.2, отличавшаяся от XNS, выпуск 5, и был одобрен стандарт POSIX.1g. В нем был помечен устаревшим API XTI и включен обзор протокола Internet Protocol version 6 (IPv6), разработанного в середине 1990-х годов. XNS, выпуск 5.2, заложил основу для документации, относящейся к работе в сети и включенной в замененный нынче стандарт SUSv3. По аналогичным причинам POSIX.1g был отозван в качестве стандарта вскоре после своего одобрения.

Рис. 1.1.Взаимоотношения между различными стандартами UNIX и C

1.3.7. Стандарты реализаций

В дополнение к стандартам, разработанным независимыми компаниями, иногда даются ссылки на два стандарта реализаций, определенных финальным выпуском BSD (4.4BSD) и AT&T’s System V, выпуск 4 (SVR4). Последний стандарт реализации был документально оформлен публикацией System V Interface Definition (SVID) (компания AT&T). В 1989 году AT&T опубликовала выпуск 3 стандарта SVID, определявшего интерфейс, который должна предоставлять реализация UNIX, чтобы называться System V, выпуск 4. (В Интернете SVID можно найти по адресу http://www.sco.com/developers/devspecs/.)

Поскольку поведение некоторых системных вызовов и библиотечных функций в SVR4 и BSD различается, во многих реализациях UNIX предусмотрены библиотеки совместимости и средства условной компиляции. Они эмулируют поведение тех особенностей, которые не были включены в конкретную реализацию UNIX (см. подраздел 3.6.1). Тем самым облегчается портирование приложений из другой реализации UNIX.

1.3.8. Linux, стандарты и нормативная база Linux

В первую очередь разработчики Linux (то есть ядра, библиотеки glibc и инструментария) стремятся соответствовать различным стандартам UNIX, особенно POSIX и Single UNIX Specification. Но на время написания этих строк ни один из распространителей Linux не получил от Open Group права называться UNIX. Проблемы — во времени и средствах. Чтобы получить такое право, каждому дистрибутиву от поставщика необходимо пройти тестирование на соответствие, и с выпуском каждого нового дистрибутива требуется повторное тестирование. Тем не менее близкое соблюдение различных стандартов позволяет Linux успешно оставаться на рынке UNIX.