<?xml version='1.0' encoding="utf-8"?>
      <rss version='2.0'>
      <channel>
      <title>Форум на Исходниках.RU</title>
      <link>https://forum.sources.ru</link>
      <description>Форум на Исходниках.RU</description>
      <generator>Форум на Исходниках.RU</generator>
  	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34417</guid>
        <pubDate>Fri, 24 Oct 2003 20:35:49 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34417</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Без глобальной переменной, хранящей описатель текущей задачи (потока), никак не обойтись. Иначе нельзя (или трудно) определить, какой поток прерван.</div></div><br>Это естественно. Глобальные переменными будут и списки задач, драйверов и т.п. Но они используются во многих частях системы. Но если переменная используется только одной функцией, лучше ее не выделять.<br>]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34414</guid>
        <pubDate>Fri, 24 Oct 2003 20:32:03 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34414</link>
        <description><![CDATA[rcz: В данном случае выразите Вашу мысль правильно. Иначе это скорее воспринимается как наезд.<br><br>Хотя здесь более приветствуются дельные советы.]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34411</guid>
        <pubDate>Fri, 24 Oct 2003 19:03:37 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34411</link>
        <description><![CDATA[хбз: ...приношу извинения за некорректный тон...]]></description>
        <author>хбз</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34408</guid>
        <pubDate>Fri, 24 Oct 2003 13:26:30 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34408</link>
        <description><![CDATA[хбз: и откуда ты такой взялся, разработчик концептуально новой ОС? ::)]]></description>
        <author>хбз</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34405</guid>
        <pubDate>Fri, 24 Oct 2003 13:04:29 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34405</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 23.10.03, 23:17:55</span><div class='quote '>Можно. Только компилятор надо подобрать. </div></div><br>А что, бывают компиляторы, которые не поддерживают ++?..<br>Но вообще, это не проблема. Может, в ядре классы совсем не понадобятся. Хуже не отсутствие класов, а отсутствие блоков и необходимость описывать переменные сразу.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>А виртуальность - вручную поддерживать vtbl.</div></div><br>Уж виртуальность в ядре точно не нужна.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>(Как нехочется вдаваться в обсуждения стиля программирования, ..).</div></div><br>Особенно, если учесть, кто начал.. ;)<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Но у нас получается, что время потребности в переменной ограничивается одной функцией(обработчиком исключения), поэтому не стоит засорять данные ядра. Можно передавать как параметр(это архитектурно ничего не нарушит).<br></div></div><br>Без глобальной переменной, хранящей описатель текущей задачи (потока), никак не обойтись. Иначе нельзя (или трудно) определить, какой поток прерван.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34402</guid>
        <pubDate>Thu, 23 Oct 2003 19:17:55 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34402</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>А вдруг они в последующих моделях решат увеличить число прерываний - ведь возможных селекторов 4096...</div></div><br>Пока возможных селекторов в IDT только 256.<br>Но дело не в увеличении самим Интеллом, а перенос на другие платформы.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Кстати, если без виртуальных методов (а также конструкторов с деструкторами), то классы в ядре использовать, наверное, можно?</div></div><br>Можно. Только компилятор надо подобрать. <br>Хотя даже в чистом С. Ведь можно сразу определить стиль вызовов - первый параметр - указатель на объект (this).<br>А виртуальность - вручную поддерживать vtbl.<br><br>(Где-то видел линк, как ядро можно писать на C++. Найду, кину сюда). Хотя в микроядре навероно это не необходимо. <br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Вообще, на каждое правило есть исключения. <br>По поводу goto, правда, таких исключений не знаю (разве что есть случаи, когда goto не режет глаз - но все равно не предпочтительнее).</div></div><br>Выход из кучи вложенных циклов. (Как нехочется вдаваться в обсуждения стиля программирования, тем более для ядра это не самое главное).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>А в plain-C глобальные переменные чаще всего оправданы (в разумных пределах).</div></div><br>Да. Но у нас получается, что время потребности в переменной ограничивается одной функцией(обработчиком исключения), поэтому не стоит засорять данные ядра. Можно передавать как параметр(это архитектурно ничего не нарушит).<br>]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34398</guid>
        <pubDate>Thu, 23 Oct 2003 16:40:13 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34398</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 22.10.03, 23:46:28</span><div class='quote '><br>В x86  - 256</div></div><br>А вдруг они в последующих моделях решат увеличить число прерываний - ведь возможных селекторов 4096...<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>А зачем приложениям предоставлять возможность создавать свои прерывания? Не вижу в этом необходимости.</div></div><br>Необходимости я тоже не вижу. ..Но и &quot;не жалко&quot;.<br>А вдруг в новый процессор добавят еще прерываний (аппаратных или исключений)?<br><br>На самом деле, вопрос не принципиальный - пусть будет как угодно (напр., статические обработчики), я не настаиваю.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Но это плохо:) В дет.саду учат, что использование глобальных переменных плохо (как впрочем и goto) :)</div></div><br>В там еще учат, что дорогу на красный свет переходить нехорошо ;) ..и вообще много чем запрещают заниматься..<br><br>Вообще, на каждое правило есть исключения.<br>По поводу goto, правда, таких исключений не знаю (разве что есть случаи, когда goto не режет глаз - но все равно не предпочтительнее).<br><br>А насчет глобальных переменных - чем по-вашему являются поля класса с точки зрения его методов? Для методов класса его переменные-члены выглядят глобальными.<br><br>Поэтому в ООП глобальные переменные действительно почти никогда не нужны.<br>А в plain-C глобальные переменные чаще всего оправданы (в разумных пределах).<br><br>Кстати, если без виртуальных методов (а также конструкторов с деструкторами), то классы в ядре использовать, наверное, можно?<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>В этом все и дело. Постобработка работает с запрещенными прерываниями. И усложнение ее очень все затормозит.</div></div><br>Сначала нужно сделать упрощенную (демо) версию, где с этой проблемой не связываться. Пусть пока тормозит.<br>Сразу все не осилить.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>И еще надо учесть, что получается сложная схема взаимосвязей, вложенности вызовов задач(а на занятую задачу переключиться нельзя), разрешение которых мне пока не кажется простой задачей.</div></div><br>Поэтому сначала стоит сделать простейший вариант.<br>А сложных взаимодействий и вложенных вызовов задач, уверен, вообще удастся избежать и в полном варианте.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34396</guid>
        <pubDate>Wed, 22 Oct 2003 19:46:28 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34396</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Ведь прерываний теоретически может быть до 2^12=4096 (или меньше?). Если так, то придется сразу выделить на обработчики около 100кб.</div></div><br>В x86 &nbsp;- 256 (на других платформах не знаю). Итого памяти займет около 4096 (+TSS_size*(used_ints+1_for_all_unused) ).<br>Но если учесть, что в системе будут обязательны обработчики исключуний (32), IRQ (16), и syscall (1-3 &nbsp;(больше 1 - на всякий)), не так уж и много памяти занято, тем более т.к. они обязательны, они в любом случае будут выделены.<br>А зачем приложениям предоставлять возможность создавать свои прерывания? Не вижу в этом необходимости.<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Правда получится модификация кода, что считается нехорошо (хотя используя модификацию кода я как-то реализовал очень быструю и компактную процедуру отрисовки линии - так что вещь иногда полезная).</div></div><br>Кто считает, что это нехорошо ? Это всегда очень красиво! Я не против нее.<br>Но здесь с модификацией кода могут быть проблемы: придется временно включать разрешение на записть в страницы ядра,+ искать место, куда поместить эти обработчики. (А если предполагается, что выделение из Хипа, то на такой код придется выделять сразу страницу. Т.к. надо потом запретить туда записть).<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Потом, когда все обработчики без параметров - это единообразие.</div></div><br>Это хорошо.<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Можно в предобработке переносить код ошибки в глобальный параметр и очищать стек сразу.</div></div><br>Но это плохо:) В дет.саду учат, что использование глобальных переменных плохо (как впрочем и goto) :)<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Это мне кажется более безопасным, чем когда С-функция будет брать параметр из стека - нужно будет следить за согласованностью форматов.</div></div><br>В ядре будет только одна согласованность. Если пишем на С, то получится cdecl, стеком занимается вызывающий. А несогласованность идет только в исключениях, которыми заниматься будет ядро.<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Видимо нужно предусмотреть в ядре не только режим обработки прерываний, но и режим &quot;обслуживания&quot;, который имеет отдельный стек и может прерываться. При этом можно обойтись и без задачного переключения (все можно свести к усложнению постобработки). </div></div><br>В этом все и дело. Постобработка работает с запрещенными прерываниями. И усложнение ее очень все затормозит.<br>Но т.к. из за такого способа переключения задач (по прерыванию), мы не можем разрешить их. В итоге приходим, что этот режим &quot;обслуживания&quot; (он в любом случае будит), должен находится в отдельной задаче. Там скорее всего будет находится бесконецный цикл, принимающий новые сообщения, и отправляющий их и переключение потоков (на низком уровне - пользовательских задач).<br><br><br>И еще надо учесть, что получается сложная схема взаимосвязей, вложенности вызовов задач(а на занятую задачу переключиться нельзя), разрешение которых мне пока не кажется простой задачей.]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34393</guid>
        <pubDate>Wed, 22 Oct 2003 17:20:59 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34393</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 22.10.03, 16:06:56</span><div class='quote '><br>В этом я вижу только один недостаток (наверно поэтому так не делают). Нельзя внутри обработчика разрашить прерывания. (Хотя у нас это микроядро и обработчики ничем кроме отсылки сообщений не занимаются). &nbsp;Но задачи ядра(выполняются ведь в прерываниях) - &nbsp;Определение какая задача будет выполняться следующей, доставка сообщения и т.п. &nbsp;- &nbsp;могут занять время и следовательно время отклика всей системы увеличится.<br>Хотя это можно выкинуть в отдельную задачу ядра, переключение из прерывания будет идти в эту задачу. Она определяет следующий Current_TSS. И как-то (как? отдельное прерывание ?) переключается.</div></div><br>Этот вопрос технический и заведомо решаемый.<br>Видимо нужно предусмотреть в ядре не только режим обработки прерываний, но и режим &quot;обслуживания&quot;, который имеет отдельный стек и может прерываться. При этом можно обойтись и без задачного переключения (все можно свести к усложнению постобработки).<br>Но в эти сложности сейчас предлагаю не погружаться, а первую версию делать без гарантий на время реакции (но если пользоваться простым алгоритмом планирования и ограничить размер сообщений, то время реакции будет ограниченным).<br>Все равно сразу все сделать хорошо невозможно, и придется писать не одну версию - потом и можно усовершенствовать.<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>И тогда еще задействовать и постобработку. Исключения с кодом ошибки кидают в стек код ошибки. Его надо после очищать.<br></div></div><br>Можно в предобработке переносить код ошибки в глобальный параметр и очищать стек сразу.<br>Это мне кажется более безопасным, чем когда С-функция будет брать параметр из стека - нужно будет следить за согласованностью форматов.<br>Потом, когда все обработчики без параметров - это единообразие.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>Клонировать точно придется. Только считаю, что не динамически. Лучше сразу вшить в ядро. (Макросы АСМа помогут)</div></div><br>А стоит ли?<br>Ведь прерываний теоретически может быть до 2^12=4096 (или меньше?). Если так, то придется сразу выделить на обработчики около 100кб.<br>С другой строны, реально используется прерываний гораздо меньше. Поэтому динамическая генерация обработчиков будет экономнее.<br>Правда получится модификация кода, что считается нехорошо (хотя используя модификацию кода я как-то реализовал очень быструю и компактную процедуру отрисовки линии - так что вещь иногда полезная).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Но если маленький код, то зачем выносить? <br>И выносить получается надо только тот код обработки прерывания.</div></div><br>Если встроенный ассемблер достаточно хорош, что можно и не выносить.<br>]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34389</guid>
        <pubDate>Wed, 22 Oct 2003 12:06:56 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34389</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Да. Это некоторая потеря в эффективности (но ведь небольшая ? - оба контекста будут в кэше), зато очень большое упрощение.</div></div><br>Потеря в эффективности небольшая (Загрузка TSS вроде занимает 80-100 тактов, точно не помню), но в любом случае обработчик должен сохранять регистры. Так что это по эффективности сравнимо.<br><br>В этом я вижу только один недостаток (наверно поэтому так не делают). Нельзя внутри обработчика разрашить прерывания. (Хотя у нас это микроядро и обработчики ничем кроме отсылки сообщений не занимаются).  Но задачи ядра(выполняются ведь в прерываниях) -  Определение какая задача будет выполняться следующей, доставка сообщения и т.п.  -  могут занять время и следовательно время отклика всей системы увеличится.<br>Хотя это можно выкинуть в отдельную задачу ядра, переключение из прерывания будет идти в эту задачу. Она определяет следующий Current_TSS. И как-то (как? отдельное прерывание ?) переключается.<br><br>Хотя как недостаток(некритический) еще можно считать и выделение TSS на каждое прерывания (трата памяти).<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Наверное, все различия можно перенести на этап предобработки.</div></div><br>И тогда еще задействовать и постобработку. Исключения с кодом ошибки кидают в стек код ошибки. Его надо после очищать.<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Так этот код как раз и придется клонировать на каждое прерывание. <br>Ведь если на все прерывания сделать один предобработчик, то в нем не получится узнать номер прерывания?</div></div><br>Клонировать точно придется. Только считаю, что не динамически. Лучше сразу вшить в ядро. (Макросы АСМа помогут)<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>И асемблерных вставок в С лучше обойтись только обращениями к портам - остальное вынести в отдельный асемблерный блок (пока из двух функций, но вероятно что-то еще добавится для обработки исключений).</div></div><br>Но если маленький код, то зачем выносить? <br>И выносить получается надо только тот код обработки прерывания.]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34386</guid>
        <pubDate>Wed, 22 Oct 2003 11:26:32 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34386</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 22.10.03, 01:07:51</span><div class='quote '><br>А вторая это что?</div></div><br>Код пред-постобработки.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>А стоит ли так строго разделять по языкам.<br>Точнее получится так:<br> - все архитектурно зависимое (что нельзя выполнить н ЯВУ) или модуль асма. Или асм вставка. (тут будет &quot;код пред- и постобработки прерывания&quot;)</div></div><br>Вот две функции и нельзя сделать на ЯВУ - остальное, вроде, можно.<br>На С также присутствует архитектурно-зависимая часть - это таблицы всех дескрипторов. <br>И асемблерных вставок в С лучше обойтись только обращениями к портам - остальное вынести в отдельный асемблерный блок (пока из двух функций, но вероятно что-то еще добавится для обработки исключений).<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Точнее только таймер, и временный жесткий диск(или флоп). (ну и прерывание для syscall'a)<br>По идее далее должны загружаться драйвера и они захватят все остальное.</div></div><br>Все равно предобработка всех прерываний делается ядром, поэтому можно предобработчики поставить сразу - но это несущественный момент, можно и потом.<br>Кстати, ядро видимо должно всегда частично обрабатывать клавиатуру - для отслеживания комбинации перехода в системный монитор (диспетчер задач).<br> <br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Для обязательный прерываний (исключения, IRQ, syscall) можно сделать статическим. Без копирования(копирование кода не очень хорошо. Появится ограничение на использование относительной адресации). <br>будет что-то вроде.<br>Для IRQ.<br>   intrruptN<br>   pushad<br>   push N<br>   call _CommonInterruptHandler<br>   add esp,4<br>   popad<br>   iret<br></div></div><br>Так этот код как раз и придется клонировать на каждое прерывание.<br>Ведь если на все прерывания сделать один предобработчик, то в нем не получится узнать номер прерывания?<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Для исключений по-другому. Там надо учитывать, что некоторые идут с кодом ошибки, а некоторые без. Тут другой способ обработки.</div></div><br>Наверное, все различия можно перенести на этап предобработки.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>А set_interrupt_handler инициализирует только IDT.<br>..И их можно реализовать и на C. Без ASMа.</div></div><br>Подключить обработчик можно и из С - но для этого нужно раздобыть клон ассемблерного кода предобработки (причем модифицированный).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Здесь имеется в виду переключение на новую задачу?<br>И нужно ли такое делать для syscall'a?</div></div><br>А какая разница - на новую задачу, или на ту, из которой был вызов. Технически это одно и то же.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Прерывания будут шлюзами задач, чтоб переключались контексты при входе в ядро?</div></div><br>Да. Это некоторая потеря в эффективности (но ведь небольшая ? - оба контекста будут в кэше), зато очень большое упрощение.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Селектор current_TSS будет один и тот же, чтоб не было ограничений на количество задач. Изменяется сам дескриптор в GDT (изменяется база на TSS новой задачи)).<br></div></div><br>Да, пожалуй.<br>]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34383</guid>
        <pubDate>Tue, 21 Oct 2003 21:07:51 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34383</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>- ассемблерное наноядро (из двух функций)</div></div><br>А вторая это что?<br><br>А стоит ли так строго разделять по языкам.<br>Точнее получится так:<br> - все архитектурно зависимое (что нельзя выполнить н ЯВУ) или модуль асма. Или асм вставка. (тут будет &quot;код пред- и постобработки прерывания&quot;)<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>При инициализации устанавливаются обработчики значительной части прерываний и всех исключений.</div></div><br>Точнее только таймер, и временный жесткий диск(или флоп). (ну и прерывание для syscall'a)<br><br>По идее далее должны загружаться драйвера и они захватят все остальное.<br> <br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Функция set_interrupt_handler прописывает (клонирует) код пред- и постобработки прерывания, а внутри этого кода вызывается обработчик из ядра. </div></div><br>Для обязательный прерываний (исключения, IRQ, syscall) можно сделать статическим. Без копирования(копирование кода не очень хорошо. Появится ограничение на использование относительной адресации). <br><br>будет что-то вроде.<br>Для IRQ.<br> &nbsp; intrruptN<br> &nbsp; pushad<br> &nbsp; push N<br> &nbsp; call _CommonInterruptHandler<br> &nbsp; add esp,4<br> &nbsp; popad<br> &nbsp; iret<br><br>void (*intrFuncs)() [0x10]; &nbsp;// Обработчики - IRQ. <br>void CommonInterruptHandler (DWORD N)<br>{ <br> &nbsp;&lt;pre-code&gt;<br> &nbsp;if(intrFuncs[N]!=NULL) //Есть ли у нас его обработчик?<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;intrFuncs[N]();<br> &nbsp;&lt;post-code&gt;<br>}<br><br><br>set_IRQ_handler(Int N, handler)<br>{ ..<br> &nbsp; &nbsp;//всякие проверки на занятость.<br> &nbsp; &nbsp;intrFuncs[N]=handler;<br> &nbsp; ..<br>}<br>Для исключений по-другому. Там надо учитывать, что некоторые идут с кодом ошибки, а некоторые без. Тут другой способ обработки.<br><br><br>А set_interrupt_handler инициализирует только IDT.<br>Ну так же надо по аналогии ввести функцию set_gdt_entry. И их можно реализовать и на C. Без ASMа.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Код постобработки полностью очищает стек, помещает в него селектор current_TSS и делает iret.</div></div><br>Здесь имеется в виду переключение на новую задачу?<br>И нужно ли такое делать для syscall'a?<br>Прерывания будут шлюзами задач, чтоб переключались контексты при входе в ядро?<br>(стек в этом случае, вроде, не надо очищать. Селектор current_TSS будет один и тот же, чтоб не было ограничений на количество задач. Изменяется сам дескриптор в GDT (изменяется база на TSS новой задачи)).<br>]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34380</guid>
        <pubDate>Tue, 21 Oct 2003 19:19:05 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34380</link>
        <description><![CDATA[nvm: Спасибо за информацию.<br><br>В техническом плане, структура ядра вырисовывается.<br><br>Общая структура:<br>- ассемблерное наноядро (из двух функций),<br>- ядро на С, состоящее из функции main и функций - обработчиков прерываний.<br><br>Работа наноядра.<br>Интерфейс:<br>- функция set_interrupt_handler,<br>- глобальная переменная current_TSS,<br>- глобальная переменная current_interrupt.<br><br>Сценарий работы.<br>Загрузчик запускает main, которая выполняет инициализацию и завершается.<br>При инициализации устанавливаются обработчики значительной части прерываний и всех исключений.<br>Функция set_interrupt_handler прописывает (клонирует) код пред- и постобработки прерывания, а внутри этого кода вызывается обработчик из ядра.<br>Обработчик прерываний (в-частности обработчик таймера) перед выходом может установить в current_TSS другую задачу.<br>Код постобработки полностью очищает стек, помещает в него селектор current_TSS и делает iret.<br>Весь код ядра выполняется с флагом запрещения всех прерываний (NMA запрещается раньше). Внутри ядра (С-части) все вызовы функций - near.<br>Вся деятельность ядра осуществляется в обработчиках прерываний (main служит только инициализации).]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34378</guid>
        <pubDate>Tue, 21 Oct 2003 07:18:20 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34378</link>
        <description><![CDATA[справочная: ftp://ftp.tsu.ru/pub/techdocs/Architecture/INTEL/IA32/24319201.PDF<br><strong class='tag-b'>5.10.1.2 FLAG USAGE BY EXCEPTION- OR INTERRUPT-HANDLER PROCEDURE</strong><br><em class='tag-i'>второй абзац:</em><br><br>The only difference between an interrupt gate and a trap gate is the way the processor handles the IF flag in the EFLAGS register. When accessing an exception- or interrupt-handling procedure through an interrupt gate, the processor clears the IF flag to prevents other interrupts from interfering with the current interrupt handler. A subsequent IRET instruction restores the IF flag to its value in the saved contents of the EFLAGS register on the stack. Accessing a handler procedure through a trap gate does not affect the IF flag.<br><br>Несколько слов о защите флага IF.<br><br>В случае IRET и POPF, флаг IF будет восстанавливаться только если CPL&lt;=IOPL.<br>Если CPL&gt;IOPL, то флаг IF не изменяется.<br><br>В случае CLI и STI, будет возникать #GP, если CPL&gt;IOPL.<br><br>В V86 mode, CPL=3<br><br>см. также:<br><strong class='tag-b'>5.5 NONMASKABLE INTERRUPT (NMI)</strong><br><br>В семействе PC/AT до сих пор есть одно NMI для обработки сбоя в электропитании. При инициализации системы, его желательно запретить.<br>ftp://ftp.tsu.ru/pub/techdocs/Hardware/Intel/Chipset/Ports/PORTS.TXT<br><em class='tag-i'>строка 768:</em><br><br>The AT and PS/2 uses port 70H bit 7 to disable 'Non-Maskable' Interrupts (NMI) by setting bit 7 to 0. &nbsp;Enable NMI by setting bit 7 to 1. Note: the PCs use port 0A0H for this purpose. Port 70H on ATs is also used to set a CMOS register index (00-3FH), which is then read from port 71H.]]></description>
        <author>справочная</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34374</guid>
        <pubDate>Mon, 20 Oct 2003 17:39:48 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34374</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Кто-нибудь знает такой момент: если в обработчике прерывания первой инструкцией стоит cli, то может ли теоретически так случиться, что эта инструкция еще не успеет выполниться, а обработчик будет прерван еще одним прерыванием ?</div></div><br>нет. Вызов прерывания очищает флаг прерывания(их запрещает). Т.е cli не нужен<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Также симметричный вопрос: если sti - последняя команда в обработчике прерывания, то может ли получиться, что новое прерывание произойдет до iret ?</div></div><br>может.<br>Но iret ведь из стека выталкивает регистр флагов и этим сама неявно делает sti.<br><br>о cli из Intel Architecture Software Developer’s Manual Vol ume 2 :Instruction Set Reference<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Clears the IF flag in the EFLAGS register. No other flags are affected. Clearing the IF flag causes<br>the processor to ignore maskable external interrupts. The IF flag and the CLI and STI instruction<br>have no affect on the generation of exceptions and NMI interrupts.</div></div><br><br>]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34371</guid>
        <pubDate>Mon, 20 Oct 2003 17:12:45 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34371</link>
        <description><![CDATA[nvm: Кто-нибудь знает такой момент: если в обработчике прерывания первой инструкцией стоит cli, то может ли теоретически так случиться, что эта инструкция еще не успеет выполниться, а обработчик будет прерван еще одним прерыванием ?<br>Также симметричный вопрос: если sti - последняя команда в обработчике прерывания, то может ли получиться, что новое прерывание произойдет до iret ?<br><br>И еще забыл одну вещь (изучал 12 лет назад и сейчас не вспомню): команда cli запрещает немаскируемые прерывания (и используются ли они вообще в современных процессорах) ?]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34369</guid>
        <pubDate>Wed, 15 Oct 2003 14:38:21 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34369</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 15.10.03, 13:44:56</span><div class='quote '>Поэтому это (А в том, что я предлагаю, его обработка начнется немедленно.)<br>немного ложь.</div></div><br>Так можно договориться, что и обычный вызов функции происходит с задержкой, так как может случиться, что в момент вызова квант времени закончится, и придется ждать следующего.<br>Поэтому переформулирую:<br>форма RunMessage гарантирует, что обработка сообщения начнется тогда же, как если бы отправитель делал функциональный вызов.<br>Собственно, это и означает &quot;немедленно&quot;, в наиболее естественном смысле этого слова.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Итак. При каждом сообщении будет создаваться поток. Но стек резервируется не ядром. Будет отложенное создание потоков.<br>Так же не согласен с ..<br></div></div><br>В общем, понятно, что к одному мнению не прийти - аргументы высказаны, остались личные предпочтения.<br>Есть смысл перейти пока к базовой технической части, которая не зависит от конкретики ОС. <br>Это библиотека внутренних функций ядра.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34366</guid>
        <pubDate>Wed, 15 Oct 2003 09:44:56 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34366</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Если придут два real time сообщения, то одному естественно потребуется ждать (не более кванта).</div></div><br>А ведь поэтому не можем гарантировать максимальное время отклика.<br>(Но это уже вопрос философский).<br>Поэтому это<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>А в том, что я предлагаю, его обработка начнется немедленно.</div></div><br>немного ложь.<br><br>Итак. При каждом сообщении будет создаваться поток. Но стек резервируется не ядром. Будет отложенное создание потоков.<br><br>Так же не согласен с <br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Я же 100 раз писал, что для функции выделения памяти адрес - это входной, а не выходной параметр! <br>handle= alloc_mem (stack_addr,stack_size).</div></div><br><br>]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34363</guid>
        <pubDate>Fri, 10 Oct 2003 16:30:17 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34363</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 10.10.03, 15:09:16</span><div class='quote '><br>Писал вариант работы посылки сообщения, (<br>)время отклика там тоже не гарантируется.</div></div><br>???<br>Если придут два real time сообщения, то одному естественно потребуется ждать (не более кванта).<br>..Но я не понял утверждения..<br>Проблемная ситуация такая: объект обрабатывает низкоприоритетное сообщение, а в это время приходит real time.<br>В Вашей схеме оно будет ждать (причем сколь угодно долго) окончания обработки сообщения с низким приоритетом.<br>А в том, что я предлагаю, его обработка начнется немедленно.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Если рассматривать эту систему,  в ней уже нет ОО.<br>Привязать стек к определенному адресу - тоже нарушение.</div></div><br>Где же нарушение?!<br>Стек принадлежит процессу и процесс имеет право привязать его к любому адресу.<br>Вполне нормальная работа объекта со своими внутренними сущностями.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Если родитель передаст в func или локальную структуру, или структуру с указателями на локальные переменные... при фиксировании стека - они потеряются.</div></div><br>Они потеряются только если использовать идею стека &quot;со слоями&quot;. Эта проблема как раз обсуждалась, и сносное решение найдено.<br>А если нет &quot;слоев&quot;, то и проблемы нет в принципе.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>А указание в создании потока размера стека - считай явный запрос .<br>Или по явным Вы подразумеваете.<br>stack_addr = alloc_mem (stack_size)<br>create_thread(func.stack_addr,params);</div></div><br>Я же 100 раз писал, что для функции выделения памяти адрес - это входной, а не выходной параметр!<br>handle= alloc_mem (stack_addr,stack_size).<br>А точнее, на входе у allocate целая структура section, где указываются в том числе и адреса.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Суть у них одна. В одном случае параметры  - размер стека указывается при создании интерфейса. В втором - при явном создании потока.</div></div><br>Проблема в указании не размера, а адреса.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Для оптимизации - лучше syscall, но для сохранение лучшей архитектурной целостности (микроядерность) - через сообщения.<br></div></div><br>syscall в эффективности не выигрывает - действия точно те же.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34360</guid>
        <pubDate>Fri, 10 Oct 2003 11:09:16 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34360</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Значит не будет гарантированного времени отклика (до начала обработки) на сколь угодно срочные сообщения.</div></div><br>Писал вариант работы посылки сообщения, (<div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Приходят 2 сообщения...</div></div>)время отклика там тоже не гарантируется.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>До этого Вы согласились с тезисом 7. <br>А теперь его фактически отвергаете. <br>На самом деле, как раз это есть нарушение инкапсуляции: когда кто-то со стороны (ядро) решает за процесс, где (в адресном пространстве) будет располагаться его стек.</div></div><br>Если рассматривать эту систему, &nbsp;в ней уже нет ОО.<br>Привязать стек к определенному адресу - тоже нарушение. (Разрешить работу с локальными переменными надо).<br><br>Пример <br>func (struct *somestruct){<br> &nbsp; &nbsp; handle thr=create_thread(thr_func,somestruct..);<br> &nbsp; &nbsp; //...some work<br> &nbsp; &nbsp; wait(thr);<br>}<br>Если родитель передаст в func или локальную структуру, или структуру с указателями на локальные переменные... при фиксировании стека - они потеряются. А вызываеющий func &nbsp;вполне может и не знать о создании потока. Т.е. он или должен сам копировать всю структуру в Хип (со всеми полями, разименовыванием указателей. считай сериализация всех объектов), или всем отказаться от стековых переменных и параметров &nbsp;вообще.<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>7. Любое отображение памяти на виртуальное пространства производится только по явному запросу процесса.</div></div><br>А указание в создании потока размера стека - считай явный запрос .<br><br>Или по явным Вы подразумеваете.<br>stack_addr = alloc_mem (stack_size)<br>create_thread(func.stack_addr,params);<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Два способа создания потока заведомо лишнее. <br>Либо create_thread, либо ForkMessage (в том чисте и для создания потока внутри процесса - через отправку сообщения самому себе).</div></div><br>Суть у них одна. В одном случае параметры &nbsp;- размер стека указывается при создании интерфейса. В втором - при явном создании потока.<br><br>Поэтому просто надо решить - делать ли боступным create_thread как syscall <br><br>Для оптимизации - лучше syscall, но для сохранение лучшей архитектурной целостности (микроядерность) - через сообщения.<br>]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34358</guid>
        <pubDate>Fri, 10 Oct 2003 09:47:34 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34358</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 10.10.03, 12:06:27</span><div class='quote '><br>Проблемма в том, какой из них будет выполняться ;)</div></div><br>По-очереди! Согласно стратегии планирования вроцессорного времени.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Значит меня не поняли. Обработчик очередями не занимается.</div></div><br>Значит не будет гарантированного времени отклика (до начала обработки) на сколь угодно срочные сообщения.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>Это как раз не проблема. Дан размер стека. Под него всегда будет вызываться выделение памяти (от лица этого процесса) динамически. фиксировать адрес не надо.<br></div></div><br>До этого Вы согласились с тезисом 7.<br>А теперь его фактически отвергаете.<br>На самом деле, как раз это есть нарушение инкапсуляции: когда кто-то со стороны (ядро) решает за процесс, где (в адресном пространстве) будет располагаться его стек.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>доапустим как создается поток.<br>create_thread (addr,params,stack_size...)<br></div></div><br>Так как с тезисом 10 ?<br>Два способа создания потока заведомо лишнее.<br>Либо create_thread, либо ForkMessage (в том чисте и для создания потока внутри процесса - через отправку сообщения самому себе).]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34355</guid>
        <pubDate>Fri, 10 Oct 2003 08:06:27 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34355</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Нет проблем. В двух параллельных потоках.</div></div><br>Проблемма в том, какой из них будет выполняться ;)<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Единственный способ обеспечить немедленную обработку в Вашей схеме - это если поток обработки будет только сортировать сообщения: для срочных запускать новый поток, несрочные - перемещать в новую очередь.</div></div><br>Значит меня не поняли. Обработчик очередями не занимается.<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Только тут возникает проблема с тем, что на одном интерфейсе может быть много потоков, значит нужно много стеков. И для этих стеков нужно определить адресное пространство.</div></div><br>Это как раз не проблема. Дан размер стека. Под него всегда будет вызываться выделение памяти (от лица этого процесса) динамически. фиксировать адрес не надо.<br><br><br>доапустим как создается поток.<br>create_thread (addr,params,stack_size...)<br><br>Процесс выделяет память (виртуальные страницы ) размером stack_size.<br>стек нового потока устанавливает на эту выделенную память. Туда копирует параметр.<br>Так и в обработке сообщения. Будет известны адрес обработчика, размер стека, а параметр - сообщение.<br>]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34353</guid>
        <pubDate>Thu, 09 Oct 2003 20:53:41 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34353</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 09.10.03, 23:29:35</span><div class='quote '>А еще, кстати, надо рассмотреть такую ситуацию. Приходят 2 сообщения. (у второго приоритет выше). Первое сообщение начинает выполняться, дле него создается поток, с приоритетом выше, чем у потока, отправивешего 2-е сообщение. Значит 2-е сообщение(приоритет будет реалтайм) не начнет выполняться, будет ждать.<br></div></div><br>Если оба потока real time, то оба и запустятся, и между ними будет делиться время.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>А в варианте создания потока для каждого сообщения -  о расположении стека не стоит волноваться.<br>Можно сделать так. При регистрации интерфейса указывается размер стека,адрес функции(ну и доп..инфа.для создания потоков). Неявным образом задается адресное пространство - процесс.<br><br>При появлении сообщения, ядро просто обычный образом создает поток, как это бы делал сам процесс(параметры были переданы при объявлении интерфейса). И передает ему параметры (сообщение). Это получается отложенное создание потока процессом<br></div></div><br>Как базовую схему я это и имел в виду.<br>Только тут возникает проблема с тем, что на одном интерфейсе может быть много потоков, значит нужно много стеков. И для этих стеков нужно определить адресное пространство.<br>Самое примитивное решение: при формировании процесса задавать начало и размер стековой области и размер стека - а при создании потоков для них стеки будут размещаться подряд в стековой области.<br>Но это не очень красивое решение - поэтому я и придумываю как все стеки &quot;посадить&quot; на один адрес.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34350</guid>
        <pubDate>Thu, 09 Oct 2003 20:31:20 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34350</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 09.10.03, 23:29:35</span><div class='quote '>Что ж. Это недостаток. Но тогда скажите как в вашей системе смогут обработаться 2 сообщения приоритета реального времени одновременно?:)</div></div><br>Нет проблем. В двух параллельных потоках.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>В моем случае интерфейс создает сам поток. И задержка обработки более приоритетного сообщения - время создание потока.</div></div><br>Эта задержка невелика и неизбежна.<br>А серьезная задержка будет в том, что придется ждать завершения обработки предыдущего сообщения. А это может быть очень долго.<br>Потому что у вас ядро может лишь обеспечить сообщению первое место в очереди - но прерывать уже начавшуюся обработку предыдущего сообщения оно не может.<br><br>Единственный способ обеспечить немедленную обработку в Вашей схеме - это если поток обработки будет только сортировать сообщения: для срочных запускать новый поток, несрочные - перемещать в новую очередь.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br> Но в моем случае есть возможность сделать,что  интерфейс обрабатывает только один запрос за время (нет задержек на создание потока). </div></div><br>Но я этот вариант тоже включаю.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>P.S. Мое дело предложить вариант. Ваше дело отказаться. Настаивать не буду.</div></div><br>Это как раз не я отказываюсь. Я то предлагаю и Вашу схему в том числе, но вместе с ней еще дополнительную.<br><br>Предлагаю такой компромисс: включить в дизайн оба варианта, но там где сложно ставить &quot;заглушки&quot;.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '> Просто интересно. А Где ?</div></div><br>Ну как где. WM_COPY_DATA. Оно, конечно, косячно, и только в синхронном варианте, и без приоритетов - но по сути то же.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34347</guid>
        <pubDate>Thu, 09 Oct 2003 19:29:35 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34347</link>
        <description><![CDATA[rcz: Ладно.<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Так ведь GetMessage и есть syscall для засыпания потока. <br>А пробуждаясь, он все равно должен получить сообщение, поэтому других специальных функций засыпания и не нужно.</div></div><br>Я хотел избавится от лишнего syscall'a. И этот метод - считай GetMessage, только без явного его использования. А других функций засыпания и не будет.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>По-вашему получается, что любой асинхронный (из другого потока) вызов метода класса является нарушением инкапсуляции.</div></div><br>С чего это взяли? Это вызов метода интерфейса. Асинхронный - это только лишь отсутствие ожидания завершения обработки.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Создание потока извне процесса это не более, чем реализация межзадачного вызова функции.</div></div><br>И является нарушением микроядерной архитектуры. Система обработки сообщений (межзадачный вызов) изначально может ничего не знать о создании потоков (это другой объект, они не связаны). Точнее о деталях создания (стек - очень хорошая деталь)<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Тогда объясните, как Вы сможете гарантировать, что приоритетные сообщения (напр. реального времени) будут обработаны немедленно (не ожидая, пока сервер закончит обработку предыдущего сообщения) ?</div></div><br>Что ж. Это недостаток. Но тогда скажите как в вашей системе смогут обработаться 2 сообщения приоритета реального времени одновременно?:)<br><br>В моем случае интерфейс создает сам поток. И задержка обработки более приоритетного сообщения - время создание потока. Но в моем случае есть возможность сделать,что  интерфейс обрабатывает только один запрос за время (нет задержек на создание потока). <br><br>В Вашем - ядро создает поток, задержка та же.<br><br><br>А еще, кстати, надо рассмотреть такую ситуацию. Приходят 2 сообщения. (у второго приоритет выше). Первое сообщение начинает выполняться, дле него создается поток, с приоритетом выше, чем у потока, отправивешего 2-е сообщение. Значит 2-е сообщение(приоритет будет реалтайм) не начнет выполняться, будет ждать.<br>Эта ситуация грозит в обоих вариантах (правда если делать очередь в ядре, то оно может отсортировать, хотя это не спасет от всех случаев).<br><br>Real-Time не получается.<br><br>P.S. Мое дело предложить вариант. Ваше дело отказаться. Настаивать не буду.<br><br>А в варианте создания потока для каждого сообщения - &nbsp;о расположении стека не стоит волноваться.<br>Можно сделать так. При регистрации интерфейса указывается размер стека,адрес функции(ну и доп..инфа.для создания потоков). Неявным образом задается адресное пространство - процесс.<br><br>Создание потоков - одна функция на системы.<br><br>При появлении сообщения, ядро просто обычный образом создает поток, как это бы делал сам процесс(параметры были переданы при объявлении интерфейса). И передает ему параметры (сообщение). Это получается отложенное создание потока процессом<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>4. Так уже сделано, хоть в тех же виндах.</div></div> Просто интересно. А Где ?]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34344</guid>
        <pubDate>Thu, 09 Oct 2003 17:37:40 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34344</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 09.10.03, 17:37:37</span><div class='quote '>Ну если учесть, что в вашем случае для каждого сообщения надо создавать по потоку </div></div><br>Почему для каждого?! Все зависит от типа сообщения.<br>Разница только в том, что я предлагаю использовать две схемы, а Вы - оставить одну.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>тем более из-вне процесса (нарушение инкапсуляции и т.п.)</div></div><br>По-вашему получается, что любой асинхронный (из другого потока) вызов метода класса является нарушением инкапсуляции.<br><br>Создание потока извне процесса это не более, чем реализация межзадачного вызова функции.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Ну и быстрее простое переключение на новый поток, чем его создание - в случае, что для каждого сооющения ядро создает поток.</div></div><br>Стоимость создания потока примерно равна стоимости выделения одной страницы памяти, что немного.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>А зачем создавать &quot;мимнимум 2 треда и 2 очереди сообщений&quot;. Нужна только 1 очередь со стороны ядра, а тот тред никаких очередей не делает.</div></div><br>Тогда объясните, как Вы сможете гарантировать, что приоритетные сообщения (напр. реального времени) будут обработаны немедленно (не ожидая, пока сервер закончит обработку предыдущего сообщения) ?<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Поток обработчик не вызывает GetMessage, ядро его просто с каждым сообщением пробуждает. </div></div><br>Так ведь GetMessage и есть syscall для засыпания потока.<br>А пробуждаясь, он все равно должен получить сообщение, поэтому других специальных функций засыпания и не нужно.<br>]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34341</guid>
        <pubDate>Thu, 09 Oct 2003 13:37:37 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34341</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>3. Требуется один дополнительный тред и одна дополнительная очередь сообщений. <br>То есть, обработчик будет вынужден создать, как минимум, два треда и две очереди сообщений: одна для приходящих сообщений - а во вторую придется после сортировки копировать асинхронные сообщения, для последующей обработки.</div></div><br><br>Ну если учесть, что в вашем случае для каждого сообщения надо создавать по потоку тем более из-вне процесса (нарушение инкапсуляции и т.п.), то какой-то один поток, тем более спящий, не мешает.<br><br>А если интрефей не поддерживает асинхронности(точнее он не реентерабельный), то обработчик может не создавать поток. Ну и быстрее простое переключение на новый поток, чем его создание - в случае, что для каждого сооющения ядро создает поток.<br><br>А зачем создавать &quot;мимнимум 2 треда и 2 очереди сообщений&quot;. Нужна только 1 очередь со стороны ядра, а тот тред никаких очередей не делает.<br><br>Асинхронные сообщения отправляются как сообщения-отправителю (тот в этих целях может сделать call-back обработчик). <br>По-моему удобно и хоть как-то структурированно. <br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Так уже сделано, хоть в тех же виндах. А при прочих равных интереснее реализовывать то, чего еще не делалось. </div></div><br>Если так подходить к делу, то вообще ничего не реализуешь, потому, что каждая идея была как-то реализована, а если не реализована - то это или плохая идея, или очень сложно реализовать, или эффективность будет ужасная.<br><br>P.S.Сами просили <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Тогда придумайте, как решить запускать новые потоки для обработки сообщений. Такой поток создается не самим приложением, но только само приложение может дать виртуальное пространство новому стеку. </div></div>Я и привел пример системы.<br>]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34338</guid>
        <pubDate>Thu, 09 Oct 2003 12:22:07 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34338</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 09.10.03, 12:01:56</span><div class='quote '>Я не ядро имел в виду. А ожидение завершение выполнения метода интерфейса вызвавшим потоком.</div></div><br>Такой вопрос может возникнуть только если Вы несогласны с предложенными 5-ю типами сообщений (потому что если их принять, то вопрос отпадает: ядро обеспечиывет и синхонные и асинхроггые сообщения). Но если несогласны, сначала скажите в чем.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Данный метод позволяет:<br>...<br>2 - поток создается внутри.<br></div></div><br>С моей точки зрения это вовсе не плюс, а минус. Так как этот способ позволяет лишь приближенно сымитировать функциональный вызов, но не в-точности.<br>..Но этот аргумент я уже приводил - так что по данному вопросу, видимо, каждый останется при своем мнении..<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Асинхронность реализовать можно в самом ядре. При отсылки сообщения обработчику не дожидаться его завершения.</div></div><br>Само собой..<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Минусы:<br>...<br>2 - если учитывать асинхронность на уровне ядра, не придумал унифицированного способа возврата результата. Но не исключаю, что просто реализовать</div></div><br>Для асинхронных сообщений (post) возврат результата и не нужен. Вернее, для ответа просто посылается новое сообщение.<br>Так что это не минус.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Добавьте свои минусы и плюсы к этой системе.</div></div><br>Самый большой минус.<br>3. Требуется один дополнительный тред и одна дополнительная очередь сообщений.<br>То есть, обработчик будет вынужден создать, как минимум, два треда и две очереди сообщений: одна для приходящих сообщений - а во вторую придется после сортировки копировать асинхронные сообщения, для последующей обработки.<br>Если же сообщения, для которых не создается специальный тред, сразу обрабатывать в принимающем потоке, то не обеспечивается оперативность реакции на срочные сообщения (в т.ч. прерывания).<br><br>4. Так уже сделано, хоть в тех же виндах. А при прочих равных интереснее реализовывать то, чего еще не делалось.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34335</guid>
        <pubDate>Thu, 09 Oct 2003 08:01:56 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34335</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Очереди сообщений может и портят архитектуру. Но уж слишком они повышают эффективность..</div></div><br>Вроде я никогда не был против очередей.<br>Просто я считаю, что все надо как-то обобщить, чтоб не рассматривать множество деталей.<br> <br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Ядро все операции исполняет быстро. &nbsp;<br>И даже если б были медленные функции, все равно обращения к ядру стоит делать все синхронными. По крайней мере в первой версии. Потом, если будет видна сильная необходимость (что маловероятно) - пересмотреть.</div></div><br>Я не ядро имел в виду. А ожидение завершение выполнения метода интерфейса вызвавшим потоком.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Тогда придумайте, как решить запускать новые потоки для обработки сообщений. Такой поток создается не самим приложением, но только само приложение может дать виртуальное пространство новому стеку. <br>Эту проблему я и решал усложнением секций стека. <br>Идея в том, что стек может иметь &quot;слои&quot; (как изображение), и для нового потока уже в имеющейся секции создается новый слой. <br>Для передачи указателей на переменные в стеке поток должен отобразить свой стек в новую &quot;неслоистую&quot; секцию и переключить указатель стека на нее. <br> <br>Проблему это решает. Конечно, пришлось ввести новое понятие &quot;слоев&quot;, что минус, но он один. <br>А как бы Вы решали описанную проблему?</div></div><br><br>Я уже писал вариант обработки сообщения. Основанный на очереди и с поддержкой асинхронности.<br><br>Примерно так.<br><br>1)Некий объект регистрирует свой интерфейс, говоря тем, что готов принимать сообщения (удаленные вызовы).<br>Этим он создает поток (как писал с автосбросом) обработчик, он спит.<br><br>2) Приложения, которые хотят вызвать что-то из интерфейса, посылают ему сообщения.<br><br>Эти сообщения ставятся в очередь и передаются этому потоку обработчику.<br>Обработчик волен создавать для каждого сообщения новый поток и возвращать управление.<br>Поток обработчик не вызывает GetMessage, ядро его просто с каждым сообщением пробуждает.<br><br>3) созданный поток (если его не, то сам обработчик) возвращает результат. <br><br>Данный метод позволяет:<br>1 - не мучаться отдельно со стеками<br>2 - поток создается внутри.<br>3 - позволяет инкапсулировать способ обработки сообщений.<br><br>Асинхронность реализовать можно в самом ядре. При отсылки сообщения обработчику не дожидаться его завершения.<br><br>Минусы:<br>1 - реализуется только с очередями.<br>2 - если учитывать асинхронность на уровне ядра, не придумал унифицированного способа возврата результата. Но не исключаю, что просто реализовать<br><br>Добавьте свои минусы и плюсы к этой системе.]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34332</guid>
        <pubDate>Wed, 08 Oct 2003 20:57:53 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34332</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 08.10.03, 22:46:50</span><div class='quote '><br>Реализовать то нетрудно, но употребить. И не испортит ли это архитектуру.<br></div></div><br>Очереди сообщений может и портят архитектуру. Но уж слишком они повышают эффективность..<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Нет. однопроцессорная система. Просто вопрос. Реализовывать ли поддержку асинхронности в ядре. Или пользователь будет для асинхронных вызовов сам создавать потоки.</div></div><br>Ядро все операции исполняет быстро. <br>И даже если б были медленные функции, все равно обращения к ядру стоит делать все синхронными. По крайней мере в первой версии. Потом, если будет видна сильная необходимость (что маловероятно) - пересмотреть.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>НЕТ. Не будем нагромождать поток описанием памяти. Потокам нужен доступ к стеку родителей.(поддержка передачи указателей на стековые данные).<br>И стек - те же VMA, что и остальная память.<br></div></div><br>Тогда придумайте, как решить запускать новые потоки для обработки сообщений. Такой поток создается не самим приложением, но только само приложение может дать виртуальное пространство новому стеку.<br>Эту проблему я и решал усложнением секций стека.<br>Идея в том, что стек может иметь &quot;слои&quot; (как изображение), и для нового потока уже в имеющейся секции создается новый слой.<br>Для передачи указателей на переменные в стеке поток должен отобразить свой стек в новую &quot;неслоистую&quot; секцию и переключить указатель стека на нее.<br><br>Проблему это решает. Конечно, пришлось ввести новое понятие &quot;слоев&quot;, что минус, но он один.<br>А как бы Вы решали описанную проблему?<br>]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34329</guid>
        <pubDate>Wed, 08 Oct 2003 18:46:50 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34329</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Это уже обсуждали: то, что запуск любого числа потоков в некотором процессе нисколько не замедляет остальные процессы.</div></div><br>Можно поэкспеременитирвать. Это не сложно реализуется<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '> 6. Приложение имеет возможность произвольно перекраивать свой виртуальный образ памяти, без всяких ограничений.</div></div><br><br>Да.<br><br><br>7. Да<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>В известных системах как раз и выбрано что-то одно. <br>Очередь не может обеспечить оперативность. <br>Отдельные потоки включают все возможности очереди, но на порядок &quot;дороже в эксплуатации&quot;. <br>Надо бы и то и другое - это довольно нетрудно реализовать.</div></div><br>Реализовать то нетрудно, но употребить. И не испортит ли это архитектуру.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Имеется в виду многопроцессорная архитектура С ней лучше пока не связываться...</div></div><br>Нет. однопроцессорная система. Просто вопрос. Реализовывать ли поддержку асинхронности в ядре. Или пользователь будет для асинхронных вызовов сам создавать потоки.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>12. Секция стека формально одна на процесс, но для каждого потока выделяется отдельная физическая память.</div></div><br>НЕТ. Не будем нагромождать поток описанием памяти. Потокам нужен доступ к стеку родителей.(поддержка передачи указателей на стековые данные).<br>И стек - те же VMA, что и остальная память.<br><br>]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34327</guid>
        <pubDate>Wed, 08 Oct 2003 14:49:44 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34327</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 08.10.03, 13:31:54</span><div class='quote '>Давайте остановимся на подробном обсуждении IPC.<br>1) Отсылка сообщений</div></div><br>Сама отсылка не составляет проблемы - лишь бы решить, сколько их будет типов.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>2) передача параметров</div></div><br>Модель протоколов, как в Интернете.<br>Сообщение имеет стандартный заголовок и облать данных, формат которой (протокол следующего уровня) определяется интерфейсом сервера. Некоторые интерфейсы серверов стандартизуются системой.<br>Технически сообщение при отправке целиком помещается в стек.<br><br>Вообще любой выход процесса &quot;во внешний мир&quot; (даже обращения к системе) производятся единственным образом: в стек помещаем сообщение и делаем syscall (без параметров). В конце сообщения (на вершине стека) лежит его длина, что защищает от ощибок стека.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>3) результат - отправка, получения</div></div><br>Получение сообщений я подробно описывал:<br>&quot;При обработке. <br>Если это первая группа, то создается поток (карта памяти одна на весь просцесс, только стек новый), в стек которого помещается сообщение. Обработчик удалает сообщение и в стек помещает ответ, после чего командует возврат (завершение потока). <br>Сообщений второй группы ядро, без ведома получателя, сразу копирует в его очередь, откуда их получатель может считать после, из любого своего потока. &quot;<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>4) поддержка ядром асинхронных вызовов (нужны ли они в ядре? Как реализовать?)</div></div><br>Имеется в виду многопроцессорная архитектура??? С ней лучше пока не связываться...<br><br>А при одном процессоре просто некому делать такие вызовы (кроме прерываний).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>5) учесть особенности сообщений в прерываниях.<br>Мне не очень нравится, если делать очередью, точнее отдельно вызывать ReсieveMessage. Лучше сделать как вызовы удаленных процедур. <br>Создавая поток на каждое сообщение - трудности с возвратом результата. Это надо продумать.</div></div><br>В пяти предложенных типах сообщений предусмотрены все эти моменты.<br>Прерывания - без особенностей реализуются через ForkMessage.<br>Вызовы удаленных процедур - RunMessage.<br>Возврат результата: если поток отправителя ждал, то ответ он получит тут же в стеке; если отправка была без ожидания - ответ придет отдельным сообщением (типа Post).]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34324</guid>
        <pubDate>Wed, 08 Oct 2003 14:49:28 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34324</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 08.10.03, 13:26:20</span><div class='quote '>4. &nbsp;не до конца понял что имелось в виду.</div></div><br>Это уже обсуждали: то, что запуск любого числа потоков в некотором процессе нисколько не замедляет остальные процессы.<br>..Хотя это можно включить потом, а для начала планировщик можно сделать самым простым.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '> нет. (Или зачем?)</div></div><br>Иначе физически не возможны сообщения в форме вызовов - останутся только с очередью через GetMessage.<br>Это жестко связанные вопросы (5,9,11).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '> 6. Нет. Определяет загрузчик. (А ниже только объект менеджера памяти)</div></div><br>Если &quot;нет&quot;, то и на следующий вопрос &quot;нет&quot;.<br><br>Пожалуй, нужно уточнить вопрос.<br>Разумеется, что приложение-загрузчик изначально конфигурирует адресное пространство создаваемой задачи.<br><br>Тезис такой<br>6. Приложение имеет возможность произвольно перекраивать свой виртуальный образ памяти, без всяких ограничений.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>7. Да. (а что имеется в виду под неявным запросом процесса на память.)</div></div><br>Неявный запрос - когда одно приложение запросило у другого большой объем данных.<br>На что задача-сервер расшаривает свой буфер с данными.<br>Но этот буфер не проецируется в адресное пространство клиента, пока тот не вызовет allocate, указав на какие адреса этот буфер проецировать.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>8. не вижу необходимости. Могут быть осложнения. Но это не категорическое НЕТ.</div></div><br>В любом случае - это не &quot;предмет первой необходимости&quot;, так что для начала пусть не реализовывается.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>9. Думаю стоит выбрать только одно.</div></div><br>В известных системах как раз и выбрано что-то одно.<br>Очередь не может обеспечить оперативность.<br>Отдельные потоки включают все возможности очереди, но на порядок &quot;дороже в эксплуатации&quot;.<br>Надо бы и то и другое - это довольно нетрудно реализовать.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>10. Если реализуем создание процессов-потоков в отдельном объкете, то Да. </div></div>ОК, вопрос сводится к предыдущему.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>11. Какие имеются в виду? </div></div><br>См. бюллетень::функции ядра.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Да. Но только давайте не будем выделять по секцию отдельный тип-объект. Это просто описатели памяти.</div></div><br>Да, секция - это описатель памяти.<br>Но, во-вторых, это не я предложил термин секция, а кто-то в форуме.<br>И, во-первых, ядру и приложениям в любом случае нужны разные описатели.<br><br>То, что я назвал дескриптором секции - это описатель памяти на уровне приложения.<br>А VMA содержат техническую информацию, большей частью которой может пользоваться только ядро.<br>Это сущности разных уровней абстракции. Вроде бы очевидно, что их нужно разнести в разные структуры.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34321</guid>
        <pubDate>Wed, 08 Oct 2003 09:31:54 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34321</link>
        <description><![CDATA[rcz: Давайте остановимся на подробном обсуждении IPC.<br><br>1) Отсылка сообщений<br>2) передача параметров<br>3) результат - отправка, получения<br>4) поддержка ядром асинхронных вызовов (нужны ли они в ядре? Как реализовать?)<br>5) учесть особенности сообщений в прерываниях.<br>6) из этого получим API ядра.<br><br>Мне не очень нравится, если делать очередью, точнее отдельно вызывать ReсieveMessage. Лучше сделать как вызовы удаленных процедур. <br><br>Создавая поток на каждое сообщение - трудности с возвратом результата. Это надо продумать.]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34318</guid>
        <pubDate>Wed, 08 Oct 2003 09:26:20 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34318</link>
        <description><![CDATA[rcz: 2справочная . Thnx. <br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>1. Потоки одного процесса имеют одно адресное пространство (без копирования). </div></div><br> Да.<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>2. С каждым ключом может быть связан один обработчик. Назовем его портом, как в mach.</div></div><br> Да.<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>3. Для каждого порта может быть запущено произвольное количество потоков. </div></div><br> Да. (произвольное количество запросов.)<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>4. Планирование времени ведется в два уровня: сначала по потокам, затем внутри потоков.</div></div><br> не до конца понял что имелось в виду.<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>5. Потоки могут создаваться извне процесса.</div></div><br> нет. (Или зачем?)<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>6. Процесс сам определяет на какие виртуальные адреса монтировать память.</div></div><br> Нет. Определяет загрузчик. (А ниже только объект менеджера памяти)<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>7. Любое отображение памяти на виртуальное пространства производится только по явному запросу процесса.</div></div><br>Да. (а что имеется в виду под неявным запросом процесса на память.)<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>8. Секции памяти позволяют использовать все возможности сегментной адресации (если она поддерживается платформой). </div></div><br>не вижу необходимости. Могут быть осложнения. Но это не категорическое НЕТ.<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>9. Сообщения могут как ставиться в очередь, так и запускать отдельный поток обработки. </div></div><br> Думаю стоит выбрать только одно. Или только очередь (один поток на интерфейс), или нет очереди, но наждой задаче новый поток(если нужна очередь, можно в процессе ставить в свою очередь - собирать из всех пришедших).<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>10. Сообщения - единственный механизм создания потока. </div></div><br>Если реализуем создание процессов-потоков в отдельном объкете, то Да. Но стоит ли так усложнять. syscall (как в mach или L4)<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>11. Реализовано 5 способов отправки сообщений. </div></div><br> Какие имеются в виду? <br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>12. Секция стека формально одна на процесс, но для каждого потока выделяется отдельная физическая память.</div></div><br>Да. Но только давайте не будем выделять по секцию отдельный тип-объект. Это просто описатели памяти.]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34315</guid>
        <pubDate>Wed, 08 Oct 2003 06:24:03 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34315</link>
        <description><![CDATA[справочная: Функция fork() (POSIX) клонирует процесс и не создаёт новых тредов в текущем процессе.<br>В целях оптимизации, она использует механизм COPY_ON_WRITE.<br>(см. http://www.opengroup.org/onlinepubs/7908799/xsh/fork.html)<br><br>Для создания треда в текущем процессе, в POSIX существует стандартный набор ф-ций.<br>(см. http://www.opengroup.org/onlinepubs/7908799/xsh/threads.html)<br><br>pthread_create(attr) - создаёт тред с атрибутами attr<br>(см. http://www.opengroup.org/onlinepubs/7908799/xsh/pthread_create.html)<br><br>pthread_attr_setstackaddr(attr, stackaddr) - устанавливает адрес стека в атрибутах attr<br>(см. http://www.opengroup.org/onlinepubs/7908799/xsh/pthread_attr_setstackaddr.html)<br><br>pthread_attr_setstacksize(attr, stacksize) - устанавливает размер стека в атрибутах attr<br>(см. http://www.opengroup.org/onlinepubs/7908799/xsh/pthread_attr_setstacksize.html)<br><br>Интерфейсы POSIX не являются интерфейсами ядра, но являются надстройкой над ним.]]></description>
        <author>справочная</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34312</guid>
        <pubDate>Tue, 07 Oct 2003 18:15:40 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34312</link>
        <description><![CDATA[nvm: В-общем, в Unix ситуация специфична: каждый поток работает в своем адресном пространстве, поэтому там другие проблемы. Как выкручиваться в поддержкой Unix-приложений - можно решить позже.<br><br>Предлагаю всем желающим высказать мнение об API ядра в виде да/нет по тезисам (чтобы понять степень пересечения мнений):<br><br>1. Потоки одного процесса имеют одно адресное пространство (без копирования).<br>2. С каждым ключом может быть связан один обработчик. Назовем его портом, как в mach.<br>3. Для каждого порта может быть запущено произвольное количество потоков.<br>4. Планирование времени ведется в два уровня: сначала по потокам, затем внутри потоков.<br>5. Потоки могут создаваться извне процесса.<br>6. Процесс сам определяет на какие виртуальные адреса монтировать память.<br>7. Любое отображение памяти на виртуальное пространства производится только по явному запросу процесса.<br>8. Секции памяти позволяют использовать все возможности сегментной адресации (если она поддерживается платформой).<br>9. Сообщения могут как ставиться в очередь, так и запускать отдельный поток обработки.<br>10. Сообщения - единственный механизм создания потока.<br>11. Реализовано 5 способов отправки сообщений.<br>12. Секция стека формально одна на процесс, но для каждого потока выделяется отдельная физическая память.<br><br>Все эти тезисы объяснялись в текстах, поэтому здесь формулировки краткие.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34309</guid>
        <pubDate>Tue, 07 Oct 2003 15:40:47 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34309</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>А кстати, как эта проблема решена в Unix ? <br>Я помню фразу, что fork() создает копию исходного процесса. Это значит, что и стека копию. Получается тогда, что если передать указатель на переменную в стеке - это будет указатель на копию переменной в копии стека? Но это ведь не то, что предполагал программист.</div></div><br><br>В Unix решено очень просто. Все описатели памяти передаются дочернему процессу. (там это список-дерево VMA)Т.е. и стек. Так ведь и получается адресное пространство.<br>Ну и механизм COPY_ON_WRITE. (изначально страницы помечены на чтение, но при записи - выделяется физическая страница и туда копируются данные).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>У меня два критерия микроядра: <br>1) небольшое (десятки) число функций в его API, <br>2) все приложения, в том числе компоненты системы общаются с ядром только через этот его API (не имеют доступа к его внутренним структурам).</div></div><br><br>2 пункт -  подходит для любого ядра.<br><br>Идеальное микроядро ничем кроме пересылки сообщений не занимается. Но таких не знаю. На примере mach, в ядре есть планирование задач и управление памятью. Это в целях оптимизации.<br><br>определение микроядра тут http://c2.com/cgi/wiki?MicroKernel<br>Обратите внимание на ядро L4. (http://os.inf.tu-dresden.de/L4/l4doc.html)<br>пишут, что только 7 API функций.<br>Хотя здесь перечисленно больше http://os.inf.tu-dresden.de/L4/l4man.html (но 7 - это IPC)<br><br>Тоже считаю, что на принцип идти не стоит. Лучше делать то, что может существовать.]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34306</guid>
        <pubDate>Tue, 07 Oct 2003 14:40:53 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34306</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 07.10.03, 17:18:59</span><div class='quote '><br>Но думаю не сложно проецировать стек родителя.</div></div><br>Не совсем просто... Но решаемо.<br><br>А кстати, как эта проблема решена в Unix ?<br>Я помню фразу, что fork() создает копию исходного процесса. Это значит, что и стека копию. Получается тогда, что если передать указатель на переменную в стеке - это будет указатель на копию переменной в копии стека? Но это ведь не то, что предполагал программист.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>Хм. Что под этим понимается. API может включать сотни функций.</div></div><br>Вот это, наверное, основной момент. Нужно определиться, что именно понимать под микроядром.<br>У меня два критерия микроядра:<br>1) небольшое (десятки) число функций в его API,<br>2) все приложения, в том числе компоненты системы общаются с ядром только через этот его API (не имеют доступа к его внутренним структурам).<br>При этом ядро &quot;не вникает&quot; в сообщения, которыми обмениваются приложения.<br>Получается, что интерфейсы компонентов не зависят от API ядра, и их можно рассматривать позже отдельно.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>В проектировании ОС главная проблемма - непонятно с какого конца начать. С ядра или с API</div></div><br>С API ядра. Этим, собственно и определяется система. Реализация - сугубо технический аспект.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Неее. Идеи плохие - всегда плохо:) . Но кто не рискует.... Просто надо быть аккуратней, все хорошо проверять. И сразу выкидывать плохие идеи.(может я консерватор)</div></div><br>Ну, заведомо плохие - конечно.<br>А в спорных случаях все же стоит предпочитать новое (чье-угодно, лишь бы не реализованное еще).]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34303</guid>
        <pubDate>Tue, 07 Oct 2003 13:18:59 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34303</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>..Насчет локальных переменных в отдельной секции я немного погорячился.. <br>Кроме как в стек их, конечно, никуда не денешь. <br> <br>Можно только настоятельно рекомендовать не передавать указатели на локальные переменные в другие потоки - это в любом случае очень опасное действие.</div></div><br>Согласен. Это плохо.<br><br>Но думаю не сложно проецировать стек родителя. А надежность приложения - дело рук самого разработчика. Он сам должен понимать, что это плохо.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Предлагаю сначала утвердить API ядра. Причем в упрощенном варианте.</div></div><br>Хм. Что под этим понимается. API может включать сотни функций.<br><br>Какого уровня. Если делаем ОС, логично предположить, что именно ядра. Но т.к. делаем микроядро, то надо разбить четко все обсуждение по объектам, подсистемам.<br><br>В проектировании ОС главная проблемма - непонятно с какого конца начать. С ядра или с API . Все взаимосвязанно. И что сначало пишетя. Спецификация и архитектура. По-моему архитектура и API к ней привязывается. Поэтому надо писать API, когда часть, подсистему полностью рассмотрим.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Рискну высказать крамольную мысль: лучше идеи даже плохие, но новые, чем хорошие, но старые. Лучше - для целей набора опыта.</div></div><br>Неее. Идеи плохие - всегда плохо:) . Но кто не рискует.... Просто надо быть аккуратней, все хорошо проверять. И сразу выкидывать плохие идеи.(может я консерватор)<br><br>И не стоит забывать, что все новое - хорошо забытое старое. просто надо смотреть, что уже есть, смотреть их ошибки, брать лучшее - это ведь уже будет само по себе новое.]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34300</guid>
        <pubDate>Tue, 07 Oct 2003 12:37:30 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34300</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 07.10.03, 12:11:35</span><div class='quote '><br>Многое ясно только на экспериментах и практике.</div></div><br>В том и проблема: когда объект (ОС) сложный все оценки становятся интуитивными, и даже численные расчеты будут лишь частными оценками, не гарантирующими эффективности в целом.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>2nvm, приводите как вы видете работу, алгоритмы, части кода. Со слов о том, как должно работать мало что понятно, да и Вам будут видны узкие места архитектуры.</div></div><br>Сначала важно со спецификацей разобраться - от этого кардинально зависит вся реализация.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>Хорошие идеи всегда реализовывать интересней чем плохие. Товарищи</div></div><br>Рискну высказать крамольную мысль: лучше идеи даже плохие, но новые, чем хорошие, но старые. Лучше - для целей набора опыта.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Правильно. Но просто кто-то постоянно отбрасывает все идеи.</div></div><br>Интересно, кто это.<br>..Наверное, всех касается..<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>Делаем так. Чтоб не дойти до драки.<br><br>Пишем основную концепцию (микроядро, объектность, ключи)  - готово.<br>Пишем отдельно каждую подсистему (сообщения,процессы,память, защита).<br>Уточняем их. Оптимизируем. Рассматриваем поглубже и отдельно(это же микроядро).<br></div></div><br>Уже на уровне основных концепций большие разногласия.<br>Нужно как-то выбирать компромиссы.<br>Предлагаю сначала утвердить API ядра. Причем в упрощенном варианте.<br>И вообще ориентироваться на тестовую сильно урезанную версию.<br><br>Один вариант API я описал. Если есть альтернативы - приведите более-менее полные списки функций, чтобы можно было понять концепцию.<br><br>Если что-то из моего описания не понятно - можно ведь уточнить.<br>Многие уточнения я уже делал по ходу обсуждения. <br>Но заранее сделать исчерпывающее описание я не могу (интересно, кто может?!) - заранее не предусмотришь все моменты, которые со стороны непонятны.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '> <br>И так нельзя заявлять. Та архитектура хорошая и главное рабочая. Есть чему всем поучиться.</div></div><br>В шутку все же можно.<br>..И даже не совсем в шутку.. Уж если что-то делать, то нужно верить (или хотя бы принять условно как рабочую гипотезу), что то, что делается, &nbsp;- лучше. Иначе как-то грустно.. :)<br>Mach - проект, очевидно, добротный. Но раз он уже есть, то придется делать лучше - просто деваться некуда.. :)]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34297</guid>
        <pubDate>Tue, 07 Oct 2003 09:36:49 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34297</link>
        <description><![CDATA[nvm: ..Насчет локальных переменных в отдельной секции я немного погорячился..<br>Кроме как в стек их, конечно, никуда не денешь.<br><br>Можно только настоятельно рекомендовать не передавать указатели на локальные переменные в другие потоки - это в любом случае очень опасное действие.<br><br>А там, где это все же делается - использовать элиасы стека.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34294</guid>
        <pubDate>Tue, 07 Oct 2003 08:11:35 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34294</link>
        <description><![CDATA[rcz: Докатились! Терпимее друг к другу.<br><br>Чтоб до такого не доходить предлагаю приводить подробные примеры и цифры, где какая архитектура будет производительне и надежнее.<br><br>Многое ясно только на экспериментах и практике.<br><br>2nvm, приводите как вы видете работу, алгоритмы, части кода. Со слов о том, как должно работать мало что понятно, да и Вам будут видны узкие места архитектуры.<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Разумеется, что чужие идеи реализовывать никому и никогда не интересно.</div></div>Хорошие идеи всегда реализовывать интересней чем плохие. Товарищи, прислушивайтесь друг к другу. :)<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Поэтому речь идет не о помощи, а о том, чтобы сделать заготовки, которые были бы полезны всем участникам.</div></div><br>Правильно. Но просто кто-то постоянно отбрасывает все идеи.<br><br><br>Делаем так. Чтоб не дойти до драки.<br><br>Пишем основную концепцию (микроядро, объектность, ключи) &nbsp;- готово.<br>Пишем отдельно каждую подсистему (сообщения,процессы,память, защита).<br>Уточняем их. Оптимизируем. Рассматриваем поглубже и отдельно(это же микроядро).<br><br>Но в одном треде это невозможно, появляется сильная путаница, то скатываемя на верхний уровень, то опять вниз, то к памяти, то к процессам.<br><br>З.Ы. надо что ль как-то &nbsp;организованнее.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>&gt;Предлагаю еще ознакомиться с ядром Mach <br>Да.. немало понаписано.. <br>ИМХО, здесь архитектура лучше &nbsp;</div></div> <br>И так нельзя заявлять. Та архитектура хорошая и главное рабочая. Есть чему всем поучиться.]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34291</guid>
        <pubDate>Tue, 07 Oct 2003 07:28:31 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34291</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>Vilmor, 07.10.03, 10:57:33</span><div class='quote '>Вы можете сколько угодно придумывать &quot;концептуально новую ОС&quot;, нисколько не обременяя себя детальной проработкой её архитектуры. Вы считаете, что ваша задача заключается только в этом.</div></div><br>Все же разработку принято четко делить на этапы: сначала интерфейс, потом реализация.<br>Не утвердив хотя бы на 90\% API ядра, нет смысла проектировать реализацию (кроме как на уровне общих идей).<br>Причем, проектирование интерфейсов - очень большая часть работы.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Отлично. Вот только все эти ваши идеи прийдётся реализовать вам своими руками.<br>Во всяком случае, я в этом помогать не собираюсь.</div></div><br>Разумеется, что чужие идеи реализовывать никому и никогда не интересно.<br>Поэтому речь идет не о помощи, а о том, чтобы сделать заготовки, которые были бы полезны всем участникам.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Однако со своей стороны, осмелюсь ещё посоветовать вам чему-нибудь научиться сначала. Можно поступить на 1-й курс фак-та информатики в каком-нибудь университете. Хочется надеяться, это вам поможет.</div></div><br>Типичная проблема выпускников вузов - они уверены, будто что-то знают.. :(<br> :)]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34288</guid>
        <pubDate>Tue, 07 Oct 2003 06:57:33 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34288</link>
        <description><![CDATA[vilmor: Спасибо за пояснения.<br><br>Вы можете сколько угодно придумывать &quot;концептуально новую ОС&quot;, нисколько не обременяя себя детальной проработкой её архитектуры. Вы считаете, что ваша задача заключается только в этом.<br><br>Отлично. Вот только все эти ваши идеи прийдётся реализовать вам своими руками.<br>Во всяком случае, я в этом помогать не собираюсь.<br><br>Однако со своей стороны, осмелюсь ещё посоветовать вам чему-нибудь научиться сначала. Можно поступить на 1-й курс фак-та информатики в каком-нибудь университете. Хочется надеяться, это вам поможет.]]></description>
        <author>vilmor</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34284</guid>
        <pubDate>Tue, 07 Oct 2003 06:46:57 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34284</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>Vilmor, 07.10.03, 02:22:26</span><div class='quote '><br>Это не изврат, а вполне реальная вещь, очень часто встречающаяся.<br><br>Например, когда один поток порождает другой, передавая ему в качестве параметра указатель на данные в своём стеке, которые дочерний поток может изменить.</div></div><br>..Как-будто изврат не может реально часто встречаться &nbsp;:)..<br><br>&quot;Родные&quot; компиляторы локальные переменные подпрограммы будут размещать не в стеке, а в специальной секции.<br>Проблема возникает только с запуском &quot;чужих&quot; exe. ..Здесь надо подумать.<br>Вероятно, придется как-то поддерживать и &quot;обычные&quot; стеки. Простое решение - разрешить потоку переключать секцию стека на alias (не требует новых сущностей, а только доп. syscall).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>А ваш метод можно легко реализовать с помощью одной VMA с локальными для треда страницами (TLS). И для отладчика это не будет проблемой.</div></div><br>..Тогда в чем, собственно, принципиальное отличие?!<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Практика показывает, что нужно не меньше 8Кб для каждого стека. Кроме того, не стоит забывать и про другие структуры, необходимые для треда. Так что тут будет никак не меньше 16-ти Мб</div></div><br>Другие структуры уложатся в десятки байт.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>1. Затормозятся все процессы, потому что они разделяют общее процессорное время, а объём накладных расходов растёт.<br>2. 50 000 потоков тоже будет тормозить, и вы с этим ничего не сможете поделать.</div></div><br>Это в обычной схеме, когда время делится сразу на потоки, будет тормозиться все.<br>А у меня затормозится только один процесс, так как время будет сначала распределяться на процессы, а уже внутри процесса - на его потоки.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Чтобы рационально использовать ресурсы памяти и процессорного времени. Число потоков всегда надо минимизировать.</div></div><br>Это резко ограничивает свободу в алгоритмах.<br>Если реализовать эффективную поддержку большого числа потоков - это будет очень большим козырем системы.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Этого нельзя допускать в любом случае, потому что это всегда даёт шанс одной программе нарушить нормальную работу другой.</div></div><br>Смотря как эта другая программа написана.<br><br>Важный момент: при завершении потока все блокировки семафоров, которые он сделал, должны автоматически сниматься.<br><br>Еще усовершенствование: при включении любой блокировки поток на время переводить на ресурс процесса, где он выполняется (при этом он временно получит приоритет из параметров этого процесса).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>На практике, приоритет треда задачи часто оказывается очень важной вещью, управление которой можно доверить только самой задаче.</div></div><br>Если поток создан клиентом, то он и нужен клиенту, а задаче-серверу он безразличен.<br>Но это технический вопрос, так как передача прав владения потоком все равно предусматривается.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Ещё одна (какая уже по счёту?) лишняя сущность. </div></div><br>Нулевая по счету..<br>Критические секции - полезный объект синхронизации, поэтому не лишний.<br>Правда, в виндовом исполнении он эквивалентен семафору, но его можно сделать функциональнее.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34281</guid>
        <pubDate>Tue, 07 Oct 2003 06:16:03 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34281</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>Vilmor, 07.10.03, 01:46:05</span><div class='quote '><br>Пускай хоть так.<br>В любом случае, предложенное вами API не удовлетворяет всем потребностям прикладного ПО в управлении памятью. К тому же, часть параметров вашей секции приложению на самом деле не нужна.</div></div><br>Каким требованиям не удовлетворяет, и какие параметры не нужны?<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>1. От таблиц перемещения всё равно не избавиться.</div></div><br>Если они кому нужны - пусть использует.<br>Кстати, подумывая о &quot;родном&quot; для системы формате exe-файла, я склоняюсь к чистому bin. Конечно, нужно поддерживать и много других, но bin - самый удобный (пусть приложение само себя размещает в памяти).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>2. Защита не выше ни на грош.</div></div><br>Выше на порядок (если правильно пользоваться).<br>Если нет сегментов, то при ошибке в указателе можно случайно попасть в уже распределенный адрес и попортить там данные.<br>А сегментом можно ограничить кучу и любой выход за ее адресное пространство будет приводить к исключению. Конечно, куча будет испорчена, но можно ведь завести несколько куч, что существенно повысит надежность.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>3. Сегментация памяти в наше время окончательно вытеснена страничной.</div></div><br>Не вытеснена - просто в виндах она не поддерживается, поэтому никто и не пользуется.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Это не экзотика, а широко распространённое явление.</div></div><br>Единственное место, где я видел не PC - это тех. университет. Там есть несколько SUN.<br>Но подозреваю, что их покупку просто кто-то лоббировал, так как они на самом деле не пришей ... . Вместо одного SUN можно купить 30 персоналок, каждая из которых по производительности практически сравнима.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Это не объект микроядра, а пользовательской подсистемы, работающей в режиме ядра.</div></div><br>У Вас, похоже, пользовательская подсистема имеет прямой доступ к структурам ядра?<br>Если так, то это по сути моноядро.<br>По-хорошему, только само ядро имеет доступ к своим структурам. Драйвера, работающие в привил. режиме имеют тем не менее свое адресное пространство.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '> Механизм частичного проецирования таких объектов, какой предлагаю я, на практике более гибкий и многофункциональный, чем расшаривание секций, какое предлагаете вы.</div></div><br>Непонятно, чем проецирование отличается от расшаривания.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>1. Зачем выделять память для секции, в которую будем проецировать файл?</div></div><br>Потому что виртуальное адресное пространство полностью во владении приложения - даже ядро по своей инициативе не имеет права в него ничего монтировать.<br>allocate - это монтирование либо новой либо расшаренной памяти на виртуальные адреса.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>2. Зачем задавать поле Type = {CODE &#124; DATA &#124; STACK &#124; OTHER} ?</div></div><br>STACK - принципиально отличается по свойствам.<br>Кроме того, только в CODE может быть точка входа, и только она может исполняться.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>3. Можно ли проецировать большой файл или разделяемую область памяти в меньшую по размерам секцию?</div></div><br>Ядро позволяет только расшарить буфер. А как им пользоваться - приложения &quot;договариваются&quot; сами.<br>Функции read и write реализуются очевидным образом.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>4. Как вы собираетесь задавать смещение данных файла относительно начала проекции?</div></div><br>Стандартным синтаксисом read/write/seek - чтения (или записи) файла.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>5. Можно ли поменять это смещение для уже проецированного файла?</div></div><br>seek<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>6. Можно ли использовать метод WRITE_COPY?</div></div><br>Это не специфично для файлов.<br>Для любых разделяемых секций этот метод можно использовать.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>7. Насколько удобно ваше API для проецирования других объектов помимо файлов и разделяемой памяти?</div></div><br>А кроме памяти ничего и не проецируется.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>8. Какими недостатками обладает VMA по сравнению с секциями?<br>9. Какими преимуществами обладают секции по сравнинию с VMA?</div></div><br>VMA, как я понял, - внутренняя структура ядра, и для ее использования нужен особый режим.<br>А секции - универсальный механизм, доступный всем.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34278</guid>
        <pubDate>Mon, 06 Oct 2003 22:22:26 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34278</link>
        <description><![CDATA[vilmor: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 07.10.03, 01:17:34</span><div class='quote '>Потокам НЕ НУЖНО работать с общими переменными в стеке.<br>А если такой изврат где-то используется - это не повод извращать архитектуру.</div></div>Это не изврат, а вполне реальная вещь, очень часто встречающаяся.<br><br>Например, когда один поток порождает другой, передавая ему в качестве параметра указатель на данные в своём стеке, которые дочерний поток может изменить.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 07.10.03, 01:17:34</span><div class='quote '>Все равно понадобится возможность монтирования этих клоновых стеков на отдельные секции - но, в основном, для отладчика..</div></div>А ваш метод можно легко реализовать с помощью одной VMA с локальными для треда страницами (TLS). И для отладчика это не будет проблемой.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 07.10.03, 01:17:34</span><div class='quote '>По-минимуму, хватит 4 Мб (по странице на стек).</div></div>Практика показывает, что нужно не меньше 8Кб для каждого стека. Кроме того, не стоит забывать и про другие структуры, необходимые для треда. Так что тут будет никак не меньше 16-ти Мб.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 07.10.03, 01:17:34</span><div class='quote '>Но суть в том, что затормозится только тот процесс, где 1000 потоков.<br><br>..Пожалуй, на средней машине 100000 будет тормозить. Но сделать, чтобы 50 000 (сколько влазит без свопа) не тормозило - реально. 8-)</div></div>1. Затормозятся все процессы, потому что они разделяют общее процессорное время, а объём накладных расходов растёт.<br>2. 50 000 потоков тоже будет тормозить, и вы с этим ничего не сможете поделать.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 07.10.03, 01:17:34</span><div class='quote '>И зачем такое ограничение?!</div></div>Чтобы рационально использовать ресурсы памяти и процессорного времени. Число потоков всегда надо минимизировать.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 07.10.03, 01:17:34</span><div class='quote '>Во многих случаях это все же можно допускать.<br>В некоторых действительно нельзя.</div></div>Этого нельзя допускать в любом случае, потому что это всегда даёт шанс одной программе нарушить нормальную работу другой.<br><br>На практике, приоритет треда задачи часто оказывается очень важной вещью, управление которой можно доверить только самой задаче.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 07.10.03, 01:17:34</span><div class='quote '>Но эта проблема решаема: можно ввести разновидность критических секций, где процесс нельзя завершить принудительно.<br>..Есть и другие решения в рамках концепции..</div></div>Ещё одна (какая уже по счёту?) лишняя сущность. Программа будет тратить дополнительное время на лишние операции, корые ей ни к чему. И всё равно, вероятность дыр в защите будет оставаться очень высокой.]]></description>
        <author>vilmor</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34276</guid>
        <pubDate>Mon, 06 Oct 2003 21:46:05 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34276</link>
        <description><![CDATA[vilmor: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 07.10.03, 00:35:22</span><div class='quote '>Секция - и есть системная абстракция сегмента, только более универсальная.<br>Приведенная структура - это элемент API. В ней есть только параметры, которые нужны приложению (в ядре предполагается доп. структура - внутренних структур я вообще не касался).</div></div>Пускай хоть так.<br>В любом случае, предложенное вами API не удовлетворяет всем потребностям прикладного ПО в управлении памятью. К тому же, часть параметров вашей секции приложению на самом деле не нужна.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 07.10.03, 00:35:22</span><div class='quote '>Если их нормально реализовать - это будет единственная система с полноценной поддержкой сегментов. А по сути, сегменты - полезная вещь: можно обходится без таблиц перемещения, и защита выше.</div></div>1. От таблиц перемещения всё равно не избавиться.<br>2. Защита не выше ни на грош.<br>3. Сегментация памяти в наше время окончательно вытеснена страничной.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 07.10.03, 00:35:22</span><div class='quote '>Все равно использование не x86 платформ - все больше экзотика.</div></div>Это не экзотика, а широко распространённое явление.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 07.10.03, 00:35:22</span><div class='quote '>hStream - для ядра лишнее понятие (в нем достаточно секций).</div></div>Это не объект микроядра, а пользовательской подсистемы, работающей в режиме ядра. Он предоставляет удобную абстракцию для блочных и символьных устройств, потоков и блоков данных, файлов. Механизм частичного проецирования таких объектов, какой предлагаю я, на практике более гибкий и многофункциональный, чем расшаривание секций, какое предлагаете вы.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 07.10.03, 00:35:22</span><div class='quote '>Открытие файла в моем сценарии:<br><div class='tag-code'><span class='pre_code'></span><div class='code  code_collapsed ' title='Подсветка синтаксиса доступна зарегистрированным участникам Форума.' style=''><div><div><ol type="1"><div class="code_line">&#60;br&#62;Section S(...); // fill requirements (параметры)&#60;br&#62;hSection=Allocate(S); &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// &nbsp;выделить память&#60;br&#62;Share(hKey_FileServer,hSection); // &nbsp;разрешить совместное использование секции&#60;br&#62;RunMessage(hKey_FileServer,&quot;hStream=open_file(hSection,&quot;&quot;/usr/bin/perl&quot;&quot;, O_READ);&quot;);&#60;br&#62; &nbsp; &nbsp;// открыть файл (сообщение приведено в текстовом виде для наглядности)&#60;br&#62;</div></ol></div></div></div></div><script>preloadCodeButtons('1');</script><br>Технические детали (половина параметров вызовов) здесь опущены.<br><br>Сервер для доступа к разделяемой памяти вызывает<br>Allocate() с доп. параметрами: hKey_Client,hSection (относительный хэндл секции).</div></div>1. Зачем выделять память для секции, в которую будем проецировать файл?<br>2. Зачем задавать поле Type = {CODE &#124; DATA &#124; STACK &#124; OTHER} ?<br>3. Можно ли проецировать большой файл или разделяемую область памяти в меньшую по размерам секцию?<br>4. Как вы собираетесь задавать смещение данных файла относительно начала проекции?<br>5. Можно ли поменять это смещение для уже проецированного файла?<br>6. Можно ли использовать метод WRITE_COPY?<br>7. Насколько удобно ваше API для проецирования других объектов помимо файлов и разделяемой памяти?<br>8. Какими недостатками обладает VMA по сравнению с секциями?<br>9. Какими преимуществами обладают секции по сравнинию с VMA?]]></description>
        <author>vilmor</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34273</guid>
        <pubDate>Mon, 06 Oct 2003 21:17:34 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34273</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>Vilmor, 06.10.03, 23:52:05</span><div class='quote '>Из выше сказанного следует, что потоки не смогут работать с общими переменными в стеке. Значит, это решение не годится.</div></div><br>Потокам НЕ НУЖНО работать с общими переменными в стеке.<br>А если такой изврат где-то используется - это не повод извращать архитектуру.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Таким образом, на сегменты взваливается совершенно несвойственная им задача - отвечать за стратегию использования адресного пространства программы. Это неправильно, потому что программа сама должна это решать, оптимальным для неё способом.</div></div><br>Все равно понадобится возможность монтирования этих клоновых стеков на отдельные секции - но, в основном, для отладчика..<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Процесс, создавший 1000 тредов, съест ещё свыше 16Мб памяти и будет тратить на переключения между ними до 10\% всего процессорного времени </div></div><br>По-минимуму, хватит 4 Мб (по странице на стек).<br>Но суть в том, что затормозится только тот процесс, где 1000 потоков.<br><br>..Пожалуй, на средней машине 100000 будет тормозить. Но сделать, чтобы 50 000 (сколько влазит без свопа) не тормозило - реально. 8-)<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>Мало того, что на обработку сообщений должно приходиться не более потока на каждый объект. Более того, число потоков должно быть меньше числа объектов! </div></div><br>И зачем такое ограничение?!<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Таким образом, один процесс может в любой момент (!) управлять тредом другого процесса, и даже принудительно завершить его! Неужели вы не понимаете, что этого нельзя допускать?</div></div><br>Во многих случаях это все же можно допускать.<br>В некоторых действительно нельзя.<br>Но эта проблема решаема: можно ввести разновидность критических секций, где процесс нельзя завершить принудительно.<br>..Есть и другие решения в рамках концепции..]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34269</guid>
        <pubDate>Mon, 06 Oct 2003 20:35:22 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34269</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>Vilmor, 06.10.03, 23:21:04</span><div class='quote '>В таком виде секция не является достаточно универсальной сущностью. Кроме того, она содержит данные, которые будут излишними при выполнении программы. На самом деле, от секций нужно избавляться при загрузке EXE и DLL-модулей - либо проецируя в VMA, либо создавая сегменты.</div></div><br>Секция - и есть системная абстракция сегмента, только более универсальная.<br>Приведенная структура - это элемент API. В ней есть только параметры, которые нужны приложению (в ядре предполагается доп. структура - внутренних структур я вообще не касался).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '> Хочется ещё раз обратить ваше внимание на то, что для x86 использование отдельных сегментов не нужно.</div></div><br>Если их нормально реализовать - это будет единственная система с полноценной поддержкой сегментов. А по сути, сегменты - полезная вещь: можно обходится без таблиц перемещения, и защита выше.<br>Все равно использование не x86 платформ - все больше экзотика.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Теперь немного о том, как это работает. Писать об этом долго, так что приведу простой пример.<br><br>Пример использования VMA в программе:<br><div class='tag-code'><span class='pre_code'></span><div class='code  code_collapsed ' title='Подсветка синтаксиса доступна зарегистрированным участникам Форума.' style=''><div><div><ol type="1"><div class="code_line">// get stream:&#60;br&#62;hStream = open_file(&quot;/usr/bin/perl&quot;, O_READ);    // open file for reading&#60;br&#62;</div></ol></div></div></div></div></div></div><br>hStream - для ядра лишнее понятие (в нем достаточно секций).<br><br>Открытие файла в моем сценарии:<br><div class='tag-code'><span class='pre_code'></span><div class='code  code_collapsed ' title='Подсветка синтаксиса доступна зарегистрированным участникам Форума.' style=''><div><div><ol type="1"><div class="code_line">&#60;br&#62;Section S(...); // fill requirements (параметры)&#60;br&#62;hSection=Allocate(S); &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// &nbsp;выделить память&#60;br&#62;Share(hKey_FileServer,hSection); // &nbsp;разрешить совместное использование секции&#60;br&#62;RunMessage(hKey_FileServer,&quot;hStream=open_file(hSection,&quot;&quot;/usr/bin/perl&quot;&quot;, O_READ);&quot;);&#60;br&#62; &nbsp; &nbsp;// открыть файл (сообщение приведено в текстовом виде для наглядности)&#60;br&#62;</div></ol></div></div></div></div><br>Технические детали (половина параметров вызовов) здесь опущены.<br><br>Сервер для доступа к разделяемой памяти вызывает<br>Allocate() с доп. параметрами: hKey_Client,hSection (относительный хэндл секции).]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34265</guid>
        <pubDate>Mon, 06 Oct 2003 19:52:05 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34265</link>
        <description><![CDATA[vilmor: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 02.10.03, 18:40:06</span><div class='quote '>В идеале, стек - это объект с интерфейсрм всего их двух функций: push и pop. И ему вообще не нужно адресное пространство. То, что в современных архитектурах ему приходится выделять адреса - это технические издержки.<br>Это аргумент в пользу выделения стека в отдельную сущность.</div></div>Но это только в идеале. А на самом деле, не так.<br><br>Во-первых, каждая ф-ция в программе выделяет в стеке фрейм, в котором хранит временные переменные, к которым она обращается в произвольном порядке, а не через push/pop.<br><br>Во-вторых, указатель на локальную переменную в стеке может передаваться в другие вызываемые ф-ции. Таким образом, в любой момент времени программа может обратиться к произвольному адресу внутри стека.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 30.09.03, 21:19:52</span><div class='quote '>Решение предлагается следующее.<br>Ввести осовый вид секции - секция стека, со свойствами:<br>- уникальность в пределах процесса,<br>- отсутствие пересечений с другими секциями, как по физическим, так и виртуальным адресам,<br>- клоновость: для каждого потока из задачи делается собственный клон секции стека, на тех же виртуальных адресах, но со своим отображением в физическую память.<br>Все клоны имеют один и тот же хэндл.</div></div>Из выше сказанного следует, что потоки не смогут работать с общими переменными в стеке. Значит, это решение не годится.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 02.10.03, 18:40:06</span><div class='quote '><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>И это не единственное осложнение, которое у вас появится, если вы будете и дальше отказываться от модели пулов тредов, которая на самом деле, проще, красивее и эффективнее в реализации,</div></div>Может, Вы бы описали ее немного подробнее (можно с фрагментами из других источников)</div></div><br>И вот вам первая проблема:<div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 02.10.03, 18:40:06</span><div class='quote '>Изначально я так и предполагал.<br>Но проблема в том, что тред может быть создан извне другим процессом, который не может смонтировать стек в данном процессе</div></div><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 02.10.03, 18:40:06</span><div class='quote '>Насчет &quot;клонированных стеков&quot; в одном сегменте - эта идея, думаю, на самом деле совершенно новая и нигде не опробованная. Поэтому у меня самого нет в ней полной уверенности, но предварительно выглядит привлекательной.</div></div>Таким образом, на сегменты взваливается совершенно несвойственная им задача - отвечать за стратегию использования адресного пространства программы. Это неправильно, потому что программа сама должна это решать, оптимальным для неё способом.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 02.10.03, 18:40:06</span><div class='quote '>Потом, поддержка потоков - это все-таки ведение ядра, и нехорошо загружать этими низкоуровневыми проблемами приложения.</div></div>По отношению к ядру, эта задача гораздо более высокого уровня.<br>Вообще, прикладное ПО разделяется на много уровней, где на самом нижнем - libc.so (kernel.dll), а на самом верхнем - прикладная программа. Прикладой программист может и не знать, как выделяется память под стек, даже если это делается не в ядре ОС.<br><br>По этой и по многим другим, более серьёзным причинам, только сам процесс может создавать у себя потоки.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 02.10.03, 18:40:06</span><div class='quote '>И заваливаем этим хламом приложение..</div></div>Нет (патамучта!)<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 03.10.03, 21:28:01</span><div class='quote '>Если не квотировать время на весь процесс, то процесс, создавший 1000 потоков в 1000 раз замедлит остальные приложения.<br>В схеме, что я предлагаю, можно безболезненно запустить до 100000 потоков (если больше - могут начаться проблемы).</div></div>Процесс, создавший 1000 тредов, съест ещё свыше 16Мб памяти и будет тратить на переключения между ними до 10\% всего процессорного времени (включая работу шедулера и проч.). Запустив 100000, вы тормознёте Pentium4. А если говорить о карманных ПК, то для них 10 тредов - это уже слишком много.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 03.10.03, 23:52:28</span><div class='quote '>Тут и работает вторая идея: обработку запросов сервер ведет в счет времени клиента (!). Поэтому сервер нисколько не замедляется.</div></div>И это не поможет.<br><br>И главное не в том, что вычислительных мощностей пока что не хватает, а в том, что такой дизайн ничем не оправдан.<br><br>Мало того, что на обработку сообщений должно приходиться не более потока на каждый объект. Более того, число потоков должно быть меньше числа объектов! Метод пулов может решить и эту проблему, если в одном потоке будут обрабатываться сообщения для разных объектов.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 02.10.03, 18:40:06</span><div class='quote '>И что?.. Разве кто-то предлагал что-либо, вызывающее зависимость ядра от модулей??</div></div>Это к тому, что наличие дополнительных модулей в режиме ядра ещё не делает само ядро монолитным. Я считаю, что часть подсистем и драйверов, для которых важна высокая производительность (все драйверы, работающие с I/O портами, дисковые и видеодрайверы), должны работать на уровне ядра, а не приложения.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 02.10.03, 18:40:06</span><div class='quote '>Есть одна зависимость: для реализации подкачки ядро вынуждено обращаться к драйверу диска - но это исключение неизбежно и единственно.</div></div>Подкачка страниц (не сама виртуальная память) может быть реализована отдельно от микроядра, в подсистеме виртуальной памяти.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 26.09.03, 16:59:44</span><div class='quote '>Нужно, чтобы функция ForkMessage, котрая единственная создает потоки, возвращала хэндл нового потока.<br>Соответственно, нужно добавить функции изменения приоритета потока и принудительного завершения.</div></div>Таким образом, один процесс может в любой момент (!) управлять тредом другого процесса, и даже принудительно завершить его! Неужели вы не понимаете, что этого нельзя допускать?<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 26.09.03, 20:56:16</span><div class='quote '>Настоящий объект САМ выполняет действия над собой - а если действия производятся извне, да еще &quot;без его ведома&quot;, то это не объект с точки зрения ООП.</div></div>Возникла путаница в понятиях. На самом деле, здесь действия надо объектом &quot;тред&quot; происходят без ведома объектов в данном процессе, но с ведома и посредсвом самого треда, котрый является объектом ядра.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 25.09.03, 20:49:10</span><div class='quote '>Если бы ограничиться только сообщениями типа Post/SendMessage - тогда объект действительно бы однозначно ассоциировался с потоком цикла обработки сообщений в нем, и можно было бы сказать, что это одно и тоже.<br>Но, когда есть Run/ForkMessage - тогда через любой объект могут проходить разные потоки и однозначной связи нет.</div></div>Я бы начертил схему, что с чем и как ассоциировано, но у меня нет возможности выложить её на форум.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 03.10.03, 17:46:27</span><div class='quote '>И еще организационное предложение.<br>Если кто имеет принципиальные возражения против спецификации (несовместимые с общей идеологией интерфейса ядра), то прилагайте к ним свои ПОЛНЫЕ версии интерфейса (функций ядра). Потому что предложения имеют смысл только в контексте.<br><br>Желательно также оформлять такие предложения в структурированном виде (html). Тогда можно сделать сайт, на котором структурированно оформить все варианты с дискуссией - такая документация имела бы самостоятельную ценность, независимо от создания кода.</div></div>Обязательно сделаю свой сайт, но пока что у меня не хватает для этого времени.]]></description>
        <author>vilmor</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34262</guid>
        <pubDate>Mon, 06 Oct 2003 19:21:04 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34262</link>
        <description><![CDATA[vilmor: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 02.10.03, 18:40:06</span><div class='quote '>Чем Ваш VMA отличается от секций? Может, опишете существо?<br><br>Здесь секция - универсальная абстракция для области памяти.<br>В x86 секция по-хорошему должна поддерживать в полном объеме возможности сегментов - а на других платформах позволять без сегментов обходиться.<br>Секция по смыслу похожа на сегмент (и призвана его эмулировать на платформах, где он не доступен). А сегмент - сущность процессора, то есть самого низкого уровня, так кому, как не ядру ее поддерживать?!</div></div><br><div class='tag-code'><span class='pre_code'></span><div class='code  code_collapsed ' title='Подсветка синтаксиса доступна зарегистрированным участникам Форума.' style=''><div><div><ol type="1"><div class="code_line">struct Section&#60;br&#62;{&#60;br&#62; &nbsp; &nbsp;pointer start;&#60;br&#62; &nbsp; &nbsp;pointer end;&#60;br&#62; &nbsp; &nbsp;int segment_selector;&#60;br&#62; &nbsp; &nbsp;enum Type {CODE, DATA, STACK, OTHER};&#60;br&#62; &nbsp; &nbsp;Type type;&#60;br&#62; &nbsp; &nbsp;bool read_only;&#60;br&#62; &nbsp; &nbsp;bool is_static; // невыгружаемая&#60;br&#62;};</div></ol></div></div></div></div><br>В таком виде секция не является достаточно универсальной сущностью. Кроме того, она содержит данные, которые будут излишними при выполнении программы. На самом деле, от секций нужно избавляться при загрузке EXE и DLL-модулей - либо проецируя в VMA, либо создавая сегменты. Хочется ещё раз обратить ваше внимание на то, что для x86 использование отдельных сегментов не нужно.<br><br>Теперь немного о том, как это работает. Писать об этом долго, так что приведу простой пример.<br><div class='tag-code'><span class='pre_code'></span><div class='code  code_collapsed ' title='Подсветка синтаксиса доступна зарегистрированным участникам Форума.' style=''><div><div><ol type="1"><div class="code_line">// kernelmode structures:&#60;br&#62;&#60;br&#62;struct vma_s&#60;br&#62;{&#60;br&#62; &nbsp; &nbsp;void &nbsp; &nbsp; &nbsp; &nbsp;*start_addr; &nbsp; &nbsp;// start address in userspace&#60;br&#62; &nbsp; &nbsp;void &nbsp; &nbsp; &nbsp; &nbsp;*end_addr; &nbsp; &nbsp; &nbsp;// last address in userspace&#60;br&#62; &nbsp; &nbsp;avl_node_s &nbsp;*node; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// AVL tree node to speed up search&#60;br&#62; &nbsp; &nbsp;void &nbsp; &nbsp; &nbsp; &nbsp;*param; &nbsp; &nbsp; &nbsp; &nbsp; // subsystem-specific parameter&#60;br&#62; &nbsp; &nbsp;vma_vtbl_s &nbsp;*vtbl; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// subsystem-specific functions&#60;br&#62; &nbsp; &nbsp;uint &nbsp; &nbsp; &nbsp; &nbsp;flags; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// subsystem-specific flags&#60;br&#62;};&#60;br&#62;&#60;br&#62;struct vma_vtbl_s&#60;br&#62;{&#60;br&#62; &nbsp; &nbsp;void (*page_fault)(vma_s *vma, void *fault_addr, uint fault_flags); &nbsp;// #PF handler&#60;br&#62; &nbsp; &nbsp;void (*close)(vma_s *vma); &nbsp; // finalize VMA when process or handle destroyed&#60;br&#62; &nbsp; &nbsp;// ...&#60;br&#62;};&#60;br&#62;&#60;br&#62;struct avl_node_s &nbsp;// Adelson-Velskii-Landis (locally balanced) tree&#60;br&#62;{&#60;br&#62; &nbsp; &nbsp; &nbsp;avl_node_s &nbsp;*left; &nbsp; // left kid of node&#60;br&#62; &nbsp; &nbsp; &nbsp;avl_node_s &nbsp;*right; &nbsp;// right kid of node&#60;br&#62; &nbsp; &nbsp; &nbsp;uint &nbsp; &nbsp; &nbsp; &nbsp;depth; &nbsp; // depth (height) of node&#39;s subtree&#60;br&#62;};</div></ol></div></div></div></div><br><br>Пример использования VMA в программе:<br><div class='tag-code'><span class='pre_code'></span><div class='code  code_collapsed ' title='Подсветка синтаксиса доступна зарегистрированным участникам Форума.' style=''><div><div><ol type="1"><div class="code_line">// get stream:&#60;br&#62;hStream = open_file(&quot;/usr/bin/perl&quot;, O_READ); &nbsp; &nbsp;// open file for reading&#60;br&#62;// - or -&#60;br&#62;hStream = shared_alloc(0x80000, &quot;/ipc/x-wnd/oem_font&quot;); &nbsp; // allocate 0x80000 bytes&#60;br&#62;// - or -&#60;br&#62;hStream = shared_open(&quot;/ipc/x-wnd/oem_font&quot;); &nbsp; // open shared memory&#60;br&#62;// - or -&#60;br&#62;hStream = local_alloc(0x80000); &nbsp; // allocate 0x80000 bytes of local memory&#60;br&#62;// - or -&#60;br&#62;hStream = open_vesa_vbuf(); &nbsp; // open VESA video buffer&#60;br&#62;// VMA can stick together parts of VESA1.x fragmented buffer&#60;br&#62;&#60;br&#62;// map hStream at memory range [dwStart, dwEnd], from position dwOffset&#60;br&#62;hVma = map_stream(hStream, dwOffset, dwStart, dwEnd, VMA_READ | VMA_WRITE_COPY);</div></ol></div></div></div></div><br>Далее идёт обработка map_stream() в режиме ядра.<br><br>Здесь следует заметить, что handle в любой ОС выполняет ф-цию шлюза, т.е. не позволяет программе подсовывать в ядро произвольные данные, а только то значение, которое ассоциировано с конкретным номером хэндла (как правило, указателем на структуру в пространстве ядра). Когда программа при вызове syscallа передаёт в ядро хэндл, вызываемая ф-ция ядра должна получить вместо него указатель на структуру объекта, связанного с этим хэндлом. Само же ядро не работает с хэндлами, а только с указателями.<br><div class='tag-code'><span class='pre_code'></span><div class='code  code_collapsed ' title='Подсветка синтаксиса доступна зарегистрированным участникам Форума.' style=''><div><div><ol type="1"><div class="code_line">// kernel directs map_stream() syscall to kernelmode function usr_map_stream()&#60;br&#62;// all hanles are translated to its respective kernel struct&#39;s pointers&#60;br&#62;&#60;br&#62;struct vma_s *usr_map_stream (struct stream_s *stream, size_t offset, void *start, void *end, uint flags)&#60;br&#62;{&#60;br&#62; &nbsp; &nbsp;struct vma_s *vma;&#60;br&#62;&#60;br&#62; &nbsp; &nbsp; &nbsp;vma = kmalloc(sizeof(vma_s));&#60;br&#62; &nbsp; &nbsp; &nbsp;vma-&#62;vma.start_addr = start;&#60;br&#62; &nbsp; &nbsp; &nbsp;vma-&#62;vma.end_addr = end;&#60;br&#62; &nbsp; &nbsp; &nbsp;avl_insert_node(¤t_process-&#62;vma_tree, vma);&#60;br&#62; &nbsp; &nbsp; &nbsp;vma-&#62;vma.vtbl = stream_mapping_vtbl;&#60;br&#62; &nbsp; &nbsp; &nbsp;vma-&#62;vma.param = stream;&#60;br&#62; &nbsp; &nbsp; &nbsp;vma-&#62;flags = flags;&#60;br&#62;&#60;br&#62; &nbsp; &nbsp; &nbsp;return vma;&#60;br&#62;}</div></ol></div></div></div></div><br><div class='tag-code'><span class='pre_code'></span><div class='code  code_collapsed ' title='Подсветка синтаксиса доступна зарегистрированным участникам Форума.' style=''><div><div><ol type="1"><div class="code_line">// member function from struct vma_vtbl_s&#60;br&#62;&#60;br&#62;void stream_mapping_page_fault (struct vma_s *vma, void *fault_addr, uint fault_flags)&#60;br&#62;{&#60;br&#62; &nbsp; &nbsp;// if page is not present, get it:&#60;br&#62; &nbsp; &nbsp;// ((struct stream_s *)vma-&#62;param)-&#62;vtbl-&#62;map_page(vma-&#62;param, pos, fault_addr)&#60;br&#62; &nbsp; &nbsp;// to make page to be available&#60;br&#62;&#60;br&#62; &nbsp; &nbsp;// if page is write-protected, generate exception&#60;br&#62;}</div></ol></div></div></div></div><br><div class='tag-code'><span class='pre_code'></span><div class='code  code_collapsed ' title='Подсветка синтаксиса доступна зарегистрированным участникам Форума.' style=''><div><div><ol type="1"><div class="code_line">// system-wide exception handler&#60;br&#62;&#60;br&#62;void page_fault_exception (void *fault_addr, uint fault_flags)&#60;br&#62;{&#60;br&#62; &nbsp; &nbsp;struct vma_s *vma;&#60;br&#62;&#60;br&#62; &nbsp; &nbsp;if (vma = avl_find_node(current_process-&#62;vma_tree, fault_addr))&#60;br&#62; &nbsp; &nbsp; &nbsp; &nbsp;vma-&#62;vtbl-&#62;page_fault(vma, fault_addr, fault_flags);&#60;br&#62; &nbsp; &nbsp;else&#60;br&#62; &nbsp; &nbsp; &nbsp; &nbsp;raise_user_exception(UNHANDLED_PAGE_FAULT);&#60;br&#62;}</div></ol></div></div></div></div>]]></description>
        <author>vilmor</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34259</guid>
        <pubDate>Mon, 06 Oct 2003 17:38:14 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34259</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 06.10.03, 18:08:15</span><div class='quote '>Как и кто будет копировать?  Т.е. кто занимается поддержкой очередей в этом случае?<br></div></div><br>Для очереди получатель создает специальную секцию и сообщает ее ядру.<br>Очередь организуется простейшим циклическим буфером.<br>Ядро копирует сообщения в очередь сразу в момент их отправки.<br>Приложение-получатель теоретически их может читать сразу, но для синхронизации и очистки оно должно использовать системные вызовы, напр. GetMessage.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Считаю от этого способа вполне можно отказаться. Он может быть реализован через 1-ый метод. Поток обработчика сам при надобности будет создавать очередь пришедших сообщений.</div></div><br>Это уже обсуждалось. Именно так сделано в KeyKOS.<br>Но создавать поток на каждое сообщение - все же очень накладно.<br>Поддержка очереди с помощью ядра - на порядок эффективнее.<br>Кроме того, подобную очередь будет реализовывать почти каждый обработчик (в GNU используется термин порт).<br>Считаю, что аргументы в пользу поддержки очереди ядром перевешивают.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Т.е. новому потоку отдается все оставшееся время вызвавшего.</div></div><br>Нет. Просто квота времени вызывающего процесса распределяется теперь и на вызванный поток (поток живет в процессе получателя, но время ему выделяется из ресурсов отправителя).<br>Технически это реализовать несложно: на каждый процесс завести список потоков-&quot;иждивенцев&quot;, и планировщик будет распределять по ним время.<br>Конкретный механизм может быть такой:<br>- на каждом тике берется условная единица ресурса и делится пропорционально приоритетам на процессы, а внутри них - на потоки (приписанные);<br>- выбирается поток с наибольшим запасом ресурса, и ему дается квант и ресурс уменьшается на 1.<br><br>При отправке PostMessage получателю передается фиксированная порция (например 0.001) ресурса. Этого достаточно на минимальную обработку, что гарантирует защиту от спама.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Ну и стоит добавить, что обработку сообщений надо как-то упорядочить. В этом варианте единственный способ - приоритет создаваемого потока зависит от приоритета сообщения.</div></div><br>Приоритет создаваемого потока можно указывать явно, при отправке сообщения.<br><br>А в очередь лучше помещать сообщения в порядке поступления (тем более, что они туда физически пишутся уже в момент отправки).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Предлагаю еще ознакомиться с ядром Mach<br></div></div><br>Да.. немало понаписано..<br>ИМХО, здесь архитектура лучше &nbsp;:D]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34258</guid>
        <pubDate>Mon, 06 Oct 2003 14:57:21 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34258</link>
        <description><![CDATA[rcz: Предлагаю еще ознакомиться с ядром Mach<br><br>http://gnuweb.kookel.org/software/hurd/gnumach-doc/mach.html<br>http://ftp.gnu.org/gnu/gnumach/gnumach-1.3.tar.gz]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34255</guid>
        <pubDate>Mon, 06 Oct 2003 14:08:15 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34255</link>
        <description><![CDATA[rcz: ОК.<br>Согласен. <br>Но не с<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>2) которые помещаются в очередь и потом считываются в уже существовавшем потоке<br>Сообщений второй группы ядро, без ведома получателя, сразу копирует в его очередь, откуда их получатель может считать после, из любого своего потока. <br></div></div><br>Как и кто будет копировать? &nbsp;Т.е. кто занимается поддержкой очередей в этом случае?<br><br>Считаю от этого способа вполне можно отказаться. Он может быть реализован через 1-ый метод. Поток обработчика сам при надобности будет создавать очередь пришедших сообщений.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Но перекидывается квота процессорного времени. То есть планировщик &quot;считает&quot;, что поток как бы принадлежит вызвавшему его процессу, а не тому, в котором он реально выполняется (это, правда, в грубом приближении - нужны будут еще и механизмы &quot;списывания потока с баланса&quot;, но это несущественные детали).</div></div><br>Т.е. на новому потоку отдается все оставшееся время вызвавшего. Тоже не вижу особой необходимости. Причины (рассматриваю асинхронные вызовы, для синхронных все понятно. Вызвавший поток в любом случае засыпает):<br>   - вызываемый поток занимает мало времени (меньше того переданного). Получается вызвавший поток простоит лишнее время, ожидая пока ему выделится время. (Здесь тогда придется рассмотреть передачу процессорного времени обратно, а это не будет просто т.к. теряем из виду вызвавший поток)<br>   - вызываемый поток занимает много времени, т.е. вызвавший поток дождется распределения памяти и будут выполняться обновременно.<br>Поэтому не стоит усложнять жизнь, и не дарить время.<br><br>Ну и стоит добавить, что обработку сообщений надо как-то упорядочить. В этом варианте единственный способ - приоритет создаваемого потока зависит от приоритета сообщения.]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34252</guid>
        <pubDate>Sat, 04 Oct 2003 18:43:40 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34252</link>
        <description><![CDATA[nvm: Любопытная ссылка:<br>http://mrlsd.narod.ru/os.html<br>Тоже предлагается приложениям дать доступ к портам, через БКВВ. Причем по &nbsp;той же схеме: кто раньше попросил, тот и получил, а &quot;опоздавшим&quot; запрет.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34249</guid>
        <pubDate>Sat, 04 Oct 2003 06:16:12 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34249</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 04.10.03, 00:16:22</span><div class='quote '>Действительно компактно. Не подробно. Нет деталей.<br>Какой тип сообщений?</div></div><br>Основных типов сообщений 4, и они разбиты на две группы:<br>1) для обработки которых создается поток,<br>2) которые помещаются в очередь и потом считываются в уже существовавшем потоке.<br>Если есть обработчик (&quot;объект&quot;), то первую группу сообщений он обрабатывает всегда.<br>А очереди он может и не иметь.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>И собственно нет самого способа отправления, передачи данных сообщения из одного контекста в другой (это я предлагал).</div></div><br>Как нет.<br><br>Для отправки сообщения его нужно поместить в стек и сделать syscall. Всё, от клиента больше ничего не требуется. <br>В зависимости от типа сообщения, управление вернется либо сразу, либо по завершению обработки. Если предусмотрено - в стеке по возвращению будет лежать ответ (исходное сообщение оттуда удаляется).<br><br>При обработке.<br>Если это первая группа, то создается поток (карта памяти одна на весь просцесс, только стек новый), в стек которого помещается сообщение. Обработчик удалает сообщение и в стек помещает ответ, после чего командует возврат (завершение потока).<br>Сообщений второй группы ядро, без ведома получателя, сразу копирует в его очередь, откуда их получатель может считать после, из любого своего потока.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>А не нравится, что для отправки сообщения должено создаваться отдельный поток. И так же при обработке сообщения - поток. (Ведб получатель должен обрабатывать несколько сообщений от разный источников сразу).</div></div><br>При отправке потока точно не создается. А при получении - зависит от типа сообщения.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Или вы предлагаете поток перекидывать из одного процесса в другой. Т.е. он сначала принадлижит одному, а потом другому процессу. - Это , сами понимаете, бред.</div></div><br>Нет, сам поток не перекидывается.<br>Но перекидывается квота процессорного времени. То есть планировщик &quot;считает&quot;, что поток как бы принадлежит вызвавшему его процессу, а не тому, в котором он реально выполняется (это, правда, в грубом приближении - нужны будут еще и механизмы &quot;списывания потока с баланса&quot;, но это несущественные детали).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Т.е. без деталей все выглядит компактно, красиво. А когда начинаются уточнения - получаешь исправление архитектуры.<br></div></div>Основные детали уже описаны, согласно архитектуре.<br>Если что упустил - подскажите.<br>]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34246</guid>
        <pubDate>Fri, 03 Oct 2003 20:16:22 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34246</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>..Насчет критики. Я ее никак не дождусь - Вы сразу предлагаете свои варианты, хотя вначале естественно было бы объяснить, что не нравится в уже предложенных.</div></div><br>Не нравится только отсутствия уточнений. Все очень поверхностно и не определено.<br><br>Взять хотя бы это <br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Там все действительно компактно: </div></div><br>Действительно компактно. Не подробно. Нет деталей.<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>1) Для обработки send/fork всегда немедленно создается новый поток, который завершается по окончании обработки. Этот тип сообщений обрабатывается всегда.</div></div><br>Какой тип сообщений?<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>2) Сообщения post/send незаметно для обработчика помещаются в буфер (если таковой есть), и обработчик их может считывать, когда пожелает (из любого своего потока).</div></div><br>И собственно нет самого способа отправления, передачи данных сообщения из одного контекста в другой (это я предлагал).<br><br>А не нравится, что для отправки сообщения должено создаваться отдельный поток. И так же при обработке сообщения - поток. (Ведб получатель должен обрабатывать несколько сообщений от разный источников сразу). (А вам не нравился всего лишь один, в моем варианте).<br><br>Или вы предлагаете поток перекидывать из одного процесса в другой. Т.е. он сначала принадлижит одному, а потом другому процессу. - Это , сами понимаете, бред.<br><br>Т.е. без деталей все выглядит компактно, красиво. А когда начинаются уточнения - получаешь исправление архитектуры.<br>]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34243</guid>
        <pubDate>Fri, 03 Oct 2003 19:52:28 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34243</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 03.10.03, 22:43:49</span><div class='quote '><br>Это скорее упрощение. Нет лишних переключений контекста.</div></div><br>Можно положить, что установка ring влияет и на все вновь создаваемые потоки процесса.<br>..Частое переключение контекста - плата за удобный API.<br>Но есть надежда, что это не так страшно - все переключение гарантированно будет в пределах процессорного кэша.. может и в один такт уложиться (?).. <br>Вообще, это у конструкторов процессора должна болеть голова, как ускорить переключение контекста..<br> <br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Стабильности это не прибавляет. Наоборот. Если процесс (допустим это сервер) больше всех использует потоков и притом очень большое количество. Зачем ему так все гадить.</div></div><br>Тут и работает вторая идея: обработку запросов сервер ведет в счет времени клиента (!). Поэтому сервер нисколько не замедляется.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Для начала, опишите ваши варианты обработки сообщений. Все очень подробно. (а то так их и нет, а только критика)</div></div><br>Все вполне подробно описано в бюллетне, начиная с &quot;Механизм сообщений&quot;.<br>Там все действительно компактно:<br>1) Для обработки send/fork всегда немедленно создается новый поток, который завершается по окончании обработки. Этот тип сообщений обрабатывается всегда.<br>2) Сообщения post/send незаметно для обработчика помещаются в буфер (если таковой есть), и обработчик их может считывать, когда пожелает (из любого своего потока).<br><br>То есть, обработчик ключа состоит из двух элементов: функция обработки (точка входа) и буфер (если создан). Все потоки объекта запускаются с одной точки.<br><br>Тут момент, конечно, получается нестандартный: приложение может быть активным, не имея вообще ни одного потока (даже приостановленного).<br><br>..Может, будут какие уточняющие вопросы? ..А то я уже повторяюсь..<br><br>..Насчет критики. Я ее никак не дождусь - Вы сразу предлагаете свои варианты, хотя вначале естественно было бы объяснить, что не нравится в уже предложенных.<br>]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34239</guid>
        <pubDate>Fri, 03 Oct 2003 18:43:49 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34239</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Зачем такие сложности?! <br>Если процесс имееет право, он может сменить ring простым syscall-ом.</div></div><br>Это скорее упрощение. Нет лишних переключений контекста.<br> <br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>Из требований стабильности и безопасности. <br>Если не квотировать время на весь процесс, то процесс, создавший 1000 потоков в 1000 раз замедлит остальные приложения. <br>В схеме, что я предлагаю, можно безболезненно запустить до 100000 потоков (если больше - могут начаться проблемы). <br></div></div><br>Стабильности это не прибавляет. Наоборот. Если процесс (допустим это сервер) больше всех использует потоков и притом очень большое количество. Зачем ему так все гадить.<br>(Хотя это и получится революционная идея. Ни в одной ОС такого не видел.)<br>Получится лишнее голодание потоков. И участится переключение контекстов- а это затормозит работу.<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Давайте тогда конструктивно определим, какие есть пересечения и в чем можно сотрудничать, что было бы полезно всем участникам.</div></div><br>Для начала, опишите ваши варианты обработки сообщений. Все очень подробно. (а то так их и нет, а только критика)]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34235</guid>
        <pubDate>Fri, 03 Oct 2003 17:28:01 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34235</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 03.10.03, 18:22:34</span><div class='quote '>Интересно откуда это взято.</div></div><br>Из требований стабильности и безопасности.<br>Если не квотировать время на весь процесс, то процесс, создавший 1000 потоков в 1000 раз замедлит остальные приложения.<br>В схеме, что я предлагаю, можно безболезненно запустить до 100000 потоков (если больше - могут начаться проблемы).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Это позволяет просто перейти на другой RING процессора</div></div><br>Зачем такие сложности?!<br>Если процесс имееет право, он может сменить ring простым syscall-ом.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>Я уже писал способ вызова интерфейса. Писал, что это не поток. Это нечто, на него похожее - главное различие - автосброс контекста<br>А подфункции - это если интерфейс еще что-то предоставляет (несколько функций). Тогда он создает другой поток, который возьмет основную работу, а сам вернет управление.<br></div></div><br>Да уж.. понятно, что каждый предпочел бы писать ОС исключительно по своему проекту...<br><br>Давайте тогда конструктивно определим, какие есть пересечения и в чем можно сотрудничать, что было бы полезно всем участникам.<br><br>А альтернативных вариантов API ядра так пока и не представлено. Пока нет полной ясности с интерфейсом, нет смысла обсуждать реализацию.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34233</guid>
        <pubDate>Fri, 03 Oct 2003 14:22:34 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34233</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>То есть если два процесса имеют одинаковый приоритет, то суммарное время, выделяемое на все потоки каждого процесса должно совпасть!</div></div><br> В планировке и распределении процессорного времени учитываются только потоки. Только они исполняются и только они потребляют время.<br><br>А процессорное время - это время существования процесса в системе. Или суммарное время выполнения всех его потоков.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Не понял: мои же слова приведены мне же как возражение... </div></div><br>Приведены, т.к. определяют, что сам процесс не исполняется и не планируется.<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>То есть если два процесса имеют одинаковый приоритет, то суммарное время, выделяемое на все потоки каждого процесса должно совпасть!</div></div><br>Интересно откуда это взято.<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Вы зачем-то отождествляете интерфейс с потоком - хотя это принципиально разные сущности. Одну функцию можно вызвать несколько раз, причем параллельно. То есть один интерфейс может иметь любое число потоков (в т.ч. 0). </div></div><br>Я уже писал способ вызова интерфейса. Писал, что это не поток. Это нечто, на него похожее - главное различие - автосброс контекста (регистров. EIP определяет адрес обработчика). Это позволяет просто перейти на другой RING процессора, выполнить там функцию. Это все, чего я хотел. <br>   И взглянув на проблему сообщений со стороны разработки, просто к этому пришел как к хорошему, простому решению.<br><br>А подфункции - это если интерфейс еще что-то предоставляет (несколько функций). Тогда он создает другой поток, который возьмет основную работу, а сам вернет управление.<br>]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34230</guid>
        <pubDate>Fri, 03 Oct 2003 13:46:27 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34230</link>
        <description><![CDATA[nvm: Похоже, обсуждение начинает упираться в личные предпочтения.<br>Или в интуитивные оценки, которые нельзя доказать, пока не напишешь под них реализацию VC++ и Office и не увидишь, где это проще..<br><br>Если какие-то варианты не удается согласовать, но, видимо, единственный вариант продолжения работы - включить их объединение.<br><br>Также предлагаю определиться, что мы пишем пока не систему, а только некоторый прототип для дальнейших исследований и использования как базы для настоящей(их) ОС.<br><br>И еще организационное предложение.<br>Если кто имеет принципиальные возражения против спецификации (несовместимые с общей идеологией интерфейса ядра), то прилагайте к ним свои ПОЛНЫЕ версии интерфейса (функций ядра). Потому что предложения имеют смысл только в контексте.<br><br>Желательно также оформлять такие предложения в структурированном виде (html). Тогда можно сделать сайт, на котором структурированно оформить все варианты с дискуссией - такая документация имела бы самостоятельную ценность, независимо от создания кода.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34227</guid>
        <pubDate>Fri, 03 Oct 2003 13:21:03 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34227</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 03.10.03, 14:34:02</span><div class='quote '><br>Интерфейс в потоке. Если он содержит подфункции - то это уже его проблема как обрабатывать.</div></div><br>При чем здесь подфункции?!<br>Вы зачем-то отождествляете интерфейс с потоком - хотя это принципиально разные сущности. Одну функцию можно вызвать несколько раз, причем параллельно. То есть один интерфейс может иметь любое число потоков (в т.ч. 0).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>И процессорного времени как понятия нет.</div></div><br>Это как??? Основного ресурса системы - и нет?<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Выполняются потоки, а не процессы. Процесс - только адресное пространство.</div></div> Не понял: мои же слова приведены мне же как возражение...<br><br>Квотироваться-то должны процессы!!<br>То есть если два процесса имеют одинаковый приоритет, то суммарное время, выделяемое на все потоки каждого процесса должно совпасть!<br>И важно, что если процесс запускает поток в чужом процессе, то он тратит на это собственный ресурс.<br>В пределах процесса потоки также могут иметь свой относительный приоритет.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Рассмотри поглубже, на уровне реализации. И увидешь, что тоже появится RPC, новые потоки.</div></div><br>Нет.<br>ВСЕ, что нужно уже отражено в спецификации. По крайней мере то, что нужно для решения всех обсуждавшихся проблем. Конечно, наверняка есть что-то, что еще не упоминалось.<br>Имеется в виду, что отражены вопросы интерфейса: взаимодействия объектов с ядром и между собой.<br>Внутренняя архитектура ядра продумана слабо, и там, конечно, появятся новые объекты (о которых снаружи не будет ничего известно)... но уж точно не потоки.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34224</guid>
        <pubDate>Fri, 03 Oct 2003 10:34:02 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34224</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>- в каждой задаче, по сравнению с моей (точнее, KeyKOS) схемой, один лишний поток - всегда ровно на один поток больше;</div></div><br>В этом не вижу ничего страшного. <br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>- все бремя управления потоками ложится на приложение;</div></div><br>Интерфейс в потоке. Если он содержит подфункции - то это уже его проблема как обрабатывать.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>- принципиальный недостаток: обработка сообщений производится всегда в счет процессорного времени получателя, что нехорошо.</div></div><br>Что ж в этом плохого. В асинхронноых вызовах это всегда так будет, а синхронные - не важно кто будет тратить время.<br>И процессорного времени как понятия нет. Есть только время выполнения потока. Процессорное время - это время выполнения первого потока. Выполняются потоки, а не процессы. Процесс - только адресное пространство.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>То, что я предлагаю, гарантирует, что при таком обращении процесс получит результат ровно тогда же, как если бы он его вычислял сам.</div></div><br>Рассмотри поглубже, на уровне реализации. И увидешь, что тоже появится RPC, новые потоки.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>..чем меньше сущностей - тем лучше.. а тут еще какие-то специальные обработчики прерываний..</div></div><br>Правильно. Пока прерывания попадают под общее определение объекта интерфейса. Но т.к. прерывания сами по себе отдельная сущность, их придется рассмотреть отдельно (хотя бы в целях оптимизации)<br>]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34221</guid>
        <pubDate>Thu, 02 Oct 2003 18:51:30 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34221</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 02.10.03, 22:00:59</span><div class='quote '>Если рассматривать прерывания - это все будет отдельно. Можно сделать отдельный объект обработки прерываний.</div></div><br>..чем меньше сущностей - тем лучше.. а тут еще какие-то специальные обработчики прерываний..<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Та схема, что я привел, тоже заменяет (или как раз определяет) все эти вызовы, прерывания и т.п.<br>И реализация мне кажется очень простой.<br>И очень хорошо накладывается на планирование задач, приоритеты (механизм тот же. Приоритет именно по сообщениям). </div></div><br>Да.. доказать, что на самом деле красивее - невозможно..<br><br>Но даже объективно в Вашей схеме есть недостатки (&quot;некомпенсированные&quot;, остальное равноценно):<br>- в каждой задаче, по сравнению с моей (точнее, KeyKOS) схемой, один лишний поток - всегда ровно на один поток больше;<br>- все бремя управления потоками ложится на приложение;<br>- принципиальный недостаток: обработка сообщений производится всегда в счет процессорного времени получателя, что нехорошо.<br>Предположим, что высокоприоритетный процесс обратился к низкоприоритетной библиотеке для вычисления некой функции. И он будет ждать, пока эта библиотека со своим низким приортетом дождется кванта времени. И в этом будет отличие от функционального вызова.<br>То, что я предлагаю, гарантирует, что при таком обращении процесс получит результат ровно тогда же, как если бы он его вычислял сам.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34218</guid>
        <pubDate>Thu, 02 Oct 2003 18:00:59 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34218</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Но при этом он еще ждет и начала обработки - это стандартный SendMessage. <br>Но такой тип сообщения не эквивалентен вызову функции, поэтому чтобы предоставить аналог межзадачного функционального вызова нужен доп. тип сообщения.</div></div><br><br>Если рассматривать прерывания - это все будет отдельно. Можно сделать отдельный объект обработки прерываний.<br><br><br>А если в обычный процесс - ожидать норамально. Приоритет задачи тоже ведь всегда учитывается. Во всех ОС ожидается. Да и с обычным GetMessage будет ожидаться хотя бы переключение на контекст объекта (а это может очень долго не происходить, если приоритет очень маленький)<br><br>Если это сообщение пришло от прерывания - оно имеет приоритет, соответствующий этому прерыванию, и выше пользовательского, что обеспечивает его выполнение.<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Это нагружает ядро задачей упорядочивания сообщений. Более того, получим новую сущность: приоритет сообщения - в этой схеме это будет не совсем то же, что приоритет потока.. </div></div><br>Можно сделать, что приоритет сообщения = приоритету потока. А можно просто ввести дополнительное поле в сообщении - приоритет создаваемого потока.<br>Да и это совсем не нагружает ядро. Это определяет само планирование задач и уже обсуждалось.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Убрать его вообще - и не мучиться.</div></div><br>не писать ничего. и точно не мучиться :).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Чем? <br>Выглядит очень стройной. <br>Конечно, это лишние разновидности сообщений - зато они заменяют прерывания, межзадачные вызовы и порождение потоков.</div></div><br>Та схема, что я привел, тоже заменяет (или как раз определяет) все эти вызовы, прерывания и т.п.<br><br>И реализация мне кажется очень простой.<br>И очень хорошо накладывается на планирование задач, приоритеты (механизм тот же. Приоритет именно по сообщениям).]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34215</guid>
        <pubDate>Thu, 02 Oct 2003 17:34:43 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34215</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 02.10.03, 19:01:03</span><div class='quote '><br>И еще как годится. Синхронность - вызвавший процесс ждет получения ответа, завершения обработки.</div></div><br>Но при этом он еще ждет и начала обработки - это стандартный SendMessage.<br>Но такой тип сообщения не эквивалентен вызову функции, поэтому чтобы предоставить аналог межзадачного функционального вызова нужен доп. тип сообщения.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Честно говоря, мне не нравится идея ForkMessage.</div></div><br>Чем?<br>Выглядит очень стройной.<br>Конечно, это лишние разновидности сообщений - зато они заменяют прерывания, межзадачные вызовы и порождение потоков.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Первоначально приоритеты учитываются ядром, при постановки сообщения в очередь интерфейсу. И вызывается обработчик самого приоритетного.</div></div><br>Это нагружает ядро задачей упорядочивания сообщений. Более того, получим новую сущность: приоритет сообщения - в этой схеме это будет не совсем то же, что приоритет потока..<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>И поток интерфейса - это не совсем обычный поток. У него контекст всегда сбрасывается. Это будет отдельный объект ядра.</div></div><br>Убрать его вообще - и не мучиться.<br>]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34211</guid>
        <pubDate>Thu, 02 Oct 2003 15:01:03 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34211</link>
        <description><![CDATA[rcz: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Это - классическая схема. <br>Но для обработки прерываний она не годится (синхронных сообщений). <br>Поэтому нужны RunMessage, а в KeyKOS подсказали хорошую идею добавить и ForkMessage.</div></div><br>И еще как годится. Синхронность - вызвавший процесс ждет получения ответа, завершения обработки.<br><br>Честно говоря, мне не нравится идея ForkMessage.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>&gt;Получается такой механизм <br>&gt;В обработчик сообщения(остановленный тред) передается очередное сообщение ?<br>&gt;(очередью управляет ядро). Этот обработчик создает новый тред, передав ему &gt;параметр-сообщение, а ядру возвращается MESSAGE_PENDING. Если это асинхронный &gt;вызов, вызвавший тред пробуждается. <br><br>У этой схемы серьезные недостатки. <br>Главное - не гарантируется мгновенная обработка приоритетных сообщений.</div></div><br>Первоначально приоритеты учитываются ядром, при постановки сообщения в очередь интерфейсу. И вызывается обработчик самого приоритетного.<br><br>А приоритет потока, то зачем ставить выше? Да и можно сделать, что поток интерфейса будет наследовать некоторые параметры вызываемого (например приоритет), или приоритет будет зависеть от приоритета сообщения, что лучше.<br><br>Так. И поток интерфейса - это не совсем обычный поток. У него контекст всегда сбрасывается. Это будет отдельный объект ядра.<br><br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Дело в том, что приложения идентифицируют секцию по хэндлу, так что указателями на секции не обойтись.</div></div><br>Правильно. Приложения всегда будут работать с хэндлами. Но ядро &nbsp;- лучше указатели. (повторюсь, что не для всего). Но для секций было бы очень удобно.]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34208</guid>
        <pubDate>Thu, 02 Oct 2003 14:40:45 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34208</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>rcz, 02.10.03, 11:49:26</span><div class='quote '>Механизм обработки сообщений. Как происходит?<br>(Передача их еще понятна. Ядро по ключу находит процесс, отвечающий за интерфейс, и адрес обработчика).</div></div><br>Механизм принципиально отличается для разных типов сообщений.<br>1) Post/SendMessage.<br>Сообщение ставится в очередь, где ждет вызова GetMessage().<br>Если очередь пуста, то вызов GetMessage() приостанавливает поток до поступления сообщения (зависит от параметра времени ожидания).<br>Если у обработчика не создана очередь сообщений (или переполнена), то отправителю сообщается об ошибке.<br>2) Fork/RunMessage.<br>Создается новый поток, который немедленно запускается с адреса обработчика.<br>В стеке потока лежит сообщение (и больше ничего нет).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '> Интерфейс - остановленный тред. При получении сообщения, он активизируется. </div></div><br>Это - классическая схема.<br>Но для обработки прерываний она не годится (синхронных сообщений).<br>Поэтому нужны RunMessage, а в KeyKOS подсказали хорошую идею добавить и ForkMessage.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Можно сделать, что именно при объевлении интерфейса создается контекст треда</div></div><br>Один интерфейс может содержать несколько тредов одновременно!<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Получается такой механизм<br>В обработчик сообщения(остановленный тред) передается очередное сообщение (очередью управляет ядро). Этот обработчик создает новый тред, передав ему параметр-сообщение, а ядру возвращается MESSAGE_PENDING. Если это асинхронный вызов, вызвавший тред пробуждается. </div></div><br>У этой схемы серьезные недостатки.<br>Главное - не гарантируется мгновенная обработка приоритетных сообщений.<br><br>И еще момент, тоже важный:<br>Когда тред создает сам обработчик, он ему может присвоить приоритет не выше собственного.<br>Но логичнее, если приоритет ставит вызывающий процесс, согласно своим полномочиям (которые могут быть и выше).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '> Хэндлы и указатели. и<br>Использование того или иного в конкретном случае будем рассматривать отдельно и желательно на готовом ядре(измерять производжительность будем).</div></div><br>ОК<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>И для ядра часто(не всегда) удобней работать не хэндлами, а указателями. Т.е. оно сначало получает указатель объекта, а потом с ним работает. Так должно быть с секциями памяти.</div></div><br>Дело в том, что приложения идентифицируют секцию по хэндлу, так что указателями на секции не обойтись.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34205</guid>
        <pubDate>Thu, 02 Oct 2003 14:40:06 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34205</link>
        <description><![CDATA[nvm: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>Vilmor, 02.10.03, 10:40:56</span><div class='quote '><br>Хых... когда не ведаешь, что было сделано задолго до тебя, то и впрямь чувсвуешь себя первооткрываетелем :D</div></div><br>Это ведь было в шутку - насчет революционности. В наше время новое придумать почти нереально.. но все равно полезнее самому дойти до идеи, чем взять ее готовой...<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>Определение секций на уровне ядра совсем ни к чему. Никаких структур и дескрипторов не нужно. Ядро работает только с Virtual Memory Areas в юзерном пр-ве процесса.</div></div><br>Чем Ваш VMA отличается от секций? Может, опишете существо?<br><br>Здесь секция - универсальная абстракция для области памяти.<br>В x86 секция по-хорошему должна поддерживать в полном объеме возможности сегментов - а на других платформах позволять без сегментов обходиться.<br>Секция по смыслу похожа на сегмент (и призвана его эмулировать на платформах, где он не доступен). А сегмент - сущность процессора, то есть самого низкого уровня, так кому, как не ядру ее поддерживать?!<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '> В этом случае, секция стека - всего лишь отдельная VMA с правами страниц на READ/WRITE, ... и для секции стека не нужно изобретать ещё одну сущность, поскольку это такая же секция, что и код и данные, олько с разными правами доступа.</div></div><br>В идеале, стек - это объект с интерфейсрм всего их двух функций: push и pop. И ему вообще не нужно адресное пространство. То, что в современных архитектурах ему приходится выделять адреса - это технические издержки.<br>Это аргумент в пользу выделения стека в отдельную сущность.<br>Еще особенность - стек логически привязан к потоку, в то время как остальные секции - к задаче.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>К тому же, если у процесса несколько тредов, то тогда ОС безразлично, как программа выделяет память для стеков - в одной секции или в нескольких. Программа, создавая тред, сама выделяет память для его стека.</div></div><br>Изначально я так и предполагал.<br>Но проблема в том, что тред может быть создан извне другим процессом, который не может смонтировать стек в данном процессе (см. пост 230).<br>Потом, поддержка потоков - это все-таки ведение ядра, и нехорошо загружать этими низкоуровневыми проблемами приложения.<br><br>Насчет &quot;клонированных стеков&quot; в одном сегменте - эта идея, думаю, на самом деле совершенно новая и нигде не опробованная. Поэтому у меня самого нет в ней полной уверенности, но предварительно выглядит привлекательной.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>И это не единственное осложнение, которое у вас появится, если вы будете и дальше отказываться от модели пулов тредов, которая на самом деле, проще, красивее и эффективнее в реализации, </div></div><br>Может, Вы бы описали ее немного подробнее (можно с фрагментами из других источников) - и есть смысл сделать сайт, на котором привести не только выбранную архитектуру, но и вообще все рассмотренные варианты, а также полезную информацию.<br>Пока можно выложить у меня, а если получится серьезный материал - можно найти более подходящий хост.<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Делая так, вы таким образом выкидываете из уровня ядра ненужный хлам на уровень приложения.</div></div><br>И заваливаем этим хламом приложение..<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Поймите, монолитность ядра - это не то, когда к нему статически прилинкованы драйверы и проч. модули. Это когда само ядро не может обходиться без них или учитывает специфику некоторых из этих модулей.</div></div><br>И что?.. Разве кто-то предлагал что-либо, вызывающее зависимость ядра от модулей??<br>Есть одна зависимость: для реализации подкачки ядро вынуждено обращаться к драйверу диска - но это исключение неизбежно и единственно.<br><br>Но микроядро - не означает простое. У него обязан быть простым интерфейс (содержать малое число сущностей и методов). А реализация может быть очень нетривиальной.<br>Я бы ожидал размер исходников ядра около 50кб, то есть где-нибудь 30кб после компиляции - но это был бы очень сложный код. Но для ОС всегда стоит пойти на сложность реализации ради простоты использования.]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34202</guid>
        <pubDate>Thu, 02 Oct 2003 07:49:26 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34202</link>
        <description><![CDATA[rcz: 1)Объекты (процессы, драйвера) содержат интерфейсы-методы(непосредственно функции обработки).<br><br>Механизм обработки сообщений. Как происходит?<br>(Передача их еще понятна. Ядро по ключу находит процесс, отвечающий за интерфейс, и адрес обработчика).<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '>Для вас такая схема неудобна, поскольку ядро само создаёт тред для обработки пришедшего в процесс сообщения. И это не единственное осложнение, которое у вас появится, если вы будете и дальше отказываться от модели пулов тредов, которая на самом деле, проще, красивее и эффективнее в реализации, да к тому же, м.б. совершенно прозрачна для прикладного программиста - достаточно сделать ф-цию GetMessage() по проинципу fork(), (однако, она будет не syscallом, а библиотечной ф-цией).</div></div><br><br> Интерфейс - остановленный тред. При получении сообщения, он активизируется. (параметры - данные ключа). Можно сделать, что именно при объевлении интерфейса создается контекст треда (точнее TSS) и он не изменяется (для всех вызвов одинаков, т.е. потом при активизации потока он дублируется).<br><br>Получается такой механизм<br><br>В обработчик сообщения(остановленный тред) передается очередное сообщение (очередью управляет ядро). Этот обработчик создает новый тред, передав ему параметр-сообщение, а ядру возвращается MESSAGE_PENDING. Если это асинхронный вызов, вызвавший тред пробуждается. <br><br>Поток интерфейс уходит в спячку(ждет очередного сообщения). А возврат результата берет на себя тред обработчика.<br>Асинхронные сообщение - ответ посылается отдельным сообщением(обработку берет на себя вызвавший тред. )<br><br>2) Хэндлы и указатели. и<br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <div class='quote '><br>&gt; &nbsp;list&lt;.... &nbsp;<br>Все-таки, почему list, если жизненно необходим vector ?! <br>Все эти структуры адресуются через хэндл, то есть индекс, поэтому нужен массив.</div></div><br>list - удобней добавлять, удалять и т.п. Без лишних выделений, перемещений. Удобней искать (двунаправленный список можно преобразовать в дерево поиска). <br>vector - тоже можно. Но если разервировать память с запасом - часто лишний расход памяти. Меньше зарезервировать памяти - чаще все придется переносить. Использование того или иного в конкретном случае будем рассматривать отдельно и желательно на готовом ядре(измерять производжительность будем).<br><br>И для ядра часто(не всегда) удобней работать не хэндлами, а указателями. Т.е. оно сначало получает указатель объекта, а потом с ним работает. Так должно быть с секциями памяти.<br><br>]]></description>
        <author>rcz</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34199</guid>
        <pubDate>Thu, 02 Oct 2003 06:40:56 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34199</link>
        <description><![CDATA[vilmor: <div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 30.09.03, 19:19:33</span><div class='quote '>3) Уже в исходной спецификации я предлагал революционную  8) ;D идею, что при выделении памяти процессу не ядро выбирает виртуальный адрес, по которому будет видна эта память - а сам процесс передает его как входной параметр!</div></div>Хых... когда не ведаешь, что было сделано задолго до тебя, то и впрямь чувсвуешь себя первооткрываетелем :D<br><br><div class='tag-quote'><span class='tag-quote-prefix'>Цитата</span> <span class='tag-quote__quote-info'>nvm, 01.10.03, 18:49:31</span><div class='quote '><br>..Ну как не революционная: обычно malloc возвращает адрес, а у тут - адрес (виртуальная структура сегмента) ей передается на входе.<br></div></div>Ну так malloc() к ОС имеет весьма отдалённое отношение. В конечном счёте, вызывается syscall, которому передаётся адрес и размер области, куда мэпится выделенная память.<br><br>Определение секций на уровне ядра совсем ни к чему. Никаких структур и дескрипторов не нужно. Ядро работает только с Virtual Memory Areas в юзерном пр-ве процесса. В этом случае, секция стека - всего лишь отдельная VMA с правами страниц на READ/WRITE, в которую спроецирована реальная память, причём те страницы, в которых ещё не было записи данных, реально указывают на единственную в системе физическую страницу, затёртую нулями. Значит, 4Мб стек может реально занимать очень мало памяти, и для секции стека не нужно изобретать ещё одну сущность, поскольку это такая же секция, что и код и данные, олько с разными правами доступа.<br><br>К тому же, если у процесса несколько тредов, то тогда ОС безразлично, как программа выделяет память для стеков - в одной секции или в нескольких. Программа, создавая тред, сама выделяет память для его стека.<br><br>Для вас такая схема неудобна, поскольку ядро само создаёт тред для обработки пришедшего в процесс сообщения. И это не единственное осложнение, которое у вас появится, если вы будете и дальше отказываться от модели пулов тредов, которая на самом деле, проще, красивее и эффективнее в реализации, да к тому же, м.б. совершенно прозрачна для прикладного программиста - достаточно сделать ф-цию GetMessage() по проинципу fork(), (однако, она будет не syscallом, а библиотечной ф-цией).<br><br>Если не нравится GetMessage(), и хочется, чтобы сразу вызывалась ф-ция обработки сообщения, то и это ничего не меняет, и всё можно сделать по тому же принципу.<br><br>Делая так, вы таким образом выкидываете из уровня ядра ненужный хлам на уровень приложения.<br><br>Поймите, монолитность ядра - это не то, когда к нему статически прилинкованы драйверы и проч. модули. Это когда само ядро не может обходиться без них или учитывает специфику некоторых из этих модулей.<br><br>Даже когда много модулей работает в режиме ядра, само ядро может оставаться микро- или наноядром.]]></description>
        <author>vilmor</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      <item>
        <guid isPermaLink='true'>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34196</guid>
        <pubDate>Wed, 01 Oct 2003 18:38:57 +0000</pubDate>
        <title>Разработка концептуально новой ОС</title>
        <link>https://forum.sources.ru/index.php?showtopic=2080&amp;view=findpost&amp;p=34196</link>
        <description><![CDATA[nvm: Начата работа над сайтом системы:<br>http://www.ios.ru/~nvm/index.html<br>]]></description>
        <author>nvm</author>
        <category>Обсуждаем новые идеи</category>
      </item>
	
      </channel>
      </rss>
	