Группа немецких инженеров под руководством профессора Вольфганга Фройде (Wolfgang Freude) из университета Карлсруэ
Университет Карлсруэ у меня прочно ассоциируется с микроядром L4 Pistachio. Приятно слышать, что не только микроядрами славится университет города, чьё населением около 300 тыс. человек.
Очень очень интересно. А можно с этого момента подробнее? На ассемблере, это не страшно, если документируете API.
На каком объекте планируете рисовать? (битмап, видеопамять, etc.)
Почему Kolibri OS? Вы имеете отношение к этому проекту?
И ещё вопрос по числам с плавающей запятой — используете команды математического сопроцессора? К сожалению я не знаком с архитектурой Kolibri — не вызовет ли переключение задач проблем с сопроцессором?
Можно ли рассчитывать не на динамическую библиотеку, а на объектный файл в формате elf? Желательно, чтобы без обращений к другим библиотекам.
И самый последний вопрос — под какой лицензией собираетесь распространять растеризатор?
Новое — это хорошо забытое старое. Вот здесь пруф: Tektronix 4010 — терминал, который умел рисовать графику без X-протокола. Соединялся с хостом посредством RS-232. Если моя память мне не изменяет, то в древних версиях xterm была поддержка этого терминала.
Не вдаваясь в отличия способа отображения терминала Tektronix от описанного в статье, скажу лишь что Tektronix не поддерживал мышь. Но если бы она там была, то могла выглядеть приблизительно вот так:
И только через чуть более чем 10 лет компьютерные мыши стали выглядеть вот так:
Я бы с удовольствием писал и отладочную информацию на русском, но есть «вавилонская проблема» — какую кодировку выбрать CP866, KOI8-R, CP1251 или Unicode? И не потому что патриот, а потому что на русском языке мне легче выражать свои мысли и ещё чтобы native english speakers не ужасались, глядя на документацию или выводимую отладочную информацию, в которой ошибок больше чем в коде.
Хамелеон поддерживает cp866, потому что использует русский фонт из досовской резидентной программы keyrus ныне покойного Дмитрия Гуртяк. Большинство кода я пишу в MS Viusal Studio, где кодировка CP1251, с юниксами дружу давно, поэтому на сборочной Slackware традиционно использую KOI8-R. От использования юникода сдерживает глобальноcть и масштабность перехода.
Времени делать функцию мапинга кодировок в драйваере терминала нет — это ведь придётся новый ioctl добавлять и, что самое главное, предусмотреть Unicode.
Хотя… Вы подняли интересную проблему. Возможно пора уже озаботится поддержкой юникода в Хамелеоне. Но не раньше фикса TCP/IP стека.
Самый стабильный — Супервизор. Я уже забыл когда с ним были какие либо проблемы. На втором месте по стабильности — файловая система. Проблем чтения не обнаружено, запись работает удовлетворительно, но не настолько, чтобы можно было довериь сколь-нибудь ценную информацию.
Есть ограничение на количество одновремнных обращений к файловой системе, которое жёстко задано при компиляции. Например, версия, которую использую для отладки, имеет ограничение на одновременный доступ к функциям файловой системы шести процессам или шести программным потокам одного процесса или любому сочетанию процессов или потоков, но не более шести.
Драйвера работают удовлетворительно. К сожалению, большинство драйверов на реальном железе не пробовал — только на виртуальных машинах. Подозреваю, что драйвер floppy диска может иметь проблемы с мотором.
Сетевой драйвер DEC21140 — полёт отличный. Писал его по спецификации, без подглядывания в чужой код. Интерфейс для работы с сетевыми драйверами почти закрепился.
Самая нестабильная часть системы в текущий момент — реализация TCP протокола. Уже несколько месяцев перепроектирую TCP/IP стек и когда остальные части сетевого стека заработали правильно, тут-то и «вылезли боком» все упрощения, которые допускал при реализации стека.
Кроме того, последняя переделка стека поломала сборку фрагментированых IP пакетов.
Впрочем, можете сами посмотреть: narod.ru/disk/13178174001/floppy.img.html
Только… не распространяйте его — он отладочный. Если попадёт в неправильные или неподготовленные руки, человек может получить стресс или чего даже хуже.
Чуть не забыл — мой компаньон обнаружил проблемы со своей конфигурации виртуальной машины. Я тестирую Хамелеон вот на этой конфигурации: narod.ru/disk/13179117001/Xameleon.vmc.html
Наконец, если ваш CPU вдруг стал потреблять 100% ресурсов, значит система попала во встроенный отладчик L4, который опрашивает клавиатуру в цикле, а не по прерываниям. Вопросительных знак вам покажет команды отладчика. В большинстве случаев продолжение исполнения кода возможно, потому что большинство точек останова — отладочные. Они вкомпилированы в код и позволяют продолжить исполнение. Но есть исключения, о которых в другой раз.
Igor1024, спасибо, конечно, за интерес, но если писать цикл статей, то не останется время на отладку существующего кода и написание нового.
А что Вам было бы интересно прочитать — об остальных функциях супервизора, о вызовах файловой системы или о драйверах? Ещё люди спрашивают о компиляции исполняемых файлов.
Пардон, вероятно я не очень подробно описал. Kickstart — тоже часть Pistachio, его задача — инициализировать микроядро и подготовить для него доступ к MBI.
Вот как выглядит конфигурация grub для загрузчики Хамелеона:
Vодуль init — это первая задача из user space. Аналог процесса init в Unix.
Вы кстати, наверное знакомы с проектом L4-Hurd (порт Gnu/Hurd на микроядро). Интересно ваше мнение о проекте в целом, планируете ли использовать их наработки?
Спасибо, хороший вопрос. Их наработки не планирую использовать. Мнение о проекте очень хорошее — мы начинали приблизительно в одно время, но разработчики Gnu/Hurd дали мне надежду, что всё делаю правильно. Эту историю я рассказывал много раз — много лет назад я запускал GNU/Hurd на своём стареньком ноуте Compaq Presario и после нескольких минут работы кулер процессора напоминал маленький вертолётик — ещё чуть чуть и ноутбук бы взлетел. Не знаю, что там намудрили разработчики, но в состоянии ожидания система не должна греть процессор.
Второй момент — это письмо-разочарование ведущего разработчика GNU/Hurd в списке рассылки Pistachio — для обработки системных вызовов он создавал процесс в kernel space на каждый процесс из user space, в результате получил overblow системы и нерациональное использование ресурсов. Я пошёл другим путём — создал хитрый алгоритм диспетчеризации системных вызовов на основе конечного автомата и контекста вызова. В результате Хамелеон оказался нетребовательным к ресурсам, упростился код файловой системы и во многих местах удалось отказаться от использования блокировок для защиты доступа к данным.
Это моё хобби. Всегда хотел написать операционную систему, делал несколько попыток (первая была на ассемблере), затем обычно сталкивался с проблемой, которую не мог решить из за незнания каких-то вещей и бросал. Когда узнавал что-то новое — начинал заново. Переломный момент — встреча с микроядром L4. Когда прочитал спецификацию, попробовал примеры, понял всю красоту L4 — сдерживающих факторов не было. Мне нравится писать операционную систему, разрабатывать протоколы и видеть, как система постепенно становится стабильнее и мощнее.
Насчёт практической цели — время покажет. Давайте вернёмся к этому вопросу после портирования системы на ARM.
Использую grub, поскольку его использует Pistachio. Более того — процесс начального старта модулей завязан на структуру MBI (Multi Boot Information), которая передаётся Супервизору. О своём загрузчике думаю, но пока нет смысла его писать — для архитектуры x86 grub вполне хорош, а написание своего загрузчика отнимет бесценное время, которого всегда не хватает. Как организовать загрузку на архитектуре ARM — пока вопрос не решён. Имеющиеся в моём распоряжении средства склеивают все модули в один файл для упрощения загрузки на встраиваемых системах. Похоже, для ARM придётся вместо MBI использовать другой протокол.
Кстати, ещё один аргумент в пользу grub — удалось запустить Хамелеон на тестовом хостинге компании sprinthost.ru. Это оказалось весьма просто — пришлось переписать файлы с образа загрузочной дискеты на файловую систему хостерского Debian, добавить модули в /boot/grub/menu.lst и Хамелеон запустился на VDS.
Честно говоря, не знаю, что двигало разработчиками из университета Karlsruhe.
Pistachio (фисташка) это второе микроядро от Karlsruhe, первое называлось Hazelnut (фундук). На мой взгляд, выбор орехов для названия микроядер — не такая уж и плохая идея. Чего нельзя сказать о разработчиках из Дрезденского университета — свою версию L4 они назвали Fiasco.
«А не сожрет ли GPU все сэкономленные дисплеем 40%, для обслуживания такого разрешения ?»
Мне подумалось то же самое, когда прочитал о 40% экономии. Хотя, разрешение 2560x1600 уже позволяет отказаться от сглаживания TrueType шрифтов — а это неплохой аргумент в пользу высокого разрешения.
Таки юристы топик не читаю. А можно было бы интересно обновить обсуждение: «No right to create modifications or derivates is granted by this license. » Hey pal! What is «derivates»?
Для ленивых на ARM'е есть Linux, который просто процветает. Кто посерьёзнее, те используют коммерческие realtime системы.
Не побоюсь прослыть занудой, но у меня «завалялась» раритетная дока:
«L4 eXperimental Kernel Reference Manual Version X.2
System Architecture Group Dept. of Computer Science
Universit¨at Karlsruhe
(L4Ka Team)
l4spec@l4ka.org
Document Revision 5
June 4, 2004»
У этой документации вот такая лицензия:
Copyright c
2001–2004 by System Architecture Group, Department of Computer Science, Universit¨at Karlsruhe.
THIS SPECIFICATION IS PROVIDED “AS IS” WITHOUT ANY WARRANTIES, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT,
FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OF ANY PROPOSAL, SPECIFICATION
OR SAMPLE.
Permission to copy and distribute verbatim copies of this specification in any medium for any purpose without fee or royalty is hereby granted. No right to create modifications or derivates is granted by this license. The L4Ka Team may make changes to this specification at any time, without notice. The latest
revision of this document is available at l4ka.org/.
Осталось пригласить юристов и лингвистов, чтобы истолковать derivates — относятся ли они только к самой документации или запрещают писать реализацию. Изучить прецеденты и…
^^ по этой ссылке находится старая спецификация, которая в совместима с последующими ревизиями, но из неё ещё не убрана поддержка «ARM Interface».
Вот и думай, то ли платить за NICTA::L4-embedded, который который имеет десяток надстроек над красивым протоколом L4-x2, или сесть за учебники и выучить внутренности архитектуры ARM. Я то уже стар для таких подвигов — мне хватает С/С++ и воспоминаний о x86, но может авантюристы-любители ещё не перевелись? Разумеется, всё это имеет смысл, если понятие derivates из вышеприведённой лицензии не относится к реализации.
amdf, у Вас уже несколько статей по внутренностям NTFS.
А вот представьте, я делаю небольшой раздел, например, 100 Мб. Затем форматирую его в NTFS, создаю на нём несколько директорий, пишу несколько файлов разного размера, играюсь с правами на файлы. Затем перегружаюсь в Linux и копирую командой dd весь NTFS раздел в файл. Затем образ NTFS раздела переношу в Windows, запускаю MS Viusal Studio С++, делаю mapping NTFS образа в память и…
Собственно говоря, мне нужно реализовать следующие функции: open, read, write, close, lseek, chdir, opendir, readdir, closedir, mkdir, remove, rmdir.
Иными словами, есть непреодолимое желание поработать с образом NTFS напрямую, без использования операционной системы.
Вопросы: Насколько реально? С чего начать? Где взять документацию на NTFS?
p.s. Использовать реализацию NTFS из ядра Linux по некоторым соображениям невозможно.
Так держать!
Университет Карлсруэ у меня прочно ассоциируется с микроядром L4 Pistachio. Приятно слышать, что не только микроядрами славится университет города, чьё населением около 300 тыс. человек.
На каком объекте планируете рисовать? (битмап, видеопамять, etc.)
Почему Kolibri OS? Вы имеете отношение к этому проекту?
И ещё вопрос по числам с плавающей запятой — используете команды математического сопроцессора? К сожалению я не знаком с архитектурой Kolibri — не вызовет ли переключение задач проблем с сопроцессором?
Можно ли рассчитывать не на динамическую библиотеку, а на объектный файл в формате elf? Желательно, чтобы без обращений к другим библиотекам.
И самый последний вопрос — под какой лицензией собираетесь распространять растеризатор?
И да, слишком много «святости» в этой теме. Кажется здесь кого-то не хватает
Не вдаваясь в отличия способа отображения терминала Tektronix от описанного в статье, скажу лишь что Tektronix не поддерживал мышь. Но если бы она там была, то могла выглядеть приблизительно вот так:
И только через чуть более чем 10 лет компьютерные мыши стали выглядеть вот так:
Хамелеон поддерживает cp866, потому что использует русский фонт из досовской резидентной программы keyrus ныне покойного Дмитрия Гуртяк. Большинство кода я пишу в MS Viusal Studio, где кодировка CP1251, с юниксами дружу давно, поэтому на сборочной Slackware традиционно использую KOI8-R. От использования юникода сдерживает глобальноcть и масштабность перехода.
Времени делать функцию мапинга кодировок в драйваере терминала нет — это ведь придётся новый ioctl добавлять и, что самое главное, предусмотреть Unicode.
Хотя… Вы подняли интересную проблему. Возможно пора уже озаботится поддержкой юникода в Хамелеоне. Но не раньше фикса TCP/IP стека.
Есть ограничение на количество одновремнных обращений к файловой системе, которое жёстко задано при компиляции. Например, версия, которую использую для отладки, имеет ограничение на одновременный доступ к функциям файловой системы шести процессам или шести программным потокам одного процесса или любому сочетанию процессов или потоков, но не более шести.
Драйвера работают удовлетворительно. К сожалению, большинство драйверов на реальном железе не пробовал — только на виртуальных машинах. Подозреваю, что драйвер floppy диска может иметь проблемы с мотором.
Сетевой драйвер DEC21140 — полёт отличный. Писал его по спецификации, без подглядывания в чужой код. Интерфейс для работы с сетевыми драйверами почти закрепился.
Самая нестабильная часть системы в текущий момент — реализация TCP протокола. Уже несколько месяцев перепроектирую TCP/IP стек и когда остальные части сетевого стека заработали правильно, тут-то и «вылезли боком» все упрощения, которые допускал при реализации стека.
Кроме того, последняя переделка стека поломала сборку фрагментированых IP пакетов.
Впрочем, можете сами посмотреть: narod.ru/disk/13178174001/floppy.img.html
Только… не распространяйте его — он отладочный. Если попадёт в неправильные или неподготовленные руки, человек может получить стресс или чего даже хуже.
Чуть не забыл — мой компаньон обнаружил проблемы со своей конфигурации виртуальной машины. Я тестирую Хамелеон вот на этой конфигурации: narod.ru/disk/13179117001/Xameleon.vmc.html
Наконец, если ваш CPU вдруг стал потреблять 100% ресурсов, значит система попала во встроенный отладчик L4, который опрашивает клавиатуру в цикле, а не по прерываниям. Вопросительных знак вам покажет команды отладчика. В большинстве случаев продолжение исполнения кода возможно, потому что большинство точек останова — отладочные. Они вкомпилированы в код и позволяют продолжить исполнение. Но есть исключения, о которых в другой раз.
А что Вам было бы интересно прочитать — об остальных функциях супервизора, о вызовах файловой системы или о драйверах? Ещё люди спрашивают о компиляции исполняемых файлов.
Пардон, вероятно я не очень подробно описал. 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.
Спасибо, хороший вопрос. Их наработки не планирую использовать. Мнение о проекте очень хорошее — мы начинали приблизительно в одно время, но разработчики Gnu/Hurd дали мне надежду, что всё делаю правильно. Эту историю я рассказывал много раз — много лет назад я запускал GNU/Hurd на своём стареньком ноуте Compaq Presario и после нескольких минут работы кулер процессора напоминал маленький вертолётик — ещё чуть чуть и ноутбук бы взлетел. Не знаю, что там намудрили разработчики, но в состоянии ожидания система не должна греть процессор.
Второй момент — это письмо-разочарование ведущего разработчика GNU/Hurd в списке рассылки Pistachio — для обработки системных вызовов он создавал процесс в kernel space на каждый процесс из user space, в результате получил overblow системы и нерациональное использование ресурсов. Я пошёл другим путём — создал хитрый алгоритм диспетчеризации системных вызовов на основе конечного автомата и контекста вызова. В результате Хамелеон оказался нетребовательным к ресурсам, упростился код файловой системы и во многих местах удалось отказаться от использования блокировок для защиты доступа к данным.
Насчёт практической цели — время покажет. Давайте вернёмся к этому вопросу после портирования системы на ARM.
Кстати, ещё один аргумент в пользу grub — удалось запустить Хамелеон на тестовом хостинге компании sprinthost.ru. Это оказалось весьма просто — пришлось переписать файлы с образа загрузочной дискеты на файловую систему хостерского Debian, добавить модули в /boot/grub/menu.lst и Хамелеон запустился на VDS.
Pistachio (фисташка) это второе микроядро от Karlsruhe, первое называлось Hazelnut (фундук). На мой взгляд, выбор орехов для названия микроядер — не такая уж и плохая идея. Чего нельзя сказать о разработчиках из Дрезденского университета — свою версию L4 они назвали Fiasco.
Мне подумалось то же самое, когда прочитал о 40% экономии. Хотя, разрешение 2560x1600 уже позволяет отказаться от сглаживания TrueType шрифтов — а это неплохой аргумент в пользу высокого разрешения.
Спасибо. Первый раз вижу подобную информацию на русском языке.
Не побоюсь прослыть занудой, но у меня «завалялась» раритетная дока:
«L4 eXperimental Kernel Reference Manual Version X.2
System Architecture Group Dept. of Computer Science
Universit¨at Karlsruhe
(L4Ka Team)
l4spec@l4ka.org
Document Revision 5
June 4, 2004»
У этой документации вот такая лицензия:
Copyright c
2001–2004 by System Architecture Group, Department of Computer Science, Universit¨at Karlsruhe.
THIS SPECIFICATION IS PROVIDED “AS IS” WITHOUT ANY WARRANTIES, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT,
FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OF ANY PROPOSAL, SPECIFICATION
OR SAMPLE.
Permission to copy and distribute verbatim copies of this specification in any medium for any purpose without fee or royalty is hereby granted. No right to create modifications or derivates is granted by this license. The L4Ka Team may make changes to this specification at any time, without notice. The latest
revision of this document is available at l4ka.org/.
Осталось пригласить юристов и лингвистов, чтобы истолковать derivates — относятся ли они только к самой документации или запрещают писать реализацию. Изучить прецеденты и…
narod.ru/disk/12675982001/l4-x2.pdf.html
^^ по этой ссылке находится старая спецификация, которая в совместима с последующими ревизиями, но из неё ещё не убрана поддержка «ARM Interface».
Вот и думай, то ли платить за NICTA::L4-embedded, который который имеет десяток надстроек над красивым протоколом L4-x2, или сесть за учебники и выучить внутренности архитектуры ARM. Я то уже стар для таких подвигов — мне хватает С/С++ и воспоминаний о x86, но может авантюристы-любители ещё не перевелись? Разумеется, всё это имеет смысл, если понятие derivates из вышеприведённой лицензии не относится к реализации.
А вот представьте, я делаю небольшой раздел, например, 100 Мб. Затем форматирую его в NTFS, создаю на нём несколько директорий, пишу несколько файлов разного размера, играюсь с правами на файлы. Затем перегружаюсь в Linux и копирую командой dd весь NTFS раздел в файл. Затем образ NTFS раздела переношу в Windows, запускаю MS Viusal Studio С++, делаю mapping NTFS образа в память и…
Собственно говоря, мне нужно реализовать следующие функции: open, read, write, close, lseek, chdir, opendir, readdir, closedir, mkdir, remove, rmdir.
Иными словами, есть непреодолимое желание поработать с образом NTFS напрямую, без использования операционной системы.
Вопросы: Насколько реально? С чего начать? Где взять документацию на NTFS?
p.s. Использовать реализацию NTFS из ядра Linux по некоторым соображениям невозможно.