Искусство программирования для Unix

Реймонд Эрик Стивен

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

Широко распространенная программа с открытым исходным кодом, которая называется screen(1), решает некоторые из этих проблем¹¹⁸. Однако поскольку пользователь должен ее вызвать явно, не гарантируется, что ее возможности будут присутствовать

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

20.3.6. В Unix API не используются исключительные ситуации

Язык С испытывает недостаток средств восстановления для обработки именованных исключительных ситуаций со связанными данными¹¹⁹. Таким образом, С-функции в Unix API сообщают об ошибках путем возвращения известного значения (обычно -1 или указатель на NULL-символ) и установки глобальной переменной errno.

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

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

Данная проблема может быть скрыта (и обычно скрывается) привязками Unix API в таких языках, как Python или Java, в которых есть исключительные ситуации.

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

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

20.3.7. Вызовы ioctl(2) и fcntl(2) являются препятствиями

Механизмы ioctl(2) и fcntl(2) обеспечивают способ написания перехватчиков (hooks) в драйверах устройств. Первоначальным историческим использованием ioctl(2) была установка параметров, таких как скорость передачи и количество фреймирующих битов в драйверах последовательных линий, отсюда и название ("I/O control"). Позднее вызовы ioctl были добавлены для других драйверов, a fcntl(2) был добавлен как перехватчик в файловую систему.

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

Основная проблема в данном случае та же, что и "большой блок байтов"; объектная модель Unix слабая и не оставляет

естественного пространства для размещения многих вспомогательных операций. Разработчики получают сложный выбор из неудовлетворительных альтернатив. Вызовы f cntl/ioctl проходят через устройства в /dev, новые специализированные системные вызовы или методы через специализированные виртуальные файловые системы, которые привязаны к ядру (например, /ргос Linux и др.).

Пока не ясно, улучшится ли в будущем объектная модель Unix, а если улучшится, то каким образом. Если MacOS-подобные атрибуты файлов станут обычной функцией Unix, подстройка "магических" именованных атрибутов на драйверах устройств может взять на себя роль, которую в настоящее время играют вызовы ioctl/fcntl (это, по крайней мере, исключило бы необходимость в применении макроопределений перед использованием интерфейса). Выше уже отмечалось, что операционная система Plan 9, в которой вместо модели файл/поток байтов используется именованный файловый сервер или файловая система как базовый объект, представляет другой возможный путь.

20.3.8. Модель безопасности Unix, возможно, слишком примитивна

Возможно, полномочия пользователя root слишком широки, и в Unix должны быть возможности более четкой градации полномочий или ACL (Access Control Lists — списки контроля доступа) для функций системного администрирования, чем один суперпользователь, который может все. Люди, которые принимают данную позицию, спорят, что многие системные программы имеют постоянные root-привилегии благодаря механизму setuid. Если даже одну из них можно будет взломать, то вторжения последуют везде.

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

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

20.3.9. Unix имеет слишком много различных видов имен

Unix объединила файлы и локальные устройства — они являются просто потоками байтов. Однако сетевые устройства, доступные через сокеты, имеют иную семантику и другое пространство имен. Plan 9 показывает, что файлы вполне можно сочетать как с локальными, так и с удаленными (сетевыми) устройствами, и все это может управляться через пространство имен, которое способно динамически настраиваться для каждого пользователя и даже для каждой программы.

20.3.10. Файловые системы могут считаться вредными

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

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