CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
15.12.2017

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Дистрибутивы :: BSD :: DragonFly BSD

DragonFly - пользовательский API

В большинстве стандартных UNIX-систем используется таблица системных вызовов, посредством которой передаются вперед-назад большинство типов данных, в том числе недоработанные структуры. Крупнейшим препятствием на пути взаимодействия программ пользователя с ядрами, более новыми или более старыми, чем сами программы, является частое изменение недоработанных структур. Основными виновниками являются сетевые интерфейсы, ioctl таблиц маршрутизации, ipfw, недоработанные процессные структуры ps, vmstat и т.д. Но даже у таких неописуемых системных вызовов как stat() и readddir() имеются проблемы. В более общих словах, проблемы переносимости могут порождаться самим списком системных вызовов.

Целью настоящего проекта является: (1) сделать все существующие системные вызовы основанными на сообщениях; (2) передавать структурную информацию посредством списков возможностей и элементов, а не в виде недоработанных структур; 3) реализовать обобщенный "промежуточный слой", несколько напоминающий уровень эмуляции, управляемый ядром, но загружаемый в пользовательское пространство. Этот слой реализует API всех стандартных системных вызовов и преобразует их в соответствующие сообщения.

Например, эмуляция Linux будет производиться в (защищённом ядром) пользовательском пространстве, а не в пространстве ядра. Эмуляция FreeBSD будет работать таким же образом. В действительность, даже "родные" программы будут проникать через слой эмуляции, чтобы увидеть системный вызов, который мы все знаем и любим. Единственное отличие состоит в том, что "родные" программы будут знать о существовании слоя эмуляции, напрямую доступного из юзерланда, и не будут расходовать дополнительные команды INT0x80 (или что-либо еще) для входа в ядро, чтобы снова быть выброшенными в слой эмуляции.

Еще одним огромным преимуществом преобразования системных вызовов в сущности, основанные на сообщениях, является полное разрешение проблем пользовательских нитей. Для управления множественными пользовательскими нитями больше не потребуется множество ядерных контекстов и стеков, будет нужно только по одному ядерному контексту и стеку на каждый пользовательский процесс. В пользовательских нитях будет по-прежнему использоваться вызов rfork() для создания реального процесса для каждого процессора системы, но все прочие операции будут использовать слой эмуляции, осведомлённый о нитях. На самом деле, почти все вызовы программ в пользовательском пространстве будут исходить от слоя эмуляции в самом пользовательском пространстве, а не прямо от ядра. Вот пример работы слоя эмуляции, осведомленного о нитях:

        ssize_t
        read(int fd, void *buf, size_t nbytes)
        {
            syscall_any_msg_t msg;
            int error;
        
            /*
             * Use a convenient mostly pre-built message stored in
             * the userthread structure for synchronous requests.
             */
            msg = &curthread->td_sysmsg;
            msg->fd = fd;
            msg->buf = buf;
            msg->nbytes = bytes;
            if ((error = lwkt_domsg(&syscall_port, msg)) != 0) {
                curthread->td_errno = error;
                msg->result = -1;
            }
            return(msg->result);
        }

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

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





Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds