Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (1)
Запрет регистрации на osrc.info (1)
Ответ Javе и Flash'у (70)
Новая программа поддержки от Microsoft (2)
Solaris будет портирован на Itanium и POWER? (3)
9 декабря вышла новая сборка Xameleon (9)
рассылка (2)
ЗРОС (3)
Новый стиль OSRC.info (2)
Обсуждение статьи "Взгляд на развитие YellowTAB" (124)В Сети
Гостей: 6, Пользователей: 0 ...
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
| Центр информации по операционным системам :: Форумы :: Концепции :: Ядро |
|
<< Предыдущая тема | Следующая тема >> |
| О стандартах | ||
| Переход на страницу [1] 2 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| alman |
| ||
  ID пользователя #753 Зарегистрирован: Суббота 28.10.2006 01:21Местонахождение: планета Земля Сообщений: 95 | Всем привет. Навеяло разговором в мини-чат. Тема о стандартах очень интересная. Одному человек почти невозможно написать систему. Исключения лишь подтверждают правило - пишут тысячи по всему миру, а написали только двое - Торвальдс и Таненбаум. Да и то, если разобраться, писали они не в одиночку. К чему это? Давно собирался описать интерфейсы модулей Xameleon, Наконец собрался и за ночь родился приаттаченный документ. С ужасом думаю что предстоит потоврить аналогичную работу для файловой системы. Там системных вызовов в несколько раз больше. А кто ещё документоровал каки-либо свои разработки? Интересно поделиться опытом. Кстати, если кому что понравитсч/непонравится в протоколе, прошу не стесняться и высказать своё мнение.  753_xam_supervisorproto.pdf<span class='smallblacktext'>[ Редактирование ]</span> | ||
| Наверх |
| ||
| Dron |
| ||
   ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Мне не нравится отсутствие единообразия... Здесь каждый вызов решает свои проблемы мало согласуясь с другими. Кроме того некоторые вызовы у меня язык не поворачивается назвать системными. Короче на первый взгляд весьма безалаберное собрание функций... а если это еще не все функции - то тем более.  Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| alman |
| ||
| ID пользователя #753 Зарегистрирован: Суббота 28.10.2006 01:21Местонахождение: планета Земля Сообщений: 95 | Dron написал(а) ... Мне не нравится отсутствие единообразия... Честно говоря, мне самому не очень нравится что не каждая функция возвращает статус. А ещё в доке проблема в Exec - сртировка неправильно отрабоатала. Dron написал(а) ... Здесь каждый вызов решает свои проблемы мало согласуясь с другими. Может быть я сгруппировал их не очень правильно... Большая часть вызовов не вызывается непосредственно приложениями, а используется другимим модулями. С другой стороны, вызовы реализовались по мере возникновения их необходимости. Поэтому и выглядит так. Dron написал(а) ... Кроме того некоторые вызовы у меня язык не поворачивается назвать системными. Например? А я попробую поспорить, почему эта функция расположилась именно в супервизоре. Dron написал(а) ... Короче на первый взгляд весьма безалаберное собрание функций... а если это еще не все функции - то тем более. Не все. Кажется, в supervisor надо ещё встроить системный вызов управление привелегиями или модифицировать существующие вызовы. <span class='smallblacktext'>[ Редактирование суббота 25.11.2006 01:16 ]</span> | ||
| Наверх |
| ||
| Hmmm |
| ||
 ID пользователя #719 Зарегистрирован: Среда 09.08.2006 11:29Местонахождение: Москва Сообщений: 108 | Модель не без шероховатостей. ProcessCreate, Exec - вообще непонятно откуда берется содержимое процесса (код, данные). Скорее всего Вы просто не дали полного описания функционала этих вызовов. ProcessDestroy - а сообщать статус завершения уже не модно? GetDeviceHandler - в описании параметра device_name написано что это имя запрашиваемого драйвера устройства. Не находите что это странно и не соответствует названию аргумента? Один драйвер может обслуживать несколько устройств с разными именами. Это я к тому что бы Вы определились что же именно должна делать Ваша функция. Я ведь не знаю как будет происходить загрузка драйверов, будет ли на каждое новое устройство создаваться своя копия драйвера или только его контекст. ProcessWait - Вы разницу между process_id и thread_id вообще делаете? | ||
| Наверх | | ||
| alman |
| ||
| ID пользователя #753 Зарегистрирован: Суббота 28.10.2006 01:21Местонахождение: планета Земля Сообщений: 95 | Спасибо за отзыв. Я Вам очень признателен. Hmmm написал(а) ... Модель не без шероховатостей. Признаю. Сейчас дорабатываю. Hmmm написал(а) ... ProcessCreate, Exec - вообще непонятно откуда берется содержимое процесса (код, данные). Скорее всего Вы просто не дали полного описания функционала этих вызовов. Действительно, я не дал полного описания вызовов, потому что с моим английским это трудно сделать. Кроме того, отчёт порезал некоторые поля. Исправлю по возможности. Если Вы не возражаете, то некоторые вещи поясню здесь. ProcessCreate использует область памяти и данные, которые для него приготовил модуль kickstart. Этот модуль является частью поставки Pistachio для архитектуры x86. В принципе, этот системный вызов можно было и не выводить, поскольку он используется одним из потоков супервизора. Но чтобы избежать проблем синхронизации внутренних объектов, он вынесен в общий интерфейс. Его участь - вводить в заблуждение Что касается вызова Exec - то это привелегированный вызов, который использутеся сервисом файловой системы. Реализация Exec в файловой системе, которая имеет обертку в виде libc, работает так - загружает заголовок файла, парсит его. Затем вызывает функцияю супервизора - AllocateSegment и загружает в этот сегмент исполняемый файл. После этого вызывается Exec супервизора, который создает процесс и запускает его. Кстати, код возврата используется файловой системой. А вот верхнеуровневый exec сообщает код возврата только в случае обнаруения ошибки. Hmmm написал(а) ... ProcessDestroy - а сообщать статус завершения уже не модно? Совершенно согласен. Руки не дойдут доделать, а пока дока один в один (ну, почти) по коду. Кстати, если Вы посмотрите новую версию спецификации, то обнаружите что системный вызов файловой системы Exit - таки имеет код возврата. Кажется он даже корректно его возвращает. Hmmm написал(а) ... GetDeviceHandler - в описании параметра device_name написано что это имя запрашиваемого драйвера устройства. Не находите что это странно и не соответствует названию аргумента? Один драйвер может обслуживать несколько устройств с разными именами. Это я к тому что бы Вы определились что же именно должна делать Ваша функция. Скорее всего это проблема документации. Попробую пояснить протокол работы устройств. Каждое устройство, как виртуальное, так и физическое, имеют два идентификатора - Major и Minor. Я не изобретал велосипед, а пошел по пути UNIX. Прежде всего, данная функция используется только модулями ядра. Называйте их как хотите - сервисы, сервера, диспетчеры протоколов и т.д. Фишка в том, что в Xameleon Major номер есть не что иное, как уникальный идентификатор потока, обслуживаеющего запросы к этому устройству. Драйвера, как блочных, так и символных устройств, для любого системного вызова всегда используют MR1 (message register) для идентификации устройства. Т.е. Minor номер. Системный вызов GetDeviceHandle возвращает Major номер устройства, который представляет из себя идентификатор программного потока, обслуживающего заросы к устройству. Аргумент этого системного вызова есть имя устройства, которое было указано при его регистрации в системном вызвове DeviceStart. К слову сказать, зарегистрированное устройство не обязвательно будет иметь одинаковое имя в devfs. Поверьте, на прикладном уровне программа даже не догадывается о формате обмена данными с устройствами, она проста использует устройства как файлы. Здесь тоже ничего не изобретено, работает принцип: все есть файл. Между прочим, драйвера стартуют параллельно. Принцип такой - запускается исполняемый модуль драйвера со стандартной точкой входа main(). Функция main() производит только одно действие - вызывает syscall DeviceStart передавая ему параметром структуру, в которой описаны все свойства драйвера - точка входа, тип драйвера, имя драйвера, количество устройств, признак работы в адресном пространстве супервизора млм в собственном и т.д. В свою очередь, Supervisor регистрирует драйвер и стартует его. Кстати, паралелльный старт драйверов приносит свои проблемы - на разном железе скорость старта некоторых драйверов индивидуальна. Поэтому драйвера верхних уровней могут стартануть раньше низкоуровневых, что приносит свои проблемы. В Xameleon эта задача решена "в лоб" - при помощи задержек в верхенуровневых драйверах. Поле для оптимизации и творчества огромное. Hmmm написал(а) ... Я ведь не знаю как будет происходить загрузка драйверов, будет ли на каждое новое устройство создаваться своя копия драйвера или только его контекст. Устройства, обслуживаемые одним драйвером различаются по номеру Minor. Hmmm написал(а) ... ProcessWait - Вы разницу между process_id и thread_id вообще делаете? Спасибо за качественный вопрос. Я буду несказанно рад ответить на него. Дело в том, что process_id есть не что иное, как POSIX pid_t. А thread_id, не что иное как L4_ThreadId_t стурктура, представляющая из себя битовое поле, описанная в L4 X2 spec. А теперь о разнице. В плане многозадачности, микроядро работает только с понятиями потоков (нитей) и адресных пространств. Я люблю его за это (и не только) Из этого слеудет, что реализация процесса ложится на плечи системного архитекотора/разработчика. Что значит процесс в терминах Xameleon - это некий набор, состоящий из одного и более программных потоков, которые находятся в одном адресном пространстве. Т.е. понятиями POSIX pid_t оперирует исключительно Supervisor и использующие его сервисы. Для микроядра L4 такого понятия не существует. Я могу бесконечно долго рассказывать об этом, но, думаю, новая версия спеков, которая на настоящий момент соответствует реализации в коде, скажет гораздо больше. В этой версии добавилось описание ещё трех протоколов - файловой системы, блочных устройств и символьных устройств. Естественно, это черновик, как в плане оформления, так и в плане содержимого. Приятно видеть людей, которые не поленились прочитать документ. p.s. Если совсем честно, то меня жаба душит его выкладывать. Радует только то, что база и шаблон отчёта остаются у меня и что описанное давно реализовано в коде. Теперь вот дилемма - править сначала спецификацию, а потом код или наоборот? <span class='smallblacktext'>[ Редактирование воскресенье 26.11.2006 02:47 ]</span> | ||
| Наверх |
| ||
| alman |
| ||
| ID пользователя #753 Зарегистрирован: Суббота 28.10.2006 01:21Местонахождение: планета Земля Сообщений: 95 | Hmmm написал(а) ... Модель не без шероховатостей. Пардон, "файл с таким именем уже существукет". Переименовал и выкладываю опять. Добавились описания сервисов файловой системы и формата обмена данными с блочными и символьными устройствами. 753_xam_protocols_draft.pdf | ||
| Наверх |
| ||
| Hmmm |
| ||
| ID пользователя #719 Зарегистрирован: Среда 09.08.2006 11:29Местонахождение: Москва Сообщений: 108 | По поводу параллельной загрузки драйверов, в Solaris 10, насколько я знаю, драйвера грузятся параллельно, но каждый драйвер может потребовать что бы его загрузка происходила только после корректного старта какого либо другого драйвера. И никаких непонятных задержек не требуется | ||
| Наверх | | ||
| Dron |
| ||
| ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Hmmm, Это медленнее... если все драйвера стартуют вместе, то те драйвера, которым нужно чего-то ждать, к нужному моменту уже все остальное проинициализируют и будут готовы. Последовательно-паралельная загрузка служб и в линуксе применяется, драйвера там правда в ядре... Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| alman |
| ||
| ID пользователя #753 Зарегистрирован: Суббота 28.10.2006 01:21Местонахождение: планета Земля Сообщений: 95 | А все-таки, кто-нить выложит свои спецификации? | ||
| Наверх |
| ||
| alman |
| ||
| ID пользователя #753 Зарегистрирован: Суббота 28.10.2006 01:21Местонахождение: планета Земля Сообщений: 95 | Уж извините, за то что так часто выкладваю. Вот новая версия протоколов. Добавлены коды возврата. Перегруппированы функции супервизора. Добавлена схема взаимеодействия протоколов. Исправлен внешний документа. Переписаны и дополнены описания многих системных вызоовов. И ещё много чего по мелочи. Как всегда, вопросы, комментарии и дополнения приветствуются. 753_xam_protocols_draft_r3.pdf | ||
| Наверх |
| ||
| Переход на страницу [1] 2 | |
Powered by e107 Forum System