OSDev

Я не имел ввиду, что нужно использовать mdb буквально. Только как модель хранения.

Соотвественно, вирусы тут тоже ни причём. Но, вообще говоря, я упустил, что у объектов могут быть и методы, т.е. программный код. Естественно, проверку программного кода никто не отменял.
И при традиционном подходе вместе с файлом может прийти вирус. Возьмём хотя бы файлыв рисунков jpg. Ведь там, насколько я помню, код для распаковки вшит в файл. И ничего, все довольны. Не ропщут. Или sfx-файлы. Т.е. само по себе изменение способа хранения данных не приводит к повышению вирусоопасности.

Собственно mdb с ходу использовать нельзя, поскольку там имеются чисто технологические ограничения.



Файлы нужно также рассматривать как объекты. Соотвественно, их также можно хранить в единой базе.
Если хранить в базе только поля, то, соотвественно, бинарные данные оформляются в виде файлов.
Я думаю, что нужно единообразие - всё хранить в базе.
Бинарные данные - это тоже поля, только большего размера. Всего-навсего.
А если объект содержит несколько полей большого размера? Вот, скажем, берём html документ с картинками. При традиционном подходе это будет несколько файлов. Но можно считать это единым объектом, у которого несколько свойств, содержащих данные существенного размера.

Изучили б тему получше, что ли... Никакого исполняемого "кода для распаковки" в jpg и других упакованных файлах нет (за исключением самораспаковывающихся архивов, но они с точки зрения системы являются обычными исполняемыми файлами).

Хотя этой идее лет 50 (с момента возникновения БД), но т.к. ни кто её не реализовал, она остаётся интересной и актуальной. Эксперимент в принципе имеет смысл.

Наверно и модульное ядро можно записать в критерий №1, в дополнение к экзоядру.
Кстати, я тут немного узнал про экзоядро из книги Таненбаума "Операционные системы. Разработка и реализация" (есть на торрент серверах). Экзоядро можно сказать противоположность клиент-серверной модели. Оно не работает с ресурсами, а только разграничивает их на непересекающиеся участки. Каждое приложение получает свой отрезок адресного пространства (секторов на диске, оперативной памяти и т.д.), поэтому коллизии не происходят, и ядру ничего не приходится делать. Это даёт неплохую скорость работы, т.к. каждое приложение работает со своими ресурсами напрямую, как в ДОС. Каждую задачу можно считать как отдельную "систему" со своими независимыми ресурсами.

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

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

Нет, нужно просто напрячь мозг и подумать, как это можно реализовать руководствуясь идеями экзоядра и покопать информацию как это реализовано в тестовой экзоядерной ос

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

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

Действительно, пусть автор поделится, что есть экзоядро в его представлении.

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