Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Пт мар 24, 2017 8:55 pm

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




Начать новую тему  Ответить на тему  [ 30 сообщений ]  На страницу 1 2 След.
Автор Сообщение
СообщениеДобавлено: Вт янв 26, 2010 2:26 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 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!


Вернуться к началу
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Вт янв 26, 2010 2:48 pm 
Не в сети

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


Вернуться к началу
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Ср янв 27, 2010 12:11 am 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
Раз почти никому это не надо, то сделаю так, как считаю нужным.

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

Kolibri is best operation system in the world!


Вернуться к началу
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Ср янв 27, 2010 7:48 am 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Вт янв 15, 2008 11:27 am
Сообщения: 750
andrew_programmer
Если не секрет, то как именно ты считаешь нужным? Очень интересно.


Вернуться к началу
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Ср янв 27, 2010 5:26 pm 
Не в сети
Аватара пользователя

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

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

Kolibri is best operation system in the world!


Вернуться к началу
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Ср янв 27, 2010 9:21 pm 
Не в сети
Mentor
Аватара пользователя

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


Вернуться к началу
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Ср янв 27, 2010 10:54 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
Цитата:
а насколько прикладному программисту будет сложнее писать программы?

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

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

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

Kolibri is best operation system in the world!


Вернуться к началу
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Чт янв 28, 2010 2:33 pm 
Не в сети

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

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


Вернуться к началу
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Чт янв 28, 2010 5:24 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
andrew_programmer писал(а):
Если как по мне, то все функции рисования и работы с окнами, что сейчас есть в ядре, только мешают нормальной работе с графикой и окнами. В результате получается куча костылей и в коде ядра разобраться значительно сложнее.

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

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

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

С целью?

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


Вернуться к началу
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Чт янв 28, 2010 7:41 pm 
Не в сети
Аватара пользователя

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

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

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

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

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

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

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

Цитата:
Специальный процесс - это независимо ни от чего минус к скорости, причём довольно заметный. Приложение хочет нарисовать окно и вместо того, чтобы одним системным вызовом попасть в код создания окна, подаёт сигнал серверу. Который - вот незадача! - постоянно занят отрисовкой всяких линий, потому что где-то на заднем фоне пользователь поставил что-то крутиться для красоты. Независимо от реализации 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!


Вернуться к началу
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Чт янв 28, 2010 8:07 pm 
Не в сети

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


Вернуться к началу
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Чт янв 28, 2010 8:23 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
Драйверы не в ядре - это уже микро ядро. Тема микро ядра обсуждается у нас в новостях. :)

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

Kolibri is best operation system in the world!


Вернуться к началу
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Чт янв 28, 2010 8:27 pm 
Не в сети

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


Вернуться к началу
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Чт янв 28, 2010 8:39 pm 
Не в сети
Аватара пользователя

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

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

Kolibri is best operation system in the world!


Вернуться к началу
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Чт янв 28, 2010 8:41 pm 
Не в сети

Зарегистрирован: Вс ноя 04, 2007 2:46 am
Сообщения: 390
Угу, я про это.


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 30 сообщений ]  На страницу 1 2 След.

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


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

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


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

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