К новой стратегии создания операционных систем

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

Достоинства проекта операционной системы

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

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

Традиционные системы позволяют пользователю добавлять компоненты в массив разделяемых библиотек (так называемый "vmunix"). Но при этом пользователи должны хорошо представлять себе структуру системы и иметь привилегированный статус. Тестирование новых компонентов требует намного более трудоемкого цикла редактирования-компиляции-отладки, чем тестирование прочих программ. Такая проверка не может быть сделана, пока систему использует кто-то другой. Ошибки обычно приводят к фатальному выходу из строя всей системы и невозможности другим пользователям работать с ней. Ядро обычно не разбивается на сегменты (существуют системы с постраничной организацией ядра, но выяснить, какая часть может быть замещена, бывает довольно сложно, и такое решение часто ведет к дополнительным ошибкам). Из-за этих ограничений многие функциональные возможности в традиционных системах вынесены из ядер. Множество отличных идей не было внедрено из-за проблем, присущих монолитной природе традиционных систем. Даже среди тех, кто смог бы внедрить новые идеи, это разрешено лишь тем, кто имеет статус привилегированного пользователя. Система, защищающая авторское право на программное обеспечение, - это трясина, в которой вязнут многие; на защиту текстов ядра даже от чтения людьми, не имеющими лицензий, тратятся огромные усилия.

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

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

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

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

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

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

Механизм трансляции

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

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

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

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

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

Еще один вариант возможного использования трансляторов - это доступ к иерархически организованным данным при помощи файлового протокола. Например, стал ненужным весь сложный интерфейс пользователя к программе FTP. Пользователям необходимо знать только каталог, представляющий FTP; для доступа к удаленной системе они могут использовать обычные команды стандартного манипулирования файлами (например, 1s или ср) вместо того, чтобы создавать новый набор. Аналогично, простой транслятор может облегчить использование tar или gzip. (Такой прозрачный доступ немного увеличивает затраты, но они окупятся).

Общие сервисы

При помощи трансляторов файловая система может действовать как рандеву (т.е. механизм, обеспечивающий сеанс связи) и для интерфейсов, не похожих на файлы. Обсудим сервер, реализующий некоторую версию Х-протокола, используя Mach-сообщения в качестве транспортного уровня. Для каждого Х-дисплея может быть создан файл с соответствующей программой в качестве транслятора. Х-клиенты будут открывать этот файл. Могут быть осмыслены и обычные файловые операции, и несколько новых (XCreateWindows или XDrawText). В этом случае протокол файловой системы нужен только для управления характеристиками узла, используемого для рандеву. Узлу нет необходимости поддерживать операции ввода/вывода, хотя он может отвечать на такие сообщения, посылая коды ошибок, свидетельствующие о том, что сообщение не понято.

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

"Умная" файловая система

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

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

Что может пользователь

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

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

Почему это так необычно?

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

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

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

"Зверинец" HURD

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

Серверы аутентикации

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

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

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

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

Сервер обработки

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

В-третьих, сервер обработки поддерживает взаимооднозначное соответствие между задачами МАСН и процессами HURD. Каждой задаче назначается pid (идентификатор процесса). Процессы могут зарегистрировать порт сообщений, связанный с этим сервером, который предоставляется каждой запросившей его программе. Сервер не делает попыток закрепить порт за данным процессом; предполагается, что пользовательская программа сама определяет необходимую ей степень защиты (в библиотеке GNU С есть удобные для этого функции). Процессы могут вызывать сервер обработки со своими текущими значениями argv (аргументы) и envp (окружение); сервер обработки может затем, по требованию, предоставлять эти значения, что очень удобно при написании программ, подобных ps, а также облегчает задачу изменения или засекречивания этой информации. Ни одно из данных средств не является обязательным. Программы могут не использовать эту информацию и вообще не регистрироваться в сервере обработки. Им, однако, все же назначается pid.

Предусмотрены также средства преобразования между идентификаторами процессов, портами серверов обработки и портами задач МАСН, обеспечивается безопасность портов.

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

Transparent FTP

Transparent (прозрачный) FTP - это очень заманчивая идея, и ее время как раз пришло. Популярный пакет ange-ftp, доступный в рамках GNU Emacs, делает доступ к FTP-файлам практически прозрачным для всех функций манипулирования файлами Emacs. Transparent FTP делает то же самое, но в рамках всей системы в целом. Этот сервер еще не написан, детали еще не ясны до конца и несомненно, вместе с опытом будут и изменения.

В ядре BSD файловую систему, поддерживающую прозрачный ftp, написать было бы не сложнее, чем в Hurd. Но обмолвитесь об этом в разговоре с хакером ядра BSD, и Вы услышите в ответ: "Эта штука к ядру не относится". В известном смысле, это действительно так. Располагать такие вещи в ядре - означает нарушать принцип послойной организации подобных систем. К сожалению, побочный эффект данной методологии проектирования (направленной на то, чтобы помешать пользователям изменять вещи, которые им не нравятся) не позволяет разработчикам системы сделать ее лучше. (Последние реализации ядра BSD позволяют написать пользовательскую программу, реализующую прозрачный ftp. Пример - alex, но она требует полных привилегий root'a.)

В Hurd нет препятствий для реализации прозрачного ftp. Для узла /ftp будет предоставлен транслятор. Содержимое каталога /ftp, возможно, не будет напрямую доступно для просмотра, однако можно ознакомиться с подкаталогами. Вудет довольно много допустимых форматов. Например, обращение к файлам в uunet. "cd /ftp/ftp.uu.net:anonymous.mibOOgnu." Или доступ к файлам в удаленной точке входа: "/ftp/gnu.ai.mit.edu:mib:passwd".

Необязательно указывать первым словом cd - можно использовать любой командный файл. Чтобы найти информацию о RFC 1097 (некоторые сообщения telnet), наберите просто: "more /ftp/ftp.uu.net/inet/rfc/rfc1097". Команду сору для копирования на локальный диск можно использовать, если RFC будет читаться часто.

Файловые системы

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

Протокол сетевой файловой системы NFS будет реализовываться, отталкиваясь от 4.4 BSD. Будет реализована файловая система, использующая те же идеи, что и в Sprite (структурированный журнал), но, вероятно, с другим форматом. Возможно либо создание собственного сетевого протокола GNU, либо расширение и улучшение NFS. Могут также разрабатываться разнообразные "маленькие" файловые системы (такие как файловая система MS-DOS), чтобы помочь пользователям обмениваться файлами между GNU и другими ОС.

Мы написали библиотеку, которая делает создание новой дисковой файловой системы очень легким делом, позволяя файловым системам с разным форматом пользоваться одними и теми же программами, реализовав соответствующим образом вызовы типа rename (переименовать) и open (открыть).

Терминалы

Сервер ввода/вывода будет обеспечивать семантику терминалов Posix.

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

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

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

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

Выполнение программ

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

После установления всех требований, связанных с новым образом задачи, файловая система передает управление серверу выполнения, который должен загрузить задачу. Этот сервер, используя библиотеку BFD (Binary File Descriptor), загружает образ. BFD поддерживает большое число форматов объектных файлов, но все они должны быть выполняемыми. Этот сервер обрабатывает также записи, начинающиеся с "#".

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

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

Новые процессы

Вызов fork реализован практически полностью в рамках бибиотеки GNU С. Новая задача создается при помощи вызова ядра Mach. Библиотека С заботится о том, чтобы создаваемый образ наследовал все необходимые характеристики. Новая задача регистрируется с сервером обработки (хотя это и не обязательно). Библиотека С формирует векторы функций, которые будут вызваны во время ветвления: один вектор будет вызван до ветвления, один - после, из родителя, один - после, из потомка. (Не предполагается использовать эти особенности в качестве замены обычой последовательности ветвления; они рассчитаны на библиотеки, которым необходимо закрыть порты или вызвать процедуру очистки перед выполнением fork). Библиотека С будет поддерживать оба вызова ветвления, специфицированных в предложениях Posix.4a (будущий стандарт, расширяющий механизм нитей для задач обработки данных в реальном масштабе времени).

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

Асинхронные сообщения

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

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

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

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

Сходство с UNIX

Библиотека С будет поддерживать все вызовы из BSD и Posix, а также некоторые очевидные расширения. Это даст возможность пользователям замещать не удовлетворяющие их или не нужные им вызовы, в то время как в Unix вызовы должны использоваться "как они есть", без каких-либо альтернатив.

В некоторых окружениях будет поддерживаться бинарная совместимость. Это будет сделано посредством создания специальной версии библиотеки, загружаемой в определенное место адресного пространства процесса (например, в VAX - в начало стека). Для перехвата системных вызовов UNIX и переключения на специальную версию библиотеки используется средство ядра Mach, называемое переназначением системных вызовов. (В большинстве архитектур затраты на такое переназначение не велики; эта часть хорошо оптимизирована. В 386-м она включает около двух дюжин машинных инструкций. Это лишь немногим больше, чем в обычном вызове процедур.)

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

Сетевые протоколы

В HURD будет включена библиотека, которая значительно облегчит портирование в Hurd стек протоколов 4.4 BSD. Она будет способна поддержать все возможности, доступные в BSD. Напомним, что сейчас это протоколы CCITT, TCP/IP, Xerox NS и ISO.

Требуется некоторая работа по оптимизации производительности,которая будет опираться на средства Hurd, поддерживающие высокоскоростной ввод/вывод. Для большинства протоколов все же необходимо некоторое "время на размышление", но оно не будет слишком велико. HURD будет выполнять протоколы стека TCP/IP так быстро, как только это возможно.

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

Текущее состояние

Сейчас в HURD функционируют сервер выполнения, сервер обработки, сервер аутентикации и первая реализация файловой системы (BSD Fast File System). Простой вариант командного интерпретатора shell может читать и выполнять команды, включая упрощенную версию ps и все программы из набора файловых утилит GNU (в том числе 1n, ср, mv и т.д.). Библиотека, поддерживающая сигналы, еще не полна, но и в этом направлении сделан уже большой шаг вперед. Библиотека сетевых серверов находится в стадии активной разработки. Терминальный драйвер и сервер сокетов еще не написаны.

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

^* M.Bushel, On new strategy of operating system design, /etc/wall, Autumn 1994