Дискуссия Таненбаума и Торвальдса: часть II

Танненбаум - профессор. Выращивает в вакууме сферических коней. Труды его занятны. Расширяют кругозор. Его споры с Торвальдсом по поводу теоретических преимуществ несколько неуместны и неадекватны. У НЕГО НЕТ СВОЕГО МИКРОЯДРА, столь же распространенного как ядро его бывшего студента. Такто вот.

>На сайте Minix3 я не нашел результатов бенчмарок - это неспроста :(
а я нашел, в конце:
http://www.minix3.ru/articles/reliable-os.html 5..20% по сравнению с Minix 2 (я так понял- там то-же количество тех-же вызовов, но внутри ядра)


(вообще самый ценный разделы на сайте, http://www.minix3.ru/articles.html и http://www.minix3.ru/kernel.html - фиг найдешь)

> я нашел, в конце:

>http://www.minix3.ru/articles/reliable-os.html 5..20% по сравнению с Minix 2

Я нашел примерно то же в pdf'ах статей на minix3.org, но это не то, что нужно. "то сравнение с самими собой - кому, кроме них, это интересно? Сравните с Linux, FreeBSD, да хоть с Виндой. Сравните не время системного вызова, а реальную пропускную способность при работе с сетью и ФС.

>Чтобы всему софту было фиолетово - линуксовое это ядро или миникс-ядро.

Бросив взгляд на мир персональных компьютеров, мы обнаружим там L4Linux, который был написан группой Германа Хартига (Hermann Härtig) в Техническом Университете Дрездена. Она запускает весь Linux в пространстве пользователя поверх микроядра L4 с потерей всего лишь пары процентов производительности. Но использование микроядра позволило людям из Технического Университета Дрездена построить новые системы, такие, как DROPS (система реального времени) и NIZZA (безопасность) поверх L4, при этом имея доступ ко всей функциональности Linux без его модификации для обеспечения этих новых возможностей. Таким способом они могут экспериментировать с новыми возможностями и по прежнему могут запускать уже существующие программы. Для исследований в области операционных систем микроядро L4 используют и другие группы, такие, как Wombat, паравиртуализованный Linux, спроектированный для поддержки существующих приложений во встроенных системах. Ещё одной ОС на базе L4 является TUD-OS и так далее.

???

>Диспетчер памяти ничего не поймет. В DMA даже адреса не те, с которыми диспетчер памяти работает.

взаимодействие с DMA можно выделить в отдельный сервис вообще-то.

>>Диспетчер памяти ничего не поймет. В DMA даже адреса не те, с которыми диспетчер памяти работает.

>взаимодействие с DMA можно выделить в отдельный сервис вообще-то.

:-D Чисто теоретически - конечно, создать язык описания команд на устройство, и писать драйвер на этом языке. Но это ничего не даст, и проще дождаться повсеместного появления IOMMU. Тем более что DMA - это не единственная проблема.

>:-D Чисто теоретически - конечно, создать язык описания команд на устройство, и писать драйвер на этом языке. Но это ничего не даст, и проще дождаться повсеместного появления IOMMU. Тем более что DMA - это не единственная проблема.

зачем команд? отдельный DMA-сервис. Которому говорить куда и сколько. Тем более что перед DMA-передачей контроллер DMA по-любому надо иницииализировать соответствующим образом. И перед тем как что-то писать в память контроллер DMA дергает цпу чтобы сказать - "ура, есть данные". Если я всё правильно помню конечно. В чем проблема-то - вынести управление DMA из драйвера устройства?

я вот сижу на работе и думаю какое микроядро спасет от мого сервисного случая - когда машина определила что у нее оишбки при передаче по шине и автоматом ребутнула себя и тепреь надо соответсвующие поменять (IB и RP). наврдя ли от этого можно обособиться микроядром - а тогда нафига весь базар?

> я вот сижу на работе и думаю какое микроядро спасет от мого сервисного случая

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

> В чем проблема-то - вынести управление DMA из драйвера устройства?

В том, что для разных устройств DMA настраивается и запускается (очень) по-разному. Поэтому нельзя написать "сервер DMA", который работает с любым устройством. Самое рабочее из предложенных решений - слой в ядре, который декодирует передаваемые в порты данные, находит в них команды DMA и проверяет их на корректность. Это 1) не реализовано в Minix3 2) подразумевает какой-то язык описания команд устройства 3) просто переносит источник багов из кода на Си в код на языке описания команд 4) пока это реализуют, в каждом компе будет IOMMU.

А твое понятие о DMA остановилось на времена ISA и DOS ;)

>В том, что для разных устройств DMA настраивается и запускается (очень) по-разному.

так в любом случае _кроме_ девайса нужно ещё контроллер DMA нужно настраивать. Или pci-девайсы уже научились плевать на это? :)

>Самое рабочее из предложенных решений - слой в ядре, который декодирует передаваемые в порты данные, находит в них команды DMA и проверяет их на корректность.

ну это эмуляция IOMMU :) Тоже вариант, кстати

>А твое понятие о DMA остановилось на времена ISA и DOS ;)

можно подумать с тех времен что-то кардинально поменялось.

> так в любом случае _кроме_ девайса нужно ещё контроллер DMA нужно настраивать.

Теперь настройка DMA - это _часть_ настройки девайса, неотделимая и не стандартизированная никак.

> ну это эмуляция IOMMU :)

Так точно.

>>А твое понятие о DMA остановилось на времена ISA и DOS ;)

>можно подумать с тех времен что-то кардинально поменялось.

Больше нет унифицированного интерфейса к контроллеру DMA.

>Больше нет унифицированного интерфейса к контроллеру DMA.

гм.гм. т.е. регистры "сюда/отсюда" и "N литров" теперь неизвесно где?

> т.е. регистры "сюда/отсюда" и "N литров" теперь неизвесно где?

Да. А еще есть массивы дескрипторов для scatter-gather вывода - специфичные для устроства :)

Кроме того - DMA не единственная проблема.

>Да. А еще есть массивы дескрипторов для scatter-gather вывода - специфичные для устроства :)

докачаю minix - посмотрю, как там сделано

беглый просмотр сырцов линукса ничего, чтобы нельзя было вынести из драйвера не показал

>Кроме того - DMA не единственная проблема.

какие ещё?

> беглый просмотр сырцов линукса ничего, чтобы нельзя было вынести из драйвера не показал

Конечно. Вынести можно всё - вопрос в том, что именно даст и к каким проблемам приведет (помимо падения производительности).

>>Кроме того - DMA не единственная проблема.

>какие ещё?

У ошибок в драйверах есть много способов убить систему (на современных шинных архитектурах). Например, можно загнать устройство в такой режим, что оно займет шину и не слезет с нее, или выбьет _другие_ устройства (не знаю, защищает ли IOMMU устройства). Ошибка в обработчике прерывания, при которой прерывание остается активным на устройстве: получим screaming interrupt и livelock - формально система жива, но ни на что не реагирует.

Кроме того, в Minix3 пока что нет виртуальной памтяи и подкачки с диска. Очень интересно посмотреть, как они будут решать проблему, когда драйвер отчасти в свопе, висит на одном IRQ с диском, и возникает прерывание. Скорее всего, им придется лочить драйверы в памяти и запрещать им пользоваться mmap, но тогда получится, что драйвер - это не совсем "обычный пользовательский процесс". В любом случае, interrupt latency у них должна доставать до неба.

по какому нафиг системнику? в машине только PCI Корзинок 2 а System Board весит ~7Кг и подозреваю что ей особенно ничего не будет от кувалды -там металл хороший.:-) к тому же это не моей работе, а у клиента.;\( я просто думаю что теоритически можно было драйвера в x86 загнать на уровень 1, а не 0. возмонжо это что-то бы и дало. Но Таненбаум - он просто изобретатель сферических коней в вакууме.

> в машине только PCI Корзинок 2 а System Board весит ~7Кг и подозреваю что ей особенно ничего не будет от кувалды -там металл хороший.:-)

Значит, гвозить кувалдой, пока система не зависнет :)

> я просто думаю что теоритически можно было драйвера в x86 загнать на уровень 1, а не 0. возмонжо это что-то бы и дало.

Анонимный брат, ты настоящий LOR'овец и не ходишь по ссылкам :) В Minix3 драйверы работают в уровне 3.

> Таненбаум - он просто изобретатель сферических коней в вакууме.

Он больше теоретик, чем практик. Но у него появился шанс исправиться :)

не - просто кроме лора и баша - больше некуда не пускает...:)

не - ну и к вендору на сайт конечно.:)

не - уровень 3 не подйёт - на этом уровен рядовые проги работают - нужно именно 1.

> не - уровень 3 не подйёт - на этом уровен рядовые проги работают

А что такого необходимого можно делать на уровне 1, но нельзя- на уровне 3? Или некрута благородным драйверам работать на одном уровне с сиволапыми апликухами? :D

если вы не в курсе - то поясню -проблематично на x86 развести по правам программы на 1 уровен от доступа к IO портам.
кроме того - там есть тонкости с приоритизацией, DT и т.д.

> если вы не в курсе

Я темный и малограмотный codemonkey :(

> проблематично на x86 развести по правам программы на 1 уровен от доступа к IO портам

Если моя память мне ни с кем не изменияе, то IOPL действует и на программы в Ring 3, но это не важно, мотому что в Minix3 драйверы напрямую к портам не обращаются.

> есть тонкости с приоритизацией, DT и т.д.

Приоритизацией чего? А что такое DT - не просветите?

>если вы не в курсе - то поясню -проблематично на x86 развести по правам программы на 1 уровен от доступа к IO портам.

да нет никаких проблем. Каждой задаче - своя карта IO

>Нам предлагаешь нахаляву доработать до того уровня пока им не станет надо ?

По твоему наступит такой момент когда нибудь? Они вон свою сингуларити на коленке за сколько написали? В ресерче у них сидят умные мужики - просто такой радиколизм не нужен компании. У них проблемы рыночного плана, а не технического.

>это не мешает им делать отстойные продукты.

Проблемы общего управления тут перпендикулярны.

>код, который под BSD лицензией, действительно крайне трудно украсть, я бы не смог.

Никто бы не смог. Это миф.