Asmxygen
Websvn
Builds
Bugs
FTP
Wiki
Telegram
Discord
RedditВ пользу микроядра - широкая возможность по масштабированию системы. Конечно можно добиться подобного эффекта за счет модульного монолита, но микроядро под это изначально предназначено.
А насчет 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. В работе микроядра проще разобраться.
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
Честно, не знаю :-). Я бы с интересом попилил ядро Linux, ведь не обязательно делать очередной дистрибутив Linux при использовании ядра Linux. Зато сколько проблем с железом решится.
> L4 - опять же тащить чужое
Не аргумент. Чужого там минимум. Возвращаясь к нашим баранам (POSIX :-), в KOS никто пока не предпринимал попыток написать "свою libc", все использовали существующий код, а ЕМНИС он куда как больше ядра Pistachio. Т.е. либо фанатично заявляем всё своё, либо давайте уж заимствовать (я переписывать FFmpeg не стану, так и знайте ;-). Без чужого никак, это наши реалии.
3. Аргумент звучит не плохо, но получится как всегда. Нужно что-то сделать, а существующий интерфейс не позволяет, прикрутим фичу сбоку, а потом, может быть когда-нибудь, сделаем по людски.
1. Как я понял связан с 3.
2. Марат там еще дополнил :-).
4. Про это мне, увы, ничего не известно.
..bw
Здесь вообще кто-нибудь читает чужие посты?Serge wrote:art_zh
Наверное это неправильные оси.Такой сервис есть в любом приличном ядре. В Линукс с этим точно нет проблем. Выделяется ДМА память, запрашивается физический адрес.art_zh wrote:Все что для этого требуется от системы - зафиксировать семафор в статическом блоке и передать устройству его физический адрес
Я по-моему подробно изложил, как именно предоставляется такой сервис в любом "приличном" ядре. Если бы мне нравилось как это наворочено в Линуксе, я бы не пришел в Колибри.
Уж кто-кто, но Вы-то должны почувствовать разницу между опросом состояния семафора через аппаратное прерывание (несколько тысяч процессорных тактов, плюс минимум два переключения задачи, плюс инвалидация кеша) и его прямым чтением в решиме захвата шины (6-10 тактов PCI или 2 "маленьких" пакета PCIe, совершенно прозрачно для текущей задачи CPU)
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for osart_zh
Видимо мне не приходилось иметь дело с этими "приличными" ядрами. Конечно это кошмарная ситуация. О каких системах идёт речь ?
Видимо мне не приходилось иметь дело с этими "приличными" ядрами. Конечно это кошмарная ситуация. О каких системах идёт речь ?
Линукс и все остальное. И аппаратные семафоры - это ерунда.Serge wrote:art_zh
Видимо мне не приходилось иметь дело с этими "приличными" ядрами. Конечно это кошмарная ситуация. О каких системах идёт речь ?
Вот навскидку цитата из "Linux Device Drivers", ch.15 "Memory mapping and DMA"
Code: Select all
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-й шаг, и то в ряде случаев можно обойтись без конечного прерывания
Last edited by art_zh on Wed Jan 27, 2010 12:38 pm, edited 1 time in total.
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for osart_zh
А можно подробнее описать ситуацию ? Похожую схему с записью указателей в системную память использует командный процессор GPU Radeon. Но там все работает без шаманства. Можно в личку. Очень интересно.
Или это проблемы в user-mode ?
А можно подробнее описать ситуацию ? Похожую схему с записью указателей в системную память использует командный процессор GPU Radeon. Но там все работает без шаманства. Можно в личку. Очень интересно.
Или это проблемы в user-mode ?
art_zh
Ну там описано гипотетическое устройство. Может некоторые сетевые карты действительно два раза дёргают ядро чтобы выполнить ДМА, но это скорее проблема железа. Такая карта и в Колибри будет работать не лучше.
Для сравнения командный процессор Rage128 - Radeon : кольцевой буфер в системной памяти размером до 2 Мб. Два регистра устройства определяют положение указателей чтения и записи. У драйвера свои копии. Равенство регистров означает что буфер пуст.
Драйвер пишет в буфер команды в специальном формате и записывает новый адрес указателя записи в регистр. Командный процессор читает данные и обновляет свой указатель чтения после чего переписывает укзатель драйвера в системной памяти. Для этого при инициализации драйвер записывает в гпу физический адрес своего указателя. Всё сделано для того чтобы минимизировать обращения драйвера к устройству, особенно чтение регистров. Самые необходимые регистры гпу пишет в системную память сам. И нет никаких ненужных прерываний.
P.S. К сожалению такие книжки часто пишут люди плохо разбырающиеся в вопросе. Даже в Intel® Architecture
Software Developer’s Manual приводится такой обработчик fpu
1. сохраняем текущий контекст фпу
2. загружаем новый контекст
3. clts
Алгоритм пережил массу переизданий и правок.
Ну там описано гипотетическое устройство. Может некоторые сетевые карты действительно два раза дёргают ядро чтобы выполнить ДМА, но это скорее проблема железа. Такая карта и в Колибри будет работать не лучше.
Для сравнения командный процессор Rage128 - Radeon : кольцевой буфер в системной памяти размером до 2 Мб. Два регистра устройства определяют положение указателей чтения и записи. У драйвера свои копии. Равенство регистров означает что буфер пуст.
Драйвер пишет в буфер команды в специальном формате и записывает новый адрес указателя записи в регистр. Командный процессор читает данные и обновляет свой указатель чтения после чего переписывает укзатель драйвера в системной памяти. Для этого при инициализации драйвер записывает в гпу физический адрес своего указателя. Всё сделано для того чтобы минимизировать обращения драйвера к устройству, особенно чтение регистров. Самые необходимые регистры гпу пишет в системную память сам. И нет никаких ненужных прерываний.
P.S. К сожалению такие книжки часто пишут люди плохо разбырающиеся в вопросе. Даже в Intel® Architecture
Software Developer’s Manual приводится такой обработчик fpu
1. сохраняем текущий контекст фпу
2. загружаем новый контекст
3. clts
Алгоритм пережил массу переизданий и правок.
Last edited by Serge on Wed Jan 27, 2010 1:56 pm, edited 1 time in total.
В моем случае есть устройство (CMOS-камера. самодельная, но очень шустрая), которое получает, группирует и подготавливает к вводу большие блоки информации. Одна видеолиния (1280 пикселей, 10 бит на пиксель) оцифровывается за 2 микросекунды . Пятьсот XGA-кадров в секунду!Serge wrote:art_zh
А можно подробнее описать ситуацию ? Похожую схему с записью указателей в системную память использует командный процессор GPU Radeon. Но там все работает без шаманства. Можно в личку. Очень интересно.
Видеограббер собран на мощном FPGA-модуле и поддерживает протокол PCI express x4 с теоретической пропускной способностью 1 Гбайт/с. В принципе, для реального приложения хватило бы и 250Мбайт/с, но без "затычек" на шине, по крайней мере не дольше 10 миллисекунд, иначе буферы PCIe-пакетов переполняются и я теряю весь кадр. Даже очень грамотно заточеный Линукс не мог дать ни одной чистой секунды, каждый раз какая-нибудь заморочка ломает мне картинку.
А в Колибри потери пакетов в принципе не должно быть. От операционной системы требуется только выделить место для буфера данных, передать его адрес устройству и... всё. Дальше DMA превращается в 100% хардверную задачу (вроде регенерации памяти или таймера), когда устройство-задатчик просто пишет свежие данные в память, а драйвер (или даже пользовательское приложение) просто их оттуда читают. Не надо ни прерываний, ни переключения задач.
В моем случае даже адрес буфера и семафора специально сообщать устройству не надо - в видеограббере они прошиты в ПЗУ. Забавно получается - не Колибри оптимизируется под имеющуюся аппаратуру, а наоборот - железо затачивается под выбранную ОСь
Пардон за офтопик. Как заработает - опишу все в деталях в отдельной теме.
Вообще-то это библия разработчика линукс-драйвервов. Вариант с кольцевым драйвером там приводится на примере сети, но оговаривается что это скорее исключение, чем рекомендуемая практика.К сожалению такие книжки часто пишут люди плохо разбырающиеся в вопросе
Code: Select all
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[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for osart_zh
Да, я посмотрел эту главу. Выше был пример работы более адекватного устройства.
Радеоны работают без поллинга. Там вообще очень много настроек. Указатель обновляется не каждый раз а после считывания заданного количества байт, прерывания на разных стадиях графического конвеера или после определённого командного пакета, всё сделано чтобы минимально нагружать процессор обслуживанием ввода-вывода. Процессор должен быть занят движком игры и Direct3D. Битва за каждый фпс.
Очень заметно именно это стремление сделать максимум работы как можно меньше отвлекая цпу.
Да, я посмотрел эту главу. Выше был пример работы более адекватного устройства.
Радеоны работают без поллинга. Там вообще очень много настроек. Указатель обновляется не каждый раз а после считывания заданного количества байт, прерывания на разных стадиях графического конвеера или после определённого командного пакета, всё сделано чтобы минимально нагружать процессор обслуживанием ввода-вывода. Процессор должен быть занят движком игры и Direct3D. Битва за каждый фпс.
Очень заметно именно это стремление сделать максимум работы как можно меньше отвлекая цпу.
Мне так кажется, что оффтопную подтему было бы полезно выделить в отдельную. Вопрос важный, но от центральной темы уехали. К сожалению Модераторы как всегда не при делах...