Как стать автором
Обновить

Комментарии 35

аналогично. Черт побери — хабр торт.

Сейчас внимательно изучу и отпишу толково, пока так — чисто эмоции
У вас смешаны в одну кучу типы size_t, ssize_t, ptrdiff_t, unsigned int для битовых полей, какой-нибудь handle_t для хендлов и просто int для статусов. В языке Си они разделены не просто так. Например, потому что одни — беззнаковые, другие со знаком. Ну и размер конечно же (хотя вы можте сказать пусть будет «всё по-максимуму» ILP64).
Занимательно. Я сейчас сам бьюсь над тем, как у себя лучше реализовать механику, хотя ссылку на спецификацию ядра вы уже давали. Хочется по-новой изобрести велосипед.
хм… действительно много картинок.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
SUSE от зависти стал похож на гомосексуальный флаг.
Почему микроядро называется именно Pistachio?
Честно говоря, не знаю, что двигало разработчиками из университета Karlsruhe.
Pistachio (фисташка) это второе микроядро от Karlsruhe, первое называлось Hazelnut (фундук). На мой взгляд, выбор орехов для названия микроядер — не такая уж и плохая идея. Чего нельзя сказать о разработчиках из Дрезденского университета — свою версию L4 они назвали Fiasco.
А кстати, что планируете в качестве загрузчика использовать? Kikstart, Grub или что-то иное (мб вообще свой)?
Использую grub, поскольку его использует Pistachio. Более того — процесс начального старта модулей завязан на структуру MBI (Multi Boot Information), которая передаётся Супервизору. О своём загрузчике думаю, но пока нет смысла его писать — для архитектуры x86 grub вполне хорош, а написание своего загрузчика отнимет бесценное время, которого всегда не хватает. Как организовать загрузку на архитектуре ARM — пока вопрос не решён. Имеющиеся в моём распоряжении средства склеивают все модули в один файл для упрощения загрузки на встраиваемых системах. Похоже, для ARM придётся вместо MBI использовать другой протокол.

Кстати, ещё один аргумент в пользу grub — удалось запустить Хамелеон на тестовом хостинге компании sprinthost.ru. Это оказалось весьма просто — пришлось переписать файлы с образа загрузочной дискеты на файловую систему хостерского Debian, добавить модули в /boot/grub/menu.lst и Хамелеон запустился на VDS.
а это?
www.l4ka.org/95.php

Вы кстати, наверное знакомы с проектом L4-Hurd (порт Gnu/Hurd на микроядро). Интересно ваше мнение о проекте в целом, планируете ли использовать их наработки?
а это?
www.l4ka.org/95.php


Пардон, вероятно я не очень подробно описал. Kickstart — тоже часть Pistachio, его задача — инициализировать микроядро и подготовить для него доступ к MBI.

Вот как выглядит конфигурация grub для загрузчики Хамелеона:

title = Xameleon on L4Ka::Pistachio/ia32
kernel=/boot/kickstart.gz bootinfo=on mbi=on decode-all=on
module=/boot/ia32-kernel.gz
module=/boot/sigma0.gz
module=/Supervisor
module=/tty.drv.gz
module=/rs232.drv
module=/floppy.drv
module=/ramdisk.drv.gz
module=/ide.drv
module=/FileSystem.drv
module=/network.drv
module=/lan/dec21140.drv
module=/init _initrd_


Vодуль init — это первая задача из user space. Аналог процесса init в Unix.

Вы кстати, наверное знакомы с проектом L4-Hurd (порт Gnu/Hurd на микроядро). Интересно ваше мнение о проекте в целом, планируете ли использовать их наработки?

Спасибо, хороший вопрос. Их наработки не планирую использовать. Мнение о проекте очень хорошее — мы начинали приблизительно в одно время, но разработчики Gnu/Hurd дали мне надежду, что всё делаю правильно. Эту историю я рассказывал много раз — много лет назад я запускал GNU/Hurd на своём стареньком ноуте Compaq Presario и после нескольких минут работы кулер процессора напоминал маленький вертолётик — ещё чуть чуть и ноутбук бы взлетел. Не знаю, что там намудрили разработчики, но в состоянии ожидания система не должна греть процессор.

Второй момент — это письмо-разочарование ведущего разработчика GNU/Hurd в списке рассылки Pistachio — для обработки системных вызовов он создавал процесс в kernel space на каждый процесс из user space, в результате получил overblow системы и нерациональное использование ресурсов. Я пошёл другим путём — создал хитрый алгоритм диспетчеризации системных вызовов на основе конечного автомата и контекста вызова. В результате Хамелеон оказался нетребовательным к ресурсам, упростился код файловой системы и во многих местах удалось отказаться от использования блокировок для защиты доступа к данным.
Упс. Я погорячился. Разумеется, речь идёт не о GNU/Hurd, а об L4-Hurd. Прошу прощения.
Интересно последить за вашим проектом. Может стоит создать блог или рассылку? А еще лучше почаще публиковать на хабре — я думаю интересно будет многим, к тому же за мироядрами будущее — тема актуальная весьма. Очень даже может быть что вашими наработками заинтересуются представители бизнеса — тогда это может стать больше чем хобби )

В плане сферы применения — до десктопов тут конечно очень далеко (чисто мое субъективное мнение)… А вот если копнуть в сторону всяческих телевизоров-холодильников-станков плазменной резки…
НЛО прилетело и опубликовало эту надпись здесь
Это моё хобби. Всегда хотел написать операционную систему, делал несколько попыток (первая была на ассемблере), затем обычно сталкивался с проблемой, которую не мог решить из за незнания каких-то вещей и бросал. Когда узнавал что-то новое — начинал заново. Переломный момент — встреча с микроядром L4. Когда прочитал спецификацию, попробовал примеры, понял всю красоту L4 — сдерживающих факторов не было. Мне нравится писать операционную систему, разрабатывать протоколы и видеть, как система постепенно становится стабильнее и мощнее.

Насчёт практической цели — время покажет. Давайте вернёмся к этому вопросу после портирования системы на ARM.
>Сперва она была на ломаном английском, но в какой-то момент было решено не позориться и переписать на чуть более лучший русский.

Как знакомо :)
Эх… Половину руководства надо вразумить если проект делается в России и плаируют его обслуживать и использовать в России надо писать на Русском. А еще лучше всегда писать на русском — тогда еще и на поддержке можно подзаработать…
Не только руководство, но и рядовых исполнителей тоже. Ладно, если на хорошем английском, а если на другом «диалекте руглиша» :(

На хабре очень часто встречаю мнение, что комменты на русском допустимы разве что в коде 1C, и то лучше использовать английский синтаксис их языка и комментировать на английском, а документацию можно перевести на русский, но изначально она должна быть на английском, а на русском так, для «неучей и лентяев».
> допустимы разве что в коде 1C
Если надо будет слить бухгалтерию потенциальном врагу, то да!!!

> а на русском так, для «неучей и лентяев».
А на ломанном английском для того что бы потом этот код продать иностранную контору.

P.S. Лучше бы программировали с использованием шаблонов проектирования.
Шаблоны предметную область не объяснят. С шаблонами видно как работает метод/функция, но не видно что она собственно делает в терминах задачи. «Совершенное» именование классов/методов/переменных, «семантический» рефакторинг и т. п. отчасти решает эту проблему, но не всегда полностью.
Я бы с удовольствием писал и отладочную информацию на русском, но есть «вавилонская проблема» — какую кодировку выбрать CP866, KOI8-R, CP1251 или Unicode? И не потому что патриот, а потому что на русском языке мне легче выражать свои мысли и ещё чтобы native english speakers не ужасались, глядя на документацию или выводимую отладочную информацию, в которой ошибок больше чем в коде.

Хамелеон поддерживает cp866, потому что использует русский фонт из досовской резидентной программы keyrus ныне покойного Дмитрия Гуртяк. Большинство кода я пишу в MS Viusal Studio, где кодировка CP1251, с юниксами дружу давно, поэтому на сборочной Slackware традиционно использую KOI8-R. От использования юникода сдерживает глобальноcть и масштабность перехода.
Времени делать функцию мапинга кодировок в драйваере терминала нет — это ведь придётся новый ioctl добавлять и, что самое главное, предусмотреть Unicode.

Хотя… Вы подняли интересную проблему. Возможно пора уже озаботится поддержкой юникода в Хамелеоне. Но не раньше фикса TCP/IP стека.
«Писдачио микроядро Л4», годное название.

Но… А где новизна? Ну кроме морального удовлетворения от «сейчас мы сядем и все перепишем с нуля»
Мощно. Побежал ставить.
и как на данный момент со стабильностью?
Самый стабильный — Супервизор. Я уже забыл когда с ним были какие либо проблемы. На втором месте по стабильности — файловая система. Проблем чтения не обнаружено, запись работает удовлетворительно, но не настолько, чтобы можно было довериь сколь-нибудь ценную информацию.

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

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

Сетевой драйвер DEC21140 — полёт отличный. Писал его по спецификации, без подглядывания в чужой код. Интерфейс для работы с сетевыми драйверами почти закрепился.

Самая нестабильная часть системы в текущий момент — реализация TCP протокола. Уже несколько месяцев перепроектирую TCP/IP стек и когда остальные части сетевого стека заработали правильно, тут-то и «вылезли боком» все упрощения, которые допускал при реализации стека.

Кроме того, последняя переделка стека поломала сборку фрагментированых IP пакетов.

Впрочем, можете сами посмотреть: narod.ru/disk/13178174001/floppy.img.html
Только… не распространяйте его — он отладочный. Если попадёт в неправильные или неподготовленные руки, человек может получить стресс или чего даже хуже.

Чуть не забыл — мой компаньон обнаружил проблемы со своей конфигурации виртуальной машины. Я тестирую Хамелеон вот на этой конфигурации: narod.ru/disk/13179117001/Xameleon.vmc.html

Наконец, если ваш CPU вдруг стал потреблять 100% ресурсов, значит система попала во встроенный отладчик L4, который опрашивает клавиатуру в цикле, а не по прерываниям. Вопросительных знак вам покажет команды отладчика. В большинстве случаев продолжение исполнения кода возможно, потому что большинство точек останова — отладочные. Они вкомпилированы в код и позволяют продолжить исполнение. Но есть исключения, о которых в другой раз.
интересно, в ближайшее время посмотрю, и если что найду отпишусь
alman, Вы будете цикл писать? Просто пока будет некоторый перерыв в статьях про осьдев (у всех экзамены и.т.д), и неплохо было бы его заполнить.
Igor1024, спасибо, конечно, за интерес, но если писать цикл статей, то не останется время на отладку существующего кода и написание нового.

А что Вам было бы интересно прочитать — об остальных функциях супервизора, о вызовах файловой системы или о драйверах? Ещё люди спрашивают о компиляции исполняемых файлов.

О драйверах и файловой системе.
Добрый день, а можно поподробнее про KIP как базовый термин L4? Ещё интересно было бы узнать про таблицу селекторов таска в L4
Спасибо, за то что сподвигли меня на написание следующей статьи: habrahabr.ru/blogs/system_programming/122216/
В ней я ответил на некоторые Ваши вопросы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории