>> Модульный он лишь в смысле наличия функций подгрузки/выгрузки кода.
> Да как сказать, ряд подсистем относительно независимо разрабатывается.Прямым текстом: это не имеет отношение к архитектуре ядра. Ядро - монолит, с общим адресным пространством для всех нитей. Ошибки в коде одной подсистемы чреваты отказом или компрометацией всей системы.
>> Это не имеет никакого отношения к архитектуре ядра.
> Это еще как сказать.
Я понимаю, вам хочется поговорить на смежные темы, лишь бы не по существу.
> не столько архитектура ядра, сколько архитектура распределенной разработки, но границы
Это нисколько не архитектура ядра. Это организация процесса разработки.
> Деление на задачи пролегает по неким вполне себе архитектурным границам :). Дело
И где же пролегают эти *архитектурные* границы в едином адресном пространстве ядра?
>> FUSE-драйвер - пользовательский процесс. В чём же этот неуловимый нюанс, который ставит
>> стабильность системы в зависимость от пользовательского процесса? Не поясните?
> Капитан объясняет: если от доступа обрабатываемых этим драйвером данным зависела работа
> каких-то программ
...то ошибка в FUSE-драйвере ставит под угрозу стабильность работы этих программ, но не всей системы. При этом после краха FUSE-драйвера ядро вернёт ошибки в ответ на сисколы процессов-клиентов раздела, и у последних будет как минимум возможность обработать эти ошибки и завершить работу.
Теперь, как события развиваются после сбоя ядерного драйвера.
В худшем случае kernel panic, мёртвое зависание с произвольно тяжёлыми последствиями (повреждение данных на других разделах) или полная компрометация системы (в случае эксплуатации ошибки-уязвимости).
В лучшем случае BUG'нутая нить драйвера блокирует доступ к разделу без возможности удостоверить консистентность данных и перемонтировать его повторно без перезагрузки всей системы. При этом процессы-клиенты раздела при любом обращении к разделу уходят в контекст ядра без возможности обработать ошибки, быть перезапущенными и даже без возможности аварийно завершить работу (SIGKILL на них тоже не действует). При этом нельзя освободить занятую процессами память, кроме как постепенно вытеснить страницы в своп, и другие ресурсы: сетевые сокеты, shm-сегменты и т.п.
> Более жестокий и жизненный пример: а что если на этой ФС был
> своп? Вообще, идея совместно использовать один своп с виндой на нтфсном
Пример из жизни хомячков-виндузятников. Заведомо ненадёжное применение интерфейса.
> томе - имеет право на жизнь: а зачем вам два свопа?
Мне? Мне вообще своп не нужен, как и для решения сколько-нибудь серьёзных задач. Кстати, по критерию скорости, который все вы так любите.
> Хинт: доступ к файловой системе - это практически половина доступа к ОС
> :)
Ну кто бы мог подумать!
> А административные операции - они для админов, вы прикиньте?! Позволить любому болвану
Вы о разделении привилегий что-нибудь слышали? А о системных псевдопользователях?
> перекраивать структуру файловой системы в многопользовательской многозадачной ОС - потом
> костей не соберешь. Может мы вообще отменим нафиг права доступа к
Вы не представляете себе модель привилегий доступа к FUSE. Позорьтесь дальше, продолжайте эту добрую традицию.
> ФС и пускай первый же хомяк своим rm -rf /* кладет
> всю систему, а? Ну тогда вам в Win95, там как раз
> никаких заморочек с правами доступа нет.
А я здесь причём? Ваши абсурдные доводы, вы и пользуйтесь - хоть 95-ой, хоть 3.10-ой.
> Может мозги у вас и есть, но вот троллить вы совершенно не
> умеете :P. На такой жирный троллинг не поведется даже школота.
А я и не троллю. Мне просто нравится наблюдать беспомощность некомпетентных выскочек без знания предмета, чувства собственного достоинства и уважения к собеседнику.
> Мне проще пользоваться нормальными ФС с ядерными драйверами оказалось. А вы можете
> сучить ножками, ручками или чем там вам удобнее, ждать разработчиков и
> что там еще.
Вы предыдущий комментатор? Его, видите ли, задолбали FUSE-драйверы, за которые он не выложил ни копейки. Предложение посучить ножками адресовано ему.
>> А то. Взять вот так всё и вынести разом. :) Я прямо устал повторять. ;)
> Ну так это уже давно реализовано в микроядерных всяких. Пользуйтесь наздоровье -
</sarcasm></smileys>
> там ядро вообше примитивный менеджер ресурсов по сути, и все. А
> драйвера напишете себе сами. Ну, линуксных разработчиков - устравивает их работа,
> видимо. Если бы это было не так - они бы писали
Вы отвечаете на собственные глупости. Претензий к разработчикам по этой части у меня нет.
>> тормозят? ;) Больше ничего не хотите сказать? ;)
> А чего тут говорить то, графики загрузки фузевым NTFS драйвером проца сами
> все скажут, доходчивее некуда. Если такой здец будет с КАЖДЫМ драйвером
Сразу видно, что микроядерными ОС вы не пользовались. "Гигантский проигрыш по скорости", о котором все говорят - это 10-20%, не более, даже на микроядерных ОС реального времени.
> - в системе работать будет просто невозможно.
Размахивайте руками. Убеждайте окружающих. Это забавно.
> Нет, бункеры - не игрушки. А вот те кто строит бункеры не
> только с поводом но и без - страдают фигней, да. О
Напоминаю, что Торвальдс, как обычно, не делал никаких оговорок в духе "а вот те, кто". Согласно его словам, заблуждаются ВСЕ пользователи FUSE, которые считают FUSE ФС чем-то большим, чем игрушки.
> чем Торвальдс и сказал. Просто число копающих себе бункеры стало как-то
> непропорционально задачам где они могли бы пригодиться.
Торвальдс сказал ровно то, что сказал. Вы оспариваете факт, пытаясь дополнить его несуществующими подробностями.
