OSDev

Ну, да:
Хотя в приведенной тобой цитате я подразумевал еще более продвинутый механизм, а именно подкачку по требованию. Т.е. я обычно даже в новом процессе не загружаю код/данные сразу. Но это можно сделать позже. Тем более что полная загрузка тоже бывает нужна (я по крайней мере при опред. условиях ее делаю).

Сейчас остро встал вопрос о том, что если приложению нужна, например, функция вывода на экран, то приходится компоновать с ним соответствующий объектный модуль. Настоящий ад зависимостей. Путем декомпозиции библиотек из которых собрано ядро, удалось отделить зерна от плевел и уменьшить объем кода приложения раза в 4. Однако есть явно системные функции, типа выделения физических фреймов при создании того же ВАП процесса, и структуры отвечающие за это необходимы в одном экземпляре. Статическая (да и динамическая линковка) создаст несколько не связанных структур. То есть уже на данном этапе надо задуматься о механизме IPC. Необходим механизм обмена сообщениями между ядром и приложениями.

Нужно заняться синхронизацией доступа к структурам ядра. Мне не нравятся твои cli/sti с достаточно большим объемом кода между ними. Еще не очень нравится мьютекс, сильно смахивающий на спин-блокировку.

Также нужно заняться разработкой системного сервиса. Прежде чем делать консольные функции, нужно подумать, как будут работать виртуальные консоли. По-моему не следует тащить в ядро все подряд лишь на том основании, что это используется в большинстве приложений. Если что-то может эффективно работать на прикладном уровне, пусть оно там и остается, пусть даже на первых порах используются статические либы - когда сможешь, сделаешь динамические.

При рассмотрении IPC не мешает подумать и о взаимодействии между родительскими и дочерними процессами.

Разработку механизма сообщений можно начать с посылки/приема клавиатурных сообщений (в дальнейшем я могу использовать другую терминологию: события, событийные пакеты).

Да, действительно, если глянуть реализацию спинлоков в той же Вики - один в один. Это я у KIV "спёр".

Собственно за счет такого разделения кода я и сократил объем компонуемого с приложением библиотечного кода примерно в 4 раза. в итоге от большой библиотеки разных функций common остался насегодня только вот такой ашник

Всё растащил по соответствующим библиотекам.

Сами сообщения - как я мыслю - это обмен данными между процессами через какую-то определенную область памяти? Так или иначе, как бы механизм IPC не назывался, сокетом там или именованым каналом - технически всё равно через память, которую видят все взаимодействующие процессы?

Нет, участвующие процессы совсем не обязаны видеть эту область памяти _одновременно_, хуже того, они её могут вообще не видеть напрямую (пример - pipe/fifo в линухе, ну и сокеты, да).

Таки я бы не смешивал в кучу обмен через shared memory, приколы типа передачи страниц (страница отцепляется от ВАП одного процесса и прицепляется к ВАП другого, соотв. ничего не нужно никуда копировать, можно устроить гарантию что эта область не будет модифицирована внезапно для работающего с ней процесса) и вещи когда сами процессы к буферу вообще доступа прямого не имеют (а подчас может и буфера не быть) - типа pipe/fifo/сокетов/сообщений.
Это разные вещи с т.з. организации доступа и соотв-но того что и как с помощью них можно делать (например, shared memory через сеть - очень плохая идея, а сокеты - норм, но сокеты локально - уже не слишком круто, ибо double-copy, хотя с shared-memory тоже может возникать необходимость double-copy и порой задумываешься о передаче страниц, такое во встроенке не редкость, да и в микроядрах, вроде).

Тогда непонятно как технически, скажем один байт, из ВАП одного процесса попадает в ВАП другого? На примитивном уровне - один процесс куда-то этот байт кладет, другой его оттуда берет. Я не говорю о том что каждый из процессов видит эту область памяти непосредственно, но она реально где-то существует, за наворотами абстракций?

На техническом уровне буферов по пути может быть неведомо сколько (пример - сокеты), а может у нас pipe и ситуация что процесс 2 заблочился на вызове read из трубы, процесс 1 в это время вызвал write чтобы что-то передать процессу 2 через этот pipe. Так ядро может не париться и сразу из памяти 1 прочесть и записать в целевой буфер у 2.

Хотя, конечно, в реальности pipe обычно выглядит как кольцевой буфер в пространстве ядра, ну а вызовы read/write берут из/кладут в него, либо блокируются до лучших времён, т.е. этот твой желанный буфер таки чётко выделяется.
С сокетами (да что там сокеты, можно вот MPI вспомнить) сложнее, там по пути и куча буферов (сетевой стек, DMA, различные сетевые железки) может быть, и среда передачи.

Так вот, не всё то навороты абстракций, что слои. Эти разные примитивы нужны не для красоты, а чтобы не стрелять из пушки по воробьям и можно было некоторые оптимизации работы делать с учётом знания о том что и как в программе предполагается вертеть. Ну и для удобства, да.

Короче говоря, мне придется всерьез заняться дизайном ядра. Поигрался с фичами и хватит. Пора писать операционную систему.
Блог пока приостановлю. Перепроектирую ядро - тогда продолжу. Будет, как это сейчас модно, "второй сезон"

Передача сообщения между процессами как мне видится выглядит так.
Мы пишем данные в буфер программы вызываем сервис ОС который просто копирует эти данные из одного процесса в другой. Технически ядро отображает память обоих процессов, не всю а кусок. И просто копирует.

Не вижу необходимости в создании буфера для pipe в пространстве ядра. Вполне можно хранить в программе организующей терминал или делать общий кусок памяти.

У разных элементов разное назначение. При использовании сообщений передающая и принимающая стороны не имеют прямого доступа к памяти, через которую происходит передача. Они работают с небольшим количеством передаваемых/получаемых данных, представленных в виде параметров функций передачи/получения сообщений. Могу рассказать, как это реализовано у меня. В моей реализации этот механизм является частью консольной подсистемы, поэтому событийные пакеты могут отправляться не любому процессу, а только переднеплановому (в перспективе одному из нескольких переднеплановых, если я когда-нибудь сделаю поддержку нескольких физических консолей). Событийная очередь у меня пока только одна - она обслуживает любой текущий переднеплановый процесс, располагается в пространстве ядра, реализована в виде статического кольцевого списка. Когда происходит смена переднепланового процесса, очередь "сбрасывается", т.е. очищается и в нее помещается событие EI_RESET. При переполнении очереди также происходит сброс. Событийные пакеты помещаются в очередь синхронно и накапливаются в ней. Есть функция ResetEvent, которая позволяет заменить в очереди последний помещенный пакет, если он совпадает по типу с помещаемым этой функцией в данный момент пакетом. К примеру может быть использована для событий от мышки, чтобы в очереди не накапливались смежные пакеты движения мышки даже при очень высокой частоте прихода соотв. прерываний - драйверу нет необходимости отслеживать эту ситуацию, достаточно просто для движений использовать функцию ResetEvent. В принципе событийные пакеты могут спокойно передаваться и в рамках одного процесса. WaitEvent на пустой очереди будет переводить поток в состояние ожидания. Для заднеплановых процессов очередь всегда представляется пустой.