Board.KolibriOS.org

Official KolibriOS board
It is currently Sat May 25, 2019 12:13 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 30 posts ]  Go to page 1 2 Next
Author Message
PostPosted: Tue Jan 26, 2010 2:26 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Вопрос по текущему ядру KolibriOS. Оконной подсистеме, необходимо работать с драйверами: видео, мыши, клавиатуры. В Linux этим занимается X-sercer(в пространстве приложений) в Windows это всё в ядре. В общем нужно решить вопрос, как быть.

1)Графику в user mode отдельным процессом типа X-server в Linux.
2) Каждая программа будет использовать специальную библиотеку уровня ядра для работы с различными драйверами и с окнами. Типа как сейчас звук через Infinity.
3)Оставить всё как есть и пусть каждая программа сама мучается с окнами и драйверами или вообще их не использует.

Без решения этой проблемы, с окошками в текущей KolibriOS ничего нормального не сделать.

_________________
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!


Top
   
PostPosted: Tue Jan 26, 2010 2:48 pm 
Offline

Joined: Wed Mar 26, 2008 12:44 pm
Posts: 225
Есть ещё одна проблема: медленный IPC.
Ведь что-бы вывести строку текста, придётся послать сообщение X-серверу, а строк может оказаться не один десяток. X-сервер, в свою очередь, отреагирует лишь когда до него очередь дойдёт.


Top
   
PostPosted: Wed Jan 27, 2010 12:11 am 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Раз почти никому это не надо, то сделаю так, как считаю нужным.

_________________
KolibriOS-перспективная ос!

Kolibri is best operation system in the world!


Top
   
PostPosted: Wed Jan 27, 2010 7:48 am 
Offline
Mentor
User avatar

Joined: Tue Jan 15, 2008 11:27 am
Posts: 752
andrew_programmer
Если не секрет, то как именно ты считаешь нужным? Очень интересно.


Top
   
PostPosted: Wed Jan 27, 2010 5:26 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Если как по мне, то все функции рисования и работы с окнами, что сейчас есть в ядре, только мешают нормальной работе с графикой и окнами. В результате получается куча костылей и в коде ядра разобраться значительно сложнее.
Я считаю, что в ядре должны работать только динамически подгружаемые драйверы. Но не одной программе нельзя будет обращаться к этим драйверам напрямую. Для создания окон и рисования в них, нужно обращаться к специальному процессу, который будет общаться с драйверами работающими в ядре и выполнять ту же роль, что и X-server в Unix системах. Да, сейчас IPC медленно работает, но ни что не мешает переделать его как надо. Исходники открыты. Это вопрос только времени выполнения работы.
Поначалу надо реализовать X-server используя те возможности, что сейчас есть в Колибри. Провести эксперименты. Так как код будет писаться на C/C++, то адаптировать его под исправленную систему будет не сложно.

_________________
KolibriOS-перспективная ос!

Kolibri is best operation system in the world!


Top
   
PostPosted: Wed Jan 27, 2010 9:21 pm 
Offline
Mentor
User avatar

Joined: Tue Jan 15, 2008 11:27 am
Posts: 752
спасибо.
сложно, но ИМХО правильно...
а насколько прикладному программисту будет сложнее писать программы? и интересно, как сообщество отнесётся к тому, что оконная подсистема будет на Си?


Top
   
PostPosted: Wed Jan 27, 2010 10:54 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Quote:
а насколько прикладному программисту будет сложнее писать программы?

Вот когда сделаю, тогда и обсудим. :)
Quote:
и интересно, как сообщество отнесётся к тому, что оконная подсистема будет на Си?

Так оконная подситема - это логический код, а драйверы в KolibriOS написаны на ассемблере(за исключением драйвера ATI).

_________________
KolibriOS-перспективная ос!

Kolibri is best operation system in the world!


Top
   
PostPosted: Thu Jan 28, 2010 2:33 pm 
Offline

Joined: Sun Feb 18, 2007 8:34 pm
Posts: 158
Я давно говорил, что графику нужно максимально вынести из ядра. Набор системных функций, начинающийся с функции рисования окна, выглядит как-то нелепо.

Вообще отдельный процесс - это явно графическая оболочка. Другое дело, какие функции на нее возложить и как с ней взаимодействовать. Непосредственно выводом на экран может управлять GUI-сервер, работающий в пространстве ядра (это единственное, что его связывает с ядром). Оболочке можно передавать лишь короткие сообщения, связанные с атрибутами/состоянием окна к примеру на таскбаре или в трее, причем не через имеющиеся средства IPC, а через тот же GUI-сервер.


Top
   
PostPosted: Thu Jan 28, 2010 5:24 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
andrew_programmer wrote:
Если как по мне, то все функции рисования и работы с окнами, что сейчас есть в ядре, только мешают нормальной работе с графикой и окнами. В результате получается куча костылей и в коде ядра разобраться значительно сложнее.

"Если это глупо, но работает, значит, это не глупо." (c) из законов Мерфи
В данный момент графика и окна вполне себе работают. На основании каких фактов делается вывод, что работа ненормальная?
Примеры костылей, кстати, в студию.
Очевидно, что сами по себе функции рисования и работы с окнами в том или ином виде в системе останутся. Следовательно, разобраться в них будет заведомо не проще, чем сейчас. А поскольку добавятся обёртывающие слои, в которых тоже нужно будет разбираться, то предлагаемые изменения ведут к усложнению понимания, а не наоборот.
andrew_programmer wrote:
Я считаю, что в ядре должны работать только динамически подгружаемые драйверы. Но ни одной программе нельзя будет обращаться к этим драйверам напрямую. Для создания окон и рисования в них, нужно обращаться к специальному процессу, который будет общаться с драйверами работающими в ядре и выполнять ту же роль, что и X-server в Unix системах. Да, сейчас IPC медленно работает, но ни что не мешает переделать его как надо. Исходники открыты. Это вопрос только времени выполнения работы.

Специальный процесс - это независимо ни от чего минус к скорости, причём довольно заметный. Приложение хочет нарисовать окно и вместо того, чтобы одним системным вызовом попасть в код создания окна, подаёт сигнал серверу. Который - вот незадача! - постоянно занят отрисовкой всяких линий, потому что где-то на заднем фоне пользователь поставил что-то крутиться для красоты. Независимо от реализации IPC будут тормоза.
Лично я против любых ненужных дополнительных слоёв. Необходимость X-сервера явно как минимум сомнительна.
andrew_programmer wrote:
и интересно, как сообщество отнесётся к тому, что оконная подсистема будет на Си?

Лично я - отрицательно.
Phantom84 wrote:
Я давно говорил, что графику нужно максимально вынести из ядра.

С целью?

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
PostPosted: Thu Jan 28, 2010 7:41 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Я прекрасно помню, что diamond противник вынесения какой-либо графики из ядра.
А ещё есть сторонники идеи,"Нечего засорять ядро всяким гов**м". Попробуйте найти компромисное решение, удовлетворяющее и первым, и вторым....
Теперь к делу.
Quote:
"Если это глупо, но работает, значит, это не глупо." (c) из законов Мерфи

Я не утверждал, что это глупо.
Quote:
В данный момент графика и окна вполне себе работают. На основании каких фактов делается вывод, что работа ненормальная?

Вот в Windows для организации интерфейса есть окна следующих типов: главное окно, дочернее окно, всплывающее окно. Функции рисования окон аппаратно ускорены. Также в windows есть библиотека GDI в которой есть все необходимые функции рисования. Причём они аппаратно ускоренные и нет никакого намёка на драйверы для различных устройств. Программист просто пользуется библиотекой не парясь ни о каких драйверах. Теперь подумаем о возможности реализации всего этого в KolibriOS.
1)Главное окно есть? Да. Дочерние окна есть? Нет. Можно только попытаться эмулировать это программно, причём в некоторых случаях с потерей производительности и с добавкой дополнительного кода. Всплывающие окна есть? Нет. Окон, которые всегда на самом верху - нет. И на данный момент эмулировать их просто невозможно! Я уже не говорю об аппаратной отрисовке окон.
2)Аппаратное ускорение возможно задействовать обращением к операционной системе через прерывания без помощи сторонних библиотек? Нет.
А если я захочу задействовать аппаратное ускорение 3D, что тогда делать? Mesa, между прочим, взаимодействует с X-server-ом для аппаратной отрисовки внутри окон.

Quote:
Примеры костылей, кстати, в студию.

Примеры давно уже у всех на слуху. То и дело люди жалуются на артефакты "след окна" возникающие при пересечении иконок и окон обычных приложений. Отрисовка курсора: скрываем курсор, рисуем, отображаем. Это ужас. Текст и числа отрисовывает операционная система. Кнопки отрисовывает операционная система. А если я захочу 10000 кнопок то все их должна перебирать операционная система. Как тогда насчёт времени отклика и скорости работы OS? Сколько раз повторялись глюки с незакрытием окна, из-за пересечения областей кнопок и кнопки закрытия окна. Вывод битмапа только 24 бита. Если с палитрой, то отдельная ситемная подфункция. Неужели по всякому поводу будем заводить подфункции системных функций?
Смотрим внимательно на код ядра. То здесь, то там вылезает кусок кода касающийся GUI. Причём все время надо проверять к какому процессу относиться, смотреть параметры окон, рабочей области. Буфер этот статический на 255 элементов. А если захочется больше потоков, значит заново перекраивать код и учитывать специфику разбросанного кода GUI в ядре? Статический код графики и GUI приводит к путанице и бардаку в ядре усложняя понимание и соответственно модернизацию этого кода.
Вообще, задача операционной системы распределять системные ресурсы и разграничивать их между процессами. А не рисованием заниматься.

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

Если всё делать правильно, то программист будет просто наслаждаться удобством пользования библиотекой. Как это сейчас с InfinitySound. Не нужно париться с драйверами и их устройством - есть промежуточный абстрактный слой.

Quote:
Специальный процесс - это независимо ни от чего минус к скорости, причём довольно заметный. Приложение хочет нарисовать окно и вместо того, чтобы одним системным вызовом попасть в код создания окна, подаёт сигнал серверу. Который - вот незадача! - постоянно занят отрисовкой всяких линий, потому что где-то на заднем фоне пользователь поставил что-то крутиться для красоты. Независимо от реализации IPC будут тормоза.
Лично я против любых ненужных дополнительных слоёв. Необходимость X-сервера явно как минимум сомнительна.

:) :) :)
diamond, ты не обижайся на меня, но ты когда-нибудь пользовался по нормальному Linux-ом? Запускал в нём 3D эффекты Compiz? Сравнивал FPS-ы скажем Quake в Linux с Quake в Windows?
Я сравнивал. FPS-ы почти одинаковые. А знаешь почему? Потому что драйверы: видео, мыши, клавиатуры работают в ядре. А X-server выполняет роль полицейского распределяющего эти ресурсы между окнами приложений, посылающих запросы. Тоже самое я предлагаю и для KolibriOS. Драйверы в ядре, "полицейский" в user mode.

Теперь более конкретно о задаче. Решение задачи - это поиск оптимального решения. Когда искомое решение является функцией одного параметра, то тут всё ясно с оптимизацией. Когда ищется оптимальное решение сразу по нескольким параметрам, то тут всё сложнее, тем более, что у разных людей набор этих параметров различается.
Теперь о параметрах.
Что мы хотим от KolibriOS?
1) Максимальная скорость требует размещения в ядре драйверов. Безопасность требует размещения драйверов в пользовательском пространстве.
2) Удобство разработки и модернизации требует модульности операционной системы. Тогда в ядре должно быть меньше кода. Драйверы по возможности на C, хотя тут есть проблема доверия компиляторам ЯВУ. Тогда больше шансов добавить поддержку 64 битности и SMP. Всё на ассемблере, тогда быстрее(не известно на сколько процентов) и стабильние (в смысле ошибок компилятора), но портирумость и простота модернизации под новые возможности почти нулевая.

Пытаясь найти компромисс пришёл к следующему решению.
Драйверы в ядре. Конёк KolibriOS - это скорость. Менеджер окон и отрисовки в пользовательском процессе, потому что:
a)Легкость модернизации кода. Несущественно ограничение на число процессов, которые может обеспечить OS. Любое приложение автоматически будет использовать аппаратные возможности драйверов не зная особенности их работы. Можно написать любой декоратор окон и задействовать различные эффекты окон.
б)Нет лишнего кода в ядре, вносящего путаницу и усложняющего его. Нет привязки к особенностям драйверов видео.
с)Меньше статических драйверов в ядре. Больше шансов добавить SMP. А вот шансов добавить 64 бита без полного переписывания кода - нет.
d)Оконная подсистема на C, потому что код логический, а не вычислительный. И дабы увеличить скорость разработки и портируемость кода, пишется на C. Может код ещё пригодится для какого-нибудь микро ядра. :)

До тех пор пока мы ОКОНЧАТЕЛЬНО не решим чего мы ВСЕ хотим от KolibriOS так и будут споры,"Какой должна быть KolibriOS?". Надоело по 100 раз обсуждать и каждый раз все тянут в свою строну не желая идти на компромис.

_________________
KolibriOS-перспективная ос!

Kolibri is best operation system in the world!


Top
   
PostPosted: Thu Jan 28, 2010 8:07 pm 
Offline

Joined: Sun Nov 04, 2007 2:46 am
Posts: 390
andrew_programmer, ты мыслишь в правильную сторону, но зачем оставлять драйверы в ядре?
З.Ы. SMP без PnP и ACPI - пустая трата времени. Когда дойдет очередь до PnP или ACPI придется опять переписывать.


Top
   
PostPosted: Thu Jan 28, 2010 8:23 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Драйверы не в ядре - это уже микро ядро. Тема микро ядра обсуждается у нас в новостях. :)

_________________
KolibriOS-перспективная ос!

Kolibri is best operation system in the world!


Top
   
PostPosted: Thu Jan 28, 2010 8:27 pm 
Offline

Joined: Sun Nov 04, 2007 2:46 am
Posts: 390
Кто сказал? Я про физическое разделение драйверов от ядра, а не о переводе их из ring 0 куда либо. Если драйвера выполняются в нулевом кольце и в одном адресном пространстве с ядром, это ещё монолитное ядро. Или я что-то путаю? :)


Top
   
PostPosted: Thu Jan 28, 2010 8:39 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Если ты имел ввиду выделение кода драйверов в отдельные DLL, то я тоже за это. Устройств много, а ядро одно. Нечего его кодом драйверов засорять.

_________________
KolibriOS-перспективная ос!

Kolibri is best operation system in the world!


Top
   
PostPosted: Thu Jan 28, 2010 8:41 pm 
Offline

Joined: Sun Nov 04, 2007 2:46 am
Posts: 390
Угу, я про это.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 30 posts ]  Go to page 1 2 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited