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

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

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

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

Основная проблема в данном случае та же, что и 'большой блок байтов'; объектная модель Unix слабая и не оставляет естественного пространства для размещения многих вспомогательных операций. Разработчики получают сложный выбор из неудовлетворительных альтернатив. Вызовы fcntl/ioctl проходят через устройства в /dev, новые специализированные системные вызовы или методы через специализированные виртуальные файловые системы, которые привязаны к ядру (например, /proc 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 [155]) подтверждают, что такие конструкции могут предоставлять большие преимущества, включая доказуемое соответствие политике безопасности и более высокую производительность. Однако следует отметить, что если это проигрыш Unix, то это равный проигрыш всех ее конкурентов. Ни одна крупная действующая операционная система еще не предпочла направление EROS [156].

20.3.11. На пути к глобальному адресному пространству Internet

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

Моим идеалом будущего является развитие удаленного интерфейса файловой системы (а ля Plan 9), а затем его реализация в Internet как стандарта вместо HTML. Это было бы действительно здорово.

Кен Томпсон.

20.4. Проблемы в окружении Unix

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

Одна из таких проблем — как сделать разработку открытого исходного кода экономически целесообразной? Мы вновь 'вернулись к нашим корням' в общем, открытом процессе ранней эпохи Unix. Мы почти совершенно выиграли технический спор об отказе от секретности и частного управления. Мы продумали способы сотрудничества с рынками и менеджерами на более равноправных условиях, чем это было возможно в 70-х и 80-х годах прошлого века, и во многом наши эксперименты были успешными. В 2003 году Unix-системы с открытым исходным кодом и их основные группы разработчиков достигли такого авторитета в обществе, который не так давно, еще в середине 90-х годов был бы невообразимым.