> И откуда вы с виртуализатором выясните, где у вас идёт обращение к
> памяти ядра, но не принадлежащей этому драйверу?В теории, виртуализатор может стопроцентно мониторить всю память. На практике понятное дело есть куча факторов, в том числе и само оборудование, которое само может данные в память гонять через DMA "как драйвер запрограммит" и прочие прелести, позволяющие поставить колом систему не столь очевидными но не менее невкусными марштурами. С другой стороны эти факторы и микроядро с драйверами в юзермоде так же поставят колом. Ну вон например драйвера GPU. Ну тот же радеон, пускай. Его основной бич - GPU вешается из-за ошиобк в работе оборудования (errata, не описаны в спеках). Рекавери GPU - отдельный гемор, сравнимый по сложности реализации с чуть ли не запуском ракеты в космос и столь же обломоопасный, т.к. современный GPU - это навороченный комплекс из нескольких подсистем. Которые желательно показать апликухам в том виде как было, иначе они осыпятся как горох. А если рекавери не удался - система резко остается без картинки на экране по вполне очевидной причине. Скажите, пожалуйста, как именно то что вы сватаете поможет в отладке в этом вполне рядовом и заурядном случае? А вот тормознет - запросто. Там летают чуть ли не гигабайты в секунду, так что одно лишнее копирование может положить производительность в разы.
> И? Это квалифицированные люди, их время стоит денег. Значит, разумно упростить им
> отладку и обезопасить их код, чтобы они могли не так сильно напрягаться.
Вы так говорите как будто эти разработчики уполномочивали вас говорить от своего лица. А они этого не делали, между прочим. И т.к. они вполне успешно пилят свои драйвера уже более десятка лет и не рвутся пилить микроядра и дрова в юзерспейсе - удачи вам их пинками загнать в всеобщее счастье.
> Ну сделает, ну обработаются через минуту. Никакой пользователь не будет вытаскивать и
> втыкать штеккер в ноут со скоростью 25 раз в секунду. Даже 2 раза в секунду не будет.
Тормозные системы пользователям не нравятся. В свое время это крепко подгадило WinNT с более правильным дизайном заставив несколько лет выпускать 9х попутно допиливая дизайн NT до состояния когда его скорость таки устроит юзерей. А сейчас запросы выросли, юзеры хотят разрешения FullHD и выше, 3D навороченное и что там еще. И опять же тормознуть ту же графическую подсистему - не вариант. SSD опять же по скорости - очень быстрые штуки, приближающиеся к физическим лимитам интерфейсов. Если проц прии этом начнет клинить в пять раз сильнее - кому оно будет надо?
> Ну вот оно передаёт демону в пространстве пользователя. А демон шлёт по
> шине в пр-ве пользователя. Зачем тут шина в ядре?
Затем что по факту этим заведует ядро и довольно глупо пытаться делать вид что это не так. Только почем зря строится лишняя длинная цепочка, снижая скорость. А может и надежность. По такой логике и TCP/IP должен отдельный демон делать. Вот только нафига оно надо такое счастье? Пусть кому надо - тот этим и пользуется, если хочет.
>> А зачем там туева хуча побочных прослоек?
> Давайте засунем всю систему в пространство ядра. :-)
Маленькие и простые системы ксати так и делают - на 8-битниках всяких вообще нет разделения режимов. И ничего, работает. Даже в ответственных применениях, между прочим. А оно всякими ABS щелкает, подушки безопасности выбрасывает и делает прочие задачи, в общем то завал которых достаточно критичен. Наверное секрет не в том чтобы изящно подтереться после того как из штанов потекло, а не допускать этого самого вытекания, для начала. Кому нужна система от которой дурно пахнет?
>> Для универсальной шины заранее не известно какой именно там будет траффик и
>> по какому поводу.
> Если вы будете гонять гигабайты, вы во-первых, заблокируете шину.
Значит по хорошему должен быть некий арбитраж и дележ ресурсов, предотвращающий такой сценарий в бесконтрольном виде.
> Если вы будете делать шину с использованием всех имеющихся в системе процессоров,
> с коммутацией пакетов, с приоритезацией и т.д., вы сильно усложните простую
> задачу уведомления о редких событиях.
Ну вон TCP/IP реашает довольно сложную задачу и имеет довольно много опций. И тем не менее, его не так уж сложно использовать. И да, таки в ядре есть возможность приоретизации пакетов и прочая. Но это не значит что апликушнику будет сложно создать сокет с нужными параметрами и прочая.
>> на основании чего ядро должно быть обделено на возможности броадкаста и
>> получения сообщений.
> Не обделено - как ещё получаются сообщения о смене режима питания, как не из ядра?
Вот мне и не понятно - зачем в этом процессе какие-то левые юзерспейсные демоны вообще будут фигурировать?
