Пара технических вопросов о вашей ОС

Applications development, KoOS API questions
  • 1) В любой ОС системные библиотеки являются оболочками над вызовами с переключением контекста. В windows vista (и её родственниках) постарались перенести в юзерспейс всё что можно, из-за чего они стали дико тормозить. В любом случае, 1000 тактов на вызов — это мелочи, другие ОС умудряются тупо просрать гораздо больше.

    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.
    "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
  • Pathoswithin wrote:1) В любой ОС системные библиотеки являются оболочками над вызовами с переключением контекста.
    Юзерспейс не обязательно должен контактировать к кернелспейсом только системными вызовами. Есть ещё общая память хотя бы. Тот же ввод/вывод с помощью fprintf() не дёргает write на каждый чих, а использует буфферизацию. Те же мьютексы из pthread в большинстве POSIX-совместимых ОС вызывают ядро только когда надо спать, а для доступа к мьютексу используют атомарные операции. Примеров куча, когда системный вызов откладывается как можно дальше.
    Pathoswithin wrote: В windows vista (и её родственниках) постарались перенести в юзерспейс всё что можно, из-за чего они стали дико тормозить. В любом случае, 1000 тактов на вызов — это мелочи, другие ОС умудряются тупо просрать гораздо больше.
    Исполнение в пространстве ядра ещё не гарантия какой-либо быстроты. Быстрота -- это сведение к минимуму переключения контекстов, так что можно быстро работать и в юзерспейсе, железо ведь то же самое. Пока у вас программы простые и маленькие -- эти переключения ещё терпимы, но как только они станут большими и замысловатыми (хотя бы как firefox, например), дикое количество переключений и сопутствующие промахи в кеше просто убьют все другие преимущества, так мне кажется
    Pathoswithin wrote: 2) Menuet01, библиотеки COFF, ждём РЕ.
    Здорово! Кстати, появился вопрос по поводу исходников. У вас в любой программе из исходников SVN (возьмем для примера programs/demos/fire/trunck/fire.asm) нет даже намёка на стек. Нет ни call (есть какой-то mcall, но я не знаю, что это), ни регистров %esp/%ebp. Вы не используете стек в своих программах O_o? Или просто это всё сильно замаскированно? (Я не знаю этого диалекта ассемблера). Ядро создаёт стек в адресном пространстве для нового процесса? А куча с аналогами malloc()/free() есть? А вы придерживаетесь SystemV x86(-64) ABI в плане вызова функций, или у вас свои соглашения?
    Pathoswithin wrote: 7) К ОС отношения не имеет. Не использует.
    Имеет прямое отношение. Если регистры xmm0-xmm15 и контрольный регистр mxcsr не сохранять при переключении контекста, то SSE инструкции станет абсолютно невозможно использовать.
    Pathoswithin wrote:8) Нет. Зачем?
    Разумеется, чтобы использовать все те фичи, что не доступны на x86

    И ещё один вопрос: А какие-либо привилегии для этих системных вызовов требуются со стороны приложений? Или любое приложение может хоть где пиксели ставить на экране или, например, хард форматнуть?
  • niemand
    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.
  • Спасибо всем за ответы
  • Здравствуйте!
    У меня такой вопрос. Где посмотреть исходники к функций API SysFn00/ru и тд.?
  • pgb wrote:У меня такой вопрос. Где посмотреть исходники к функций API SysFn00/ru и тд.?
    В файле window.inc: http://websvn.kolibrios.org/filedetails ... window.inc
    начиная со строки 34. Другие системные функции могут быть в других файлах.
  • А что Вы имели в виду говоря, что
    art_zh wrote:Мы над этим работаем.
    Результат Вас очень сильно удивит, и уже скоро.
    ? Вы как-то перерабатываете GUI?
  • mkostoevr, как по мне, то речь была про
    art_zh wrote:Вы правы, частое переключение контекста задач действительно сильно тормозит систему.
    Мы над этим работаем.
  • Who is online

    Users browsing this forum: No registered users and 3 guests