Эксперимент

[SfS]

народ восставал против NMI по той причине что не надо вмешиваться в аппаратуру. имхо модульная структура позволит использовать все что угодно.

NMI - это идеальный вариант. МОжно и стандартный INT - это не принципиально. Так что если "народ восставал" - то пусть юзают стандартный INT. Но тогда зависшую после DI программу - не снимешь без рестарта. Впрочем - можно написать поддержку и NMI и INTа - пусть кому что нравится юзают.

а с другой стороны практически полное отсутствие защиты от несанкционированной записи в ядро

Ну это уж не проблема. Кому очень захочится такой защиты - могут сделать порт блокировки записи в нижние 16к ОЗУ. Или лучше - порт, который позволяет блокировать запись в любую из 4х страниц. Большинству же это поровну. ИМХО, для большинства - прошить ПЗУ большая проблема, нежели мириться с отсутствием защиты.

для того чтобы скомпилять ядро того же линукса не обязательно быть крутым кулхацкером. и это несмотря на то что оно в исходах. компилятор все делает по скриптам за тебя. и никакой мороки

Ну это кому как удобнее. Совершенно непринципиальный вопрос.

ну должен поддерживаться стандартный джентльменский набор IPC: семафоры, критические секции, сигналы, каналы

В иделае - да. Но надо начинать с минимума. ИМХО, минимум - это разделяемая память, стандартный интерфейс драйверов и менеджер задач. Если пытаться реализовать все сразу - то только мороки больше будет.

выделять по 16 кило на процесс- слишком жирно. плюс желательно предусмотреть возможность использования одного куска кода разными процессами (тогда можно будет делать fork и не ломать голову с нитями)

Сразу в стандарте POSIX мыслишь ? ))) МОжет форки и нити на чуть потом оставим ?)
Я и не собирался 16К на процесс выделять. В ядре хранится таблица свободных странц и для каждой страницы есть флаг - занята она целиком под процесс или частично. Если целиком - то все понятно. А если частично - то на странице присутствует структура, типа локальной кучи. Таким образом на странице может быть много процессов.

у меня были такие идеи. вся верхняя память делится по блокам, при загрузке процесса выделяется место под его код и еще немного (сколько надо) под локальную память, которая распределяется статически самим процессом (хотя можно и системный менеджер кучи прикрутить). если процессу надо много памяти, он запрашивает систему и она выделяет память. правда доступ лучше реализовывать через буфер- доступ к верхней памяти по блокам. хоть тут есть один жирный минус- довольно большие затраты, зато много плюсов- не нужны резиденты в нижней памяти (их роль на себя берет система), на систему также можно возложить остальные операции по перемещению/копированию памяти (пускай делает это как ей удобно), контроль на запись данных (хранить контрольную сумму блока), возможность использования общей памяти с функцией copy-on-write.

Тут подходов может быть несколько. Не на всех компах все сработают. Скажем там где можно щелкать не только последние 16К памяти - все упрощается. На 128й стандартной машине - вообще сложно сделать нормально по быстродействию. Моя точка зрения - надо делать все по минимуму. Тогда быстрее будет виден результат. А затем уже дополнять чего не хватает.

Короче так или иначе - надо ориентироваться на 128к - стандарт как минимум. Для навороченных машин типа ATM - другой менеджер памяти однозначно нужен.