Привет. Очень давно наткнулся на вашу ОС в интернете, появилось несколько вопросов о принципах её работы.
1) Графическая подсистема. Если я правильно помню, чтобы приложению отрисовать окно или какой-нибудь виджет, ему нужно было дёргать системный вызов (ядро предоставляет набор системных вызовов для работы с графикой). Правильно я понимаю, что на каждый отрисованный виджет или клик пользователя происходит переключение контекста? Или это в прошлом, и существует некая юзерспейс библиотека для графики.
2) Каков формат исполняемых файлов? Есть ли поддержка разделяемых библиотек? Загрузка библиотек -- функция ядра или юзерспейса?
3) Есть ли SMP?
4) Как с поддержкой USB, сетевых протоколов, драйверами Ethernet карт, IEEE802.11?
5) Что с IPC? Есть ли взаимствования из POSIX, такие как сокеты, пайпы, потоки ввода/вывода?
6) Какие фичи системы виртуальной памяти у вас есть? Есть ли поддержка Large/Huge pages?
7) Есть ли поддержка SSE в ядре? Сохраняет ли ядро xmm регистры между переключениями контекста?
8 ) Правильно ли я понял, что нет x86-64 версии? Почему так?
Надеюсь на ваш ответ, спасибо.
Пара технических вопросов о вашей ОС
1) В любой ОС системные библиотеки являются оболочками над вызовами с переключением контекста. В windows vista (и её родственниках) постарались перенести в юзерспейс всё что можно, из-за чего они стали дико тормозить. В любом случае, 1000 тактов на вызов — это мелочи, другие ОС умудряются тупо просрать гораздо больше.
2) Menuet01, библиотеки COFF, ждём РЕ.
4) Хорошо, неплохо, неплохо, никак.
6) Базовые. Нет.
7) К ОС отношения не имеет. Не использует.
8) Нет. Зачем?
2) Menuet01, библиотеки COFF, ждём РЕ.
4) Хорошо, неплохо, неплохо, никак.
6) Базовые. Нет.
7) К ОС отношения не имеет. Не использует.
8) Нет. Зачем?
3) No
5) There is system call 60,2.
IPC sockets were implemented long time ago, but never properly tested.
5) There is system call 60,2.
IPC sockets were implemented long time ago, but never properly tested.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
Юзерспейс не обязательно должен контактировать к кернелспейсом только системными вызовами. Есть ещё общая память хотя бы. Тот же ввод/вывод с помощью fprintf() не дёргает write на каждый чих, а использует буфферизацию. Те же мьютексы из pthread в большинстве POSIX-совместимых ОС вызывают ядро только когда надо спать, а для доступа к мьютексу используют атомарные операции. Примеров куча, когда системный вызов откладывается как можно дальше.Pathoswithin wrote:1) В любой ОС системные библиотеки являются оболочками над вызовами с переключением контекста.
Исполнение в пространстве ядра ещё не гарантия какой-либо быстроты. Быстрота -- это сведение к минимуму переключения контекстов, так что можно быстро работать и в юзерспейсе, железо ведь то же самое. Пока у вас программы простые и маленькие -- эти переключения ещё терпимы, но как только они станут большими и замысловатыми (хотя бы как firefox, например), дикое количество переключений и сопутствующие промахи в кеше просто убьют все другие преимущества, так мне кажетсяPathoswithin wrote: В windows vista (и её родственниках) постарались перенести в юзерспейс всё что можно, из-за чего они стали дико тормозить. В любом случае, 1000 тактов на вызов — это мелочи, другие ОС умудряются тупо просрать гораздо больше.
Здорово! Кстати, появился вопрос по поводу исходников. У вас в любой программе из исходников SVN (возьмем для примера programs/demos/fire/trunck/fire.asm) нет даже намёка на стек. Нет ни call (есть какой-то mcall, но я не знаю, что это), ни регистров %esp/%ebp. Вы не используете стек в своих программах O_o? Или просто это всё сильно замаскированно? (Я не знаю этого диалекта ассемблера). Ядро создаёт стек в адресном пространстве для нового процесса? А куча с аналогами malloc()/free() есть? А вы придерживаетесь SystemV x86(-64) ABI в плане вызова функций, или у вас свои соглашения?Pathoswithin wrote: 2) Menuet01, библиотеки COFF, ждём РЕ.
Имеет прямое отношение. Если регистры xmm0-xmm15 и контрольный регистр mxcsr не сохранять при переключении контекста, то SSE инструкции станет абсолютно невозможно использовать.Pathoswithin wrote: 7) К ОС отношения не имеет. Не использует.
Разумеется, чтобы использовать все те фичи, что не доступны на x86Pathoswithin wrote: Нет. Зачем?
И ещё один вопрос: А какие-либо привилегии для этих системных вызовов требуются со стороны приложений? Или любое приложение может хоть где пиксели ставить на экране или, например, хард форматнуть?
niemand
1) на большинстве платформ дремучая GUI Колибри в доисторическом VESA-режиме работает быстрее, чем WinGUI с аппаратной акселерацией.
И безусловно быстрее, чем в Иксах.
Но - да, Вы правы, частое переключение контекста задач действительно сильно тормозит систему.
Мы над этим работаем.
Результат Вас очень сильно удивит, и уже скоро.
2+) стек у каждого приложения свой. Юзер заказывает себе нужный размер стека в заголовке программы.
6) поддержка Huge-страниц в ядре имеется. Там, где она реально необходима: ядерное пространство и графический фреймбуфер, а также PCIe-пространство (в А-версии).
Ни одно из пользовательских приложений пока еще не ожирело до такого безобразия, чтобы требовать себе 4Мб страниц.
7) SSE планируется использовать для оптимизации пересылки/распаковки больших блоков памяти (как насчет эффективности memcpy() в Линуксе, а?),
и еще для оптимизации графической подсистемы (отмена жутко неэффективной байт-на-пиксельной оконной карты).
8 ) с 64-битной версией когда-то игрался Serge, спроси у него. Была даже сумасшедшая идея замутить "гибридную" систему, в которой 32-битное ядро могло бы запускать 64-битные приложения на отдельной голове процессора.
А насчет "почему так?" много лет назад хорошо ответил crazy diamond: "КолибриОС позиционируется не только как очень быстрая, но и как очень маленькая система".
Перепиши весь код (который реально умещается в пару мегабайт + фреймбуфер) на 64 бита - и система раздуется даже не вдвое, а втрое.
При нулевом приросте в скорости.
1) на большинстве платформ дремучая GUI Колибри в доисторическом VESA-режиме работает быстрее, чем WinGUI с аппаратной акселерацией.
И безусловно быстрее, чем в Иксах.
Но - да, Вы правы, частое переключение контекста задач действительно сильно тормозит систему.
Мы над этим работаем.
Результат Вас очень сильно удивит, и уже скоро.
2+) стек у каждого приложения свой. Юзер заказывает себе нужный размер стека в заголовке программы.
6) поддержка Huge-страниц в ядре имеется. Там, где она реально необходима: ядерное пространство и графический фреймбуфер, а также PCIe-пространство (в А-версии).
Ни одно из пользовательских приложений пока еще не ожирело до такого безобразия, чтобы требовать себе 4Мб страниц.
7) SSE планируется использовать для оптимизации пересылки/распаковки больших блоков памяти (как насчет эффективности memcpy() в Линуксе, а?),
и еще для оптимизации графической подсистемы (отмена жутко неэффективной байт-на-пиксельной оконной карты).
8 ) с 64-битной версией когда-то игрался Serge, спроси у него. Была даже сумасшедшая идея замутить "гибридную" систему, в которой 32-битное ядро могло бы запускать 64-битные приложения на отдельной голове процессора.
А насчет "почему так?" много лет назад хорошо ответил crazy diamond: "КолибриОС позиционируется не только как очень быстрая, но и как очень маленькая система".
Перепиши весь код (который реально умещается в пару мегабайт + фреймбуфер) на 64 бита - и система раздуется даже не вдвое, а втрое.
При нулевом приросте в скорости.
niemand
1.Системной библиотеки нет, но есть разные библиотеки, реализующие элементы GUI.
1.1 Любая программа при желании программиста может рисовать всё в битмап и выводить его за один вызов ядра или воспользоваться аппаратной поддержкой при счастливом стечении обстоятельств.
2. Загрузка COFF библиотек -- функция ядра, библиотеки разделяемые. Newlib грузит библиотеки в формате PE DLL, но без разделения памяти.
6)Для ядра минимальные необходимый набор - выделение выделение виртуальной и физической памяти, маппинг страниц и т.п. Для юзерспейса усечённая версия mmap.
7)SSE и переключение контекста fpu/mmx/xmm поддерживается уже лет 9.
1.Системной библиотеки нет, но есть разные библиотеки, реализующие элементы GUI.
1.1 Любая программа при желании программиста может рисовать всё в битмап и выводить его за один вызов ядра или воспользоваться аппаратной поддержкой при счастливом стечении обстоятельств.
2. Загрузка COFF библиотек -- функция ядра, библиотеки разделяемые. Newlib грузит библиотеки в формате PE DLL, но без разделения памяти.
6)Для ядра минимальные необходимый набор - выделение выделение виртуальной и физической памяти, маппинг страниц и т.п. Для юзерспейса усечённая версия mmap.
7)SSE и переключение контекста fpu/mmx/xmm поддерживается уже лет 9.
Спасибо всем за ответы
Здравствуйте!
У меня такой вопрос. Где посмотреть исходники к функций API SysFn00/ru и тд.?
У меня такой вопрос. Где посмотреть исходники к функций API SysFn00/ru и тд.?
В файле window.inc: http://websvn.kolibrios.org/filedetails ... window.incpgb wrote:У меня такой вопрос. Где посмотреть исходники к функций API SysFn00/ru и тд.?
начиная со строки 34. Другие системные функции могут быть в других файлах.
А что Вы имели в виду говоря, что
? Вы как-то перерабатываете GUI?art_zh wrote:Мы над этим работаем.
Результат Вас очень сильно удивит, и уже скоро.
mkostoevr, как по мне, то речь была про
art_zh wrote:Вы правы, частое переключение контекста задач действительно сильно тормозит систему.
Мы над этим работаем.
Who is online
Users browsing this forum: No registered users and 3 guests