Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Вс сен 24, 2017 1:29 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 5 сообщений ] 
Автор Сообщение
СообщениеДобавлено: Вт май 25, 2010 10:04 am 
Не в сети

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

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

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


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


Вернуться к началу
СообщениеДобавлено: Вт май 25, 2010 2:11 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Ср янв 27, 2010 10:59 am
Сообщения: 269
По моему - это совсем не бред, Колибри изначально - ось с GUI. А сделать драйвер оконной системы - вполне реально. Поддерживаю ;)

_________________
ушёл...


Вернуться к началу
СообщениеДобавлено: Вт май 25, 2010 2:48 pm 
Sorcerer
Как программист ты можешь заниматься чем угодно, не факт что остальные тебя подержат и будут помогать, но никто ничего не запрещает.
Выскажу свое субъективное мнение. Просьба не воспринимать как просто критику - пытаюсь обоснованно оценить.
Цитата:
1) Код ядра станет проще и легче

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

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

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

Неоптимальный подход - если уж переделывать, то переделывать, полумеры вредны.
Цитата:
Но сейчас же никто не мешает программам писать напрямую хоть в kernel.mnt?

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

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


Вернуться к началу
   
СообщениеДобавлено: Вт май 25, 2010 6:30 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пт июн 27, 2008 3:22 pm
Сообщения: 974
Согласен по всем пунктам.

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


Вернуться к началу
СообщениеДобавлено: Вт май 25, 2010 9:08 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
С пунктами - согласен, с базовой концепцией - нет.
Переделка ядра нужна только если она делает систему быстрее, компактнее и надёжнее.
Sorcerer писал(а):
Идея такая. Драйвер для Колибри - по сути, библиотека с немного другим API, выполняющаяся в ring 0 и имеющая только одну копию в памяти для всех запущенных программ, так?

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

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

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

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


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 5 сообщений ] 

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB