Board.KolibriOS.org

В пользу микроядра - широкая возможность по масштабированию системы. Конечно можно добиться подобного эффекта за счет модульного монолита, но микроядро под это изначально предназначено.
А насчет L4 - опять же тащить чужое, ну чего тогда сразу не делать дистрибутив Линукса или BSD?

bw

L4 вещь которую надо знать, но построить на нём систему очень непросто. Я искал любительские системы на ядре L4 и результат неутешительный. Обычно всё сводится к запуску Линукс. Ещё есть попытка сделать клон OS/2 на ядре L4 ( OSFree). Ничего самобытного на L4 не нашлось. Хотелось бы иметь ядро более дружелюбное к разработчикам.

Почему микроядро.
1. Хорошо проработанное микроядро защищено от обрастания всякими ненужными фичами.
Монолит будет разбухать как бы этому все не противились. За примером далеко ходить не надо - http://www.kernel.org Начиная с 2.6.31 туда запихнули DRI2/DRM/TTM под общим названием kms (kernel modesetting). Было обсуждение. Один разработчик с X.org комментировал ситуацию так: "Microsoft переносит драйверы из ядра в user-mode а мы всё тянем в ядро". Торвальдс противился и упирался как мог, назвал одну из версий кода "куском дерьма" и отказался вносить в git. Теперь улучшенная версия этого кода будет во всех Убунтах. Завтра в ядро запихнут mesa или gallium потому что это сделает 3D быстрее на 1%.

2. Масштабируемость, о чём сказал Марат.

3. Система на микроядре требует более тщательной проработки программных интерфейсов что положительно сказывается на работе системы. Ядро задаёт простые и одинаковые для всех правила работы. Меньше шансов на то что кто-то из разработчиков "срежет угол" и вместо "как правильно" сделает "как проще". Хотя бы на уровне ядра.

4. В работе микроядра проще разобраться.

> ну чего тогда сразу не делать дистрибутив Линукса или BSD?
Честно, не знаю :-). Я бы с интересом попилил ядро Linux, ведь не обязательно делать очередной дистрибутив Linux при использовании ядра Linux. Зато сколько проблем с железом решится.

> L4 - опять же тащить чужое
Не аргумент. Чужого там минимум. Возвращаясь к нашим баранам (POSIX :-), в KOS никто пока не предпринимал попыток написать "свою libc", все использовали существующий код, а ЕМНИС он куда как больше ядра Pistachio. Т.е. либо фанатично заявляем всё своё, либо давайте уж заимствовать (я переписывать FFmpeg не стану, так и знайте ;-). Без чужого никак, это наши реалии.

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

1. Как я понял связан с 3.

2. Марат там еще дополнил :-).

4. Про это мне, увы, ничего не известно.

..bw

Здесь вообще кто-нибудь читает чужие посты?

Я по-моему подробно изложил, как именно предоставляется такой сервис в любом "приличном" ядре. Если бы мне нравилось как это наворочено в Линуксе, я бы не пришел в Колибри.

Уж кто-кто, но Вы-то должны почувствовать разницу между опросом состояния семафора через аппаратное прерывание (несколько тысяч процессорных тактов, плюс минимум два переключения задачи, плюс инвалидация кеша) и его прямым чтением в решиме захвата шины (6-10 тактов PCI или 2 "маленьких" пакета PCIe, совершенно прозрачно для текущей задачи CPU)

_________________
Евангелие от Иоанна: стих 1

Code:

; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os

art_zh

Видимо мне не приходилось иметь дело с этими "приличными" ядрами. Конечно это кошмарная ситуация. О каких системах идёт речь ?

Линукс и все остальное. И аппаратные семафоры - это ерунда.
Вот навскидку цитата из "Linux Device Drivers", ch.15 "Memory mapping and DMA"

1. The hardware rises an interrupt to announce that new data has arrived
2. The interrupt handler allocates a buffer and tells the hardware where to transfer its data
3. The peripheral device writes the data to the buffer and raises another interrupt when it's done
4. The handler dispatches the new data, wakes any relevant process, and takes care on housekeeping

Здесь описана стандартная последовательность ПДП по инициативе устройства.
В Колибри от нее остается один только 3-й шаг, и то в ряде случаев можно обойтись без конечного прерывания

_________________
Евангелие от Иоанна: стих 1

Code:

; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os

art_zh

А можно подробнее описать ситуацию ? Похожую схему с записью указателей в системную память использует командный процессор GPU Radeon. Но там все работает без шаманства. Можно в личку. Очень интересно.

Или это проблемы в user-mode ?

art_zh

Ну там описано гипотетическое устройство. Может некоторые сетевые карты действительно два раза дёргают ядро чтобы выполнить ДМА, но это скорее проблема железа. Такая карта и в Колибри будет работать не лучше.
Для сравнения командный процессор Rage128 - Radeon : кольцевой буфер в системной памяти размером до 2 Мб. Два регистра устройства определяют положение указателей чтения и записи. У драйвера свои копии. Равенство регистров означает что буфер пуст.
Драйвер пишет в буфер команды в специальном формате и записывает новый адрес указателя записи в регистр. Командный процессор читает данные и обновляет свой указатель чтения после чего переписывает укзатель драйвера в системной памяти. Для этого при инициализации драйвер записывает в гпу физический адрес своего указателя. Всё сделано для того чтобы минимизировать обращения драйвера к устройству, особенно чтение регистров. Самые необходимые регистры гпу пишет в системную память сам. И нет никаких ненужных прерываний.

P.S. К сожалению такие книжки часто пишут люди плохо разбырающиеся в вопросе. Даже в Intel® Architecture
Software Developer’s Manual приводится такой обработчик fpu
1. сохраняем текущий контекст фпу
2. загружаем новый контекст
3. clts

Алгоритм пережил массу переизданий и правок.

В моем случае есть устройство (CMOS-камера. самодельная, но очень шустрая), которое получает, группирует и подготавливает к вводу большие блоки информации. Одна видеолиния (1280 пикселей, 10 бит на пиксель) оцифровывается за 2 микросекунды . Пятьсот XGA-кадров в секунду!
Видеограббер собран на мощном FPGA-модуле и поддерживает протокол PCI express x4 с теоретической пропускной способностью 1 Гбайт/с. В принципе, для реального приложения хватило бы и 250Мбайт/с, но без "затычек" на шине, по крайней мере не дольше 10 миллисекунд, иначе буферы PCIe-пакетов переполняются и я теряю весь кадр. Даже очень грамотно заточеный Линукс не мог дать ни одной чистой секунды, каждый раз какая-нибудь заморочка ломает мне картинку.
А в Колибри потери пакетов в принципе не должно быть. От операционной системы требуется только выделить место для буфера данных, передать его адрес устройству и... всё. Дальше DMA превращается в 100% хардверную задачу (вроде регенерации памяти или таймера), когда устройство-задатчик просто пишет свежие данные в память, а драйвер (или даже пользовательское приложение) просто их оттуда читают. Не надо ни прерываний, ни переключения задач.
В моем случае даже адрес буфера и семафора специально сообщать устройству не надо - в видеограббере они прошиты в ПЗУ. Забавно получается - не Колибри оптимизируется под имеющуюся аппаратуру, а наоборот - железо затачивается под выбранную ОСь
Пардон за офтопик. Как заработает - опишу все в деталях в отдельной теме.
Вообще-то это библия разработчика линукс-драйвервов. Вариант с кольцевым драйвером там приводится на примере сети, но оговаривается что это скорее исключение, чем рекомендуемая практика.

While it is possible to implement DMA with a polling driver, it wouldn't make sense, because a polling driver would waste the performance benefits that DMA offers over the easier processor-driven I/O.

_________________
Евангелие от Иоанна: стих 1

Code:

; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os

art_zh

Да, я посмотрел эту главу. Выше был пример работы более адекватного устройства.

Радеоны работают без поллинга. Там вообще очень много настроек. Указатель обновляется не каждый раз а после считывания заданного количества байт, прерывания на разных стадиях графического конвеера или после определённого командного пакета, всё сделано чтобы минимально нагружать процессор обслуживанием ввода-вывода. Процессор должен быть занят движком игры и Direct3D. Битва за каждый фпс.
Очень заметно именно это стремление сделать максимум работы как можно меньше отвлекая цпу.

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

Mario
Еще раз пардон. Не каждый день удается поболтать с Serg'ем

Теперь по теме.

Уже много раз говорил, и еще раз повторю: самый быстрый путь к коммерциализации Колибри ведет в embedded-рынок. Там - целый сектор вообще никем не занят:

Exotic custom operating systems
A small fraction of embedded systems require safe, timely, reliable or efficient behavior unobtainable with the one of the above architectures. In this case an organization builds a system to suit. In some cases, the system may be partitioned into a "mechanism controller" using special techniques, and a "display controller" with a conventional operating system. A communication system passes data between the two.
(взято отсюда: http://en.wikipedia.org/wiki/Embedded_system)

Самоцитата с недавней ветки: Крупные производители могут позволить себе иметь свою собственную ОСь, остро заточеную для решения специфических задач, а также обкатки, тестирования и внедрения нового железа. Средние - могут купить такую систему или арендовать оснащенный ей тестовый комплекс (за очень приличные деньги).
А куда податься мелкому шабашнику вроде меня?

Вот он, ваш клиент

А я предупреждал!
Ладно, тролли флуда не боятся

Возвращаясь к теме.

Есть интересная идея системы с единым пространством адресов.
Подробнее можно прочитать в Википедии но лучше здесь. Мне идея понравилась тем что идеально подходит для PE dll и хороша для микроядра у которого все драйверы и сервисы в user-mode.

P.S. Не следует понимать Single address space как общую память. Это не Singularity. Адресные пространства аппаратно изолированы друг от друга. Главное то что они не перекрывают друг друга.

art_zh, Вы видимо плохо понимаете законы рынка. Предприятию не важна, какая хорошая эта ОС, если он о ней не знает. А он о ней не узнает (или Вы думаете, что все тока и лазеют в нете в поисках чуда? наивно). Или Вы знаете инвестора, который готов в _очень рискованный_ сегмент рынка вложить деньги (очень рискованный потому что конкуренты - компании с многолетним опытом, и чертовски хорошо пропиаренные. не верите? Покажите мне хоть одну низкоуровневую разработку, которая за последние 5 лет будучи написана на энтузиазме, получила инвестиции? Что то не припоминаю).

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

где здесь рынок? конкуренты, ау!

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



В списке Форбс никто из инженеров-шабашников никогда не появится, у них более интересных задач полно. А так чтобы на хлеб с маслом заработать - тут примеров туча. Вот очень знакомый перец: <http://hitechglobal.com>
Лет 6 назад клепал FPGA-борта на заказ, а как в 2007 его pci-express карту включили в список рекомендованных прототипов Xilinx - тут бабло и попёрло.

Среди асм-программистов: например, ребята из U-boot, которые на голом энтузиазме забабахали простенький ROM-загрузчик для AVR, а теперь те же Xilinx и Atmel их здорово подкармливают и всячески пиарят (понятно, чтобы отбить свой кусок каравая у AMD, Intel и Freescale)

_________________
Евангелие от Иоанна: стих 1

Code:

; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os