Время от времени в течении пяти-семи лет на форуме обсуждают, что пора бы вынести GUI из ядра.
Возможно, я не первый, у кого появились подобные мысли, но все-таки, мне очень интересно мнение сообщества - имеет ли смысл переходить к экспериментам, или затея не будет стоить и выеденого яйца?
Идея такая. Драйвер для Колибри - по сути, библиотека с немного другим API, выполняющаяся в ring 0 и имеющая только одну копию в памяти для всех запущенных программ, так?
Если функции GUI будет выполнять некоторый "драйвер", то:
1) Код ядра станет проще и легче
2) Код gui-части системы тоже станет "изолирован" и более удобен для правок
3) Потерь в скорости работы оконной подсистемы быть не должно, потому что работает все в ring 0
4) Если не исключать некоторое время (допустим, пару релизов) старый код gui из ядра, то никаких проблем с совместимостью не предвидится - исправленные программы будут работать через "драйвер" оконной системы, неисправленные - обращаться к ядру (а ядро вполне может редиректить их к "драйверу")
Однако, если вся эта ерундовина будет крутиться в ring 0, можно возразить, что это приведет к ослаблению системы в плане безопасности (допустим, замена драйвера оконной подсистемы на вредоносный код). Но сейчас же никто не мешает программам писать напрямую хоть в kernel.mnt?
Вот такие бредовые мысли.
Бредовые мысли об оконной подсистеме
По моему - это совсем не бред, Колибри изначально - ось с GUI. А сделать драйвер оконной системы - вполне реально. Поддерживаю ![Wink ;)](./images/smilies/icon_wink.gif)
![Wink ;)](./images/smilies/icon_wink.gif)
ушёл...
Sorcerer
Как программист ты можешь заниматься чем угодно, не факт что остальные тебя подержат и будут помогать, но никто ничего не запрещает.
Выскажу свое субъективное мнение. Просьба не воспринимать как просто критику - пытаюсь обоснованно оценить.
С точки зрения эффективности нужно проектирование и планирование. Иначе может получиться очередная перетряска ядра добавляющаяя еще костылей.
Как программист ты можешь заниматься чем угодно, не факт что остальные тебя подержат и будут помогать, но никто ничего не запрещает.
Выскажу свое субъективное мнение. Просьба не воспринимать как просто критику - пытаюсь обоснованно оценить.
Сомнительно. Ничем не подтвержденное утверждение.1) Код ядра станет проще и легче
Никакой "изоляции" - уронить по прежнему будет легко. Насчет правок не знаю - требуется переписывание с использованием макросов и прочее, тогда может быть.2) Код gui-части системы тоже станет "изолирован" и более удобен для правок
Тут согласен -как минимум заметно медленнее не станет.Потерь в скорости работы оконной подсистемы быть не должно, потому что работает все в ring 0
Неоптимальный подход - если уж переделывать, то переделывать, полумеры вредны.4) Если не исключать некоторое время (допустим, пару релизов) старый код gui из ядра, то никаких проблем с совместимостью не предвидится - исправленные программы будут работать через "драйвер" оконной системы, неисправленные - обращаться к ядру (а ядро вполне может редиректить их к "драйверу")
В системе нет разделения прав, со всеми вытекающими. Ядро это обычный файл.Но сейчас же никто не мешает программам писать напрямую хоть в kernel.mnt?
С точки зрения эффективности нужно проектирование и планирование. Иначе может получиться очередная перетряска ядра добавляющаяя еще костылей.
Согласен по всем пунктам.
Изолирован в смысле локализован?
Изолирован в смысле локализован?
С пунктами - согласен, с базовой концепцией - нет.
Переделка ядра нужна только если она делает систему быстрее, компактнее и надёжнее.
Вынесение кода из ядра в драйвер не сделает систему ни компактнее, ни производительнее.
Всё равно каждый вызов GUI-драйвера будет требовать входа в ring0.
Альтернатива 1 (наихудшая): перенести драйвер в ring3-DLL.
-- Будет работать гораздо быстрее, но крайне ненадёжно.
Альтернатива 2 (наилучшая): сделать обработку GUI-вызовов асинхронной.
-- Приложение не должно стучаться в ring0 по каждому ерундовому поводу. Вместо этого имеет смысл реализовать общесистемный буфер GUI-запросов, который будет периодически обрабатываться драйвером-модулем графической подсистемы.
Все буферизованные запросы обрабатывать одним системным вызовом
- с возможностью дальнейшей оптимизации отрисовки перекрытых окон, работы с оконным стеком, панелью, стрелкой мыши и курсором
- и аппаратной акселерации части GUI-запросов на GPU.
Второй подход позволит значительно увеличить производительность графической подсистемы при сохранении существующего уровня надежности.
Размер системы (ядро+графический модуль)
- для неоптимизированной буферизации GUI-запросов заметно не изменится;
- многопроходная оптимизация раздует код, но ещё больше увеличит скорость;
- GPU-акселератор позволит значительно сократить системный код при одновременном увеличении производительности.
Важно: графический модуль можно будет легко менять/апгрейдить/переключать без переделки GUI-кода приложений.
Переделка ядра нужна только если она делает систему быстрее, компактнее и надёжнее.
Такая "ядерная" библиотека уже существует и более-менее удовлетворительно работает.Sorcerer wrote:Идея такая. Драйвер для Колибри - по сути, библиотека с немного другим API, выполняющаяся в ring 0 и имеющая только одну копию в памяти для всех запущенных программ, так?
Вынесение кода из ядра в драйвер не сделает систему ни компактнее, ни производительнее.
Всё равно каждый вызов GUI-драйвера будет требовать входа в ring0.
Альтернатива 1 (наихудшая): перенести драйвер в ring3-DLL.
-- Будет работать гораздо быстрее, но крайне ненадёжно.
Альтернатива 2 (наилучшая): сделать обработку GUI-вызовов асинхронной.
-- Приложение не должно стучаться в ring0 по каждому ерундовому поводу. Вместо этого имеет смысл реализовать общесистемный буфер GUI-запросов, который будет периодически обрабатываться драйвером-модулем графической подсистемы.
Все буферизованные запросы обрабатывать одним системным вызовом
- с возможностью дальнейшей оптимизации отрисовки перекрытых окон, работы с оконным стеком, панелью, стрелкой мыши и курсором
- и аппаратной акселерации части GUI-запросов на GPU.
Второй подход позволит значительно увеличить производительность графической подсистемы при сохранении существующего уровня надежности.
Размер системы (ядро+графический модуль)
- для неоптимизированной буферизации GUI-запросов заметно не изменится;
- многопроходная оптимизация раздует код, но ещё больше увеличит скорость;
- GPU-акселератор позволит значительно сократить системный код при одновременном увеличении производительности.
Важно: графический модуль можно будет легко менять/апгрейдить/переключать без переделки GUI-кода приложений.
Who is online
Users browsing this forum: No registered users and 6 guests