> Прямым текстом: это не имеет отношение к архитектуре ядра. Ядро - монолит,
> с общим адресным пространством для всех нитей.

Более того, практически все остальные ОС общего применения обладают теми же свойствами. Это же относится и к WinNT, и к *BSD и к кому там еще. Полтора экзота на пятке АЭС в мире - великолепно! Проблемка только в том что у меня нет АЭС. И даже спутника.

> Ошибки в коде одной подсистемы чреваты отказом или компрометацией всей системы.

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

> Я понимаю, вам хочется поговорить на смежные темы, лишь бы не по существу.

А вам, видимо, хочется меня потроллить? Или зачем вы так демонстративно тупите, как будто не понимаете что если я получил полный доступ к тому через баг в драйвере - я уже царь и бог. Особенно в posix-like, где "everything is a file".

> Это нисколько не архитектура ядра. Это организация процесса разработки.

Организация процесса разработки связана с делением по архитектурным границам.

> И где же пролегают эти *архитектурные* границы в едином адресном пространстве ядра?

По различным подсистемам являющим более-менее самостоятельные сущности.

> ...то ошибка в FUSE-драйвере ставит под угрозу стабильность работы этих программ, но
> не всей системы.

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

> При этом после краха FUSE-драйвера ядро вернёт ошибки
> в ответ на сисколы процессов-клиентов раздела, и у последних будет как
> минимум возможность обработать эти ошибки и завершить работу.

Ну да, щаз. Если не прочелся например своп, процесс словит page fault -> не получилось прочесть страницу -> процесс умирает. Без внятных шансов это обработать. Сложно что-то обрабатывать, когда в мозг воткнулся лом.

> Теперь, как события развиваются после сбоя ядерного драйвера.
> В худшем случае kernel panic, мёртвое зависание с произвольно тяжёлыми последствиями (повреждение
> данных на других разделах)

В хучшем случае, то же самое будет и в случае FUSE драйвера побившего своп-файл на своей ФС, например. Более того, скомпрометированный драйвер ФС может внаглую инжектить в своп любые произвольные данные, произвольно перекраивая работу всех остальных процессов, которых угораздило попасть в своп. По сути - это полное поимение ОС со всеми потрохами. Аналогично, при чтении бинарей, скомпрометированный драйвер может например тело вируса в каждый файл подшивать, или что там ему угодно.

> или полная компрометация системы (в случае эксплуатации
> ошибки-уязвимости).

Знаете, если драйвер скомпрометирован и вернет вам при чтении бинаря не бинарь а вирусяку - хрен вы это оспорите, даже если это FUSE'вый драйвер сделал. Аналогично, драйвер может на лету патчить своп на своем томе с целью получения управления в рамках всех остальных частей системы, может оверрайдить записи ACL на томе в пользу себя и хозяина малвари, etc. А кто ему запретит то? Если он разбирает эти структуры, он же и соврать при этом остальной части ОС запросто может. И это может иметь далеко идущие последствия. Более того, обычно в CPU аппаратная изоляция кернела от юзера сделана куда более кардинально чем юзера от юзера.

> В лучшем случае BUG'нутая нить драйвера блокирует доступ к разделу без возможности
> удостоверить консистентность данных и перемонтировать его повторно без перезагрузки всей
> системы.

Простите, а если драйвер FUSE напортачит и сольет битые данные на свой том - чем это неконсистентное состояние ФС будет отличаться от того что выше?

> При этом процессы-клиенты раздела при любом обращении к разделу уходят
> в контекст ядра без возможности обработать ошибки,

То что вы описываете - баг ядра. А приколитесь, что будет если драйвер FUSE получит запрос "запишите мне 20 байтов в файл по смещению 0x100500" и ... повиснет? Как абсолютный максимум, драйвер можно пристрелить по таймауту. Но при этом том скорее всего будет основательно испорчен, особенно если таймаут случится в тот момент когда драйвер что-то делал и например оборудование решило стормозить. Ну может диск там минуту бэд ремапал, пытаясь его подчитать. Никто нам не гарантирует за сколько жесткий диск нашу команду смолотит.

> быть перезапущенными и даже без возможности аварийно завершить работу (SIGKILL
> на них тоже не действует).

Ну вообще-то взвис в драйвере - это баг. Даже не столько драйвера ФС, сколько драйвера работающего с железкой. Правильная реакция - задетектить что железо померло и вернуть ошибку. Кстати, а часто у вас драйвера ФС все вешали? Я вообще видел только 1 раз OOPS в драйвере ФС, при том это был сырейший драйвер btrfs, год назад примерно. В результате упал процесс который вызвал оопс. И все. Отсюда мораль: криворуким обезьянам нечего делать в драйверах ФС. Вообще. Они с пользовательскими данными работают, поэтому сбои там попросту недопустимы. А кому нужна ОС, теряющая или разрушающая пользовательские данные? :)

> При этом нельзя освободить занятую процессами память, кроме как постепенно вытеснить
> страницы в своп, и другие ресурсы: сетевые сокеты, shm-сегменты и т.п.

А вы хоть раз на практике такое видели с драйверами из майнлайна, объявленных стабильными? Их в оопс то свалить - надо крепко постараться. Вот так и надо работать, потому что сбой в драйвере ФС в любом случае означает что пользователь потеряет свои данные. Доверять писать это кому попало? Спасибочки. Сами пользуйтесь сбоящими драйверами. А я буду пользоваться теми, которые не сбоят, не крашат систему и не виснут. Мне мои данные нужны не в виде вермишели размазанной по диску.

> Пример из жизни хомячков-виндузятников. Заведомо ненадёжное применение интерфейса.

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

> Мне? Мне вообще своп не нужен, как и для решения сколько-нибудь серьёзных
> задач. Кстати, по критерию скорости, который все вы так любите.

Для сколь-нибудь серьезных задач, очень редко но все-таки может потребоваться объем памяти превышающий физически доступный в системе. И, кстати, если уж мы о надежности, при нехватке памяти как минимум обломается 1 или несколько процессов, и еще не факт что они корректно переваривают нехватку памяти. А может и OOM киллер пройтись по расстрельному списку. Вы уж определитесь - или уж надежность, или уж скорость. А то какие-то двойные стандарты прямо.

>> А административные операции - они для админов, вы прикиньте?! Позволить любому болвану
> Вы о разделении привилегий что-нибудь слышали? А о системных псевдопользователях?

Да, я слышал о разделении привилегий. Ну вот административные операции - они, внезапно, для административных пользователей. Например, рута. Или иных пользователей, которым теми или иными механизмами позволят делать те или иные привилегированные операции. Как именно это реализуется, через системных псевдопользователей, suid'ные флаги или какое-нибудь sudo - да вообще вопрос десятый и относится уже к конкретике реализации системы деления прав в той или иной ОС. При том ядру ОС чисто технически никто и ничто не мешает делить права так как они захотят. Просто они работают более-менее в рамках выбранной абстракции, POSIX и прочая. Там - вот так. Но если надо чтобы вон там бесправный лузер получил вон те права на монтирование тома и вдруг почему-то вам не понравились уже существующие рычаги воздействия и механизмы - ну поменяйте сорцы и пусть вон тому юзеру тоже можно будет юзать этот сискол. Законом не запрещено, законы природы не нарушает. Хотя почти наверняка эквивалентное деление прав можно реализовать какими-то менее варварскими методами. Например, засунув юзера в контейнер и дав ему там права "псевдорута". Ну и будет он рулить, но только в своем загончике, а остальным напакостить не сможет. И простая абстракция, и вполне эффективно.

> Вы не представляете себе модель привилегий доступа к FUSE.
> Позорьтесь дальше, продолжайте эту добрую традицию.

И вас также.

> А я здесь причём? Ваши абсурдные доводы, вы и пользуйтесь - хоть
> 95-ой, хоть 3.10-ой.

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

> А я и не троллю. Мне просто нравится наблюдать беспомощность некомпетентных выскочек
> без знания предмета, чувства собственного достоинства и уважения к собеседнику.

Да-да, вы не троллите, а только пытаетесь, довольно уныло, имхо. Местами тупя не хуже собеседников. Кстати, синдром Д`Артаньяна вам засчитан.

> Вы предыдущий комментатор? Его, видите ли, задолбали FUSE-драйверы, за которые он не
> выложил ни копейки. Предложение посучить ножками адресовано ему.

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

> Вы отвечаете на собственные глупости. Претензий к разработчикам по этой части у
> меня нет.

Тогда какие к Торвальдсу претензии? С чем вы не согласны? С тем что FUSE дрова тормозят и жрут процессор? Так это бенчмарками и мониторами ресурсов проверяется на раз и результат получается совсем не в ползу FUSE почему-то.

> Сразу видно, что микроядерными ОС вы не пользовались. "Гигантский проигрыш по скорости",
> о котором все говорят - это 10-20%, не более, даже на
> микроядерных ОС реального времени.

А вы какими микроядерными ОС пользовались, и под какими нагрузками получили 10-20% и все такое? А то почему-то FUSE'вый NTFS грузит проц раз в пять сильнее чем ядерный EXT4. И вечно норовит упереться в проц, а не диск почему-то. И чего б это вдруг?

> Размахивайте руками. Убеждайте окружающих. Это забавно.

Вай-вай. Вы тоже с забавлением окружающих имхо справляетесь. Ну вот например очередная попытка потроллить, не особо удачная, имхо :P.

>> только с поводом но и без - страдают фигней, да. О
> Напоминаю, что Торвальдс, как обычно, не делал никаких оговорок в духе "а
> вот те, кто". Согласно его словам, заблуждаются ВСЕ пользователи FUSE, которые
> считают FUSE ФС чем-то большим, чем игрушки.

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

> Торвальдс сказал ровно то, что сказал. Вы оспариваете факт, пытаясь дополнить его
> несуществующими подробностями.

Ну так и правильно сказал, по большому счету. А дополнения были лишь в допущении что у собеседника есть мозги и он понимает, что если не было призыва вынести поддержку FUSE совсем, значит возможность "копания бункера" никто полностью отбирать не собирается. Но повертеть пальцем у виска - в своем праве, ага.