Board.KolibriOS.org

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

Идея такая. Драйвер для Колибри - по сути, библиотека с немного другим API, выполняющаяся в ring 0 и имеющая только одну копию в памяти для всех запущенных программ, так?
Если функции GUI будет выполнять некоторый "драйвер", то:
1) Код ядра станет проще и легче
2) Код gui-части системы тоже станет "изолирован" и более удобен для правок
3) Потерь в скорости работы оконной подсистемы быть не должно, потому что работает все в ring 0
4) Если не исключать некоторое время (допустим, пару релизов) старый код gui из ядра, то никаких проблем с совместимостью не предвидится - исправленные программы будут работать через "драйвер" оконной системы, неисправленные - обращаться к ядру (а ядро вполне может редиректить их к "драйверу")

Однако, если вся эта ерундовина будет крутиться в ring 0, можно возразить, что это приведет к ослаблению системы в плане безопасности (допустим, замена драйвера оконной подсистемы на вредоносный код). Но сейчас же никто не мешает программам писать напрямую хоть в kernel.mnt?


Вот такие бредовые мысли.

По моему - это совсем не бред, Колибри изначально - ось с GUI. А сделать драйвер оконной системы - вполне реально. Поддерживаю

Sorcerer
Как программист ты можешь заниматься чем угодно, не факт что остальные тебя подержат и будут помогать, но никто ничего не запрещает.
Выскажу свое субъективное мнение. Просьба не воспринимать как просто критику - пытаюсь обоснованно оценить.

1) Код ядра станет проще и легче

Сомнительно. Ничем не подтвержденное утверждение.

2) Код gui-части системы тоже станет "изолирован" и более удобен для правок

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

Потерь в скорости работы оконной подсистемы быть не должно, потому что работает все в ring 0

Тут согласен -как минимум заметно медленнее не станет.

4) Если не исключать некоторое время (допустим, пару релизов) старый код gui из ядра, то никаких проблем с совместимостью не предвидится - исправленные программы будут работать через "драйвер" оконной системы, неисправленные - обращаться к ядру (а ядро вполне может редиректить их к "драйверу")

Неоптимальный подход - если уж переделывать, то переделывать, полумеры вредны.

Но сейчас же никто не мешает программам писать напрямую хоть в kernel.mnt?

В системе нет разделения прав, со всеми вытекающими. Ядро это обычный файл.

С точки зрения эффективности нужно проектирование и планирование. Иначе может получиться очередная перетряска ядра добавляющаяя еще костылей.

Согласен по всем пунктам.

Изолирован в смысле локализован?

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

Sorcerer wrote:Идея такая. Драйвер для Колибри - по сути, библиотека с немного другим API, выполняющаяся в ring 0 и имеющая только одну копию в памяти для всех запущенных программ, так?

Такая "ядерная" библиотека уже существует и более-менее удовлетворительно работает.
Вынесение кода из ядра в драйвер не сделает систему ни компактнее, ни производительнее.
Всё равно каждый вызов GUI-драйвера будет требовать входа в ring0.

Альтернатива 1 (наихудшая): перенести драйвер в ring3-DLL.
-- Будет работать гораздо быстрее, но крайне ненадёжно.

Альтернатива 2 (наилучшая): сделать обработку GUI-вызовов асинхронной.
-- Приложение не должно стучаться в ring0 по каждому ерундовому поводу. Вместо этого имеет смысл реализовать общесистемный буфер GUI-запросов, который будет периодически обрабатываться драйвером-модулем графической подсистемы.
Все буферизованные запросы обрабатывать одним системным вызовом
- с возможностью дальнейшей оптимизации отрисовки перекрытых окон, работы с оконным стеком, панелью, стрелкой мыши и курсором
- и аппаратной акселерации части GUI-запросов на GPU.

Второй подход позволит значительно увеличить производительность графической подсистемы при сохранении существующего уровня надежности.
Размер системы (ядро+графический модуль)
- для неоптимизированной буферизации GUI-запросов заметно не изменится;
- многопроходная оптимизация раздует код, но ещё больше увеличит скорость;
- GPU-акселератор позволит значительно сократить системный код при одновременном увеличении производительности.
Важно: графический модуль можно будет легко менять/апгрейдить/переключать без переделки GUI-кода приложений.