Дискуссия Таненбаума и Торвальдса: часть II

>Торвальдсу давно взять топор и пороботать руками :)

Наверное, имеется ввиду "над руками"?

Объясните мне, дибилу, как микроядерная архитекту ра защитит от кривого драйвера ФС =) И кстати, Symbian - очень, очень глючная система...

Если кривой драйвер ФС в микроядре рухнет, то имеется возможность поставить новый без перерыва работы текущей системы. В конце-концов, можно сделать дамп на другой ФС. А вот если рухнет кривой драйвер в монолитном ядре...короче, резервирование форева...

> Если кривой драйвер ФС в микроядре рухнет, то имеется возможность поставить новый без перерыва работы текущей системы.

Анонимный брат, если драйвер ФС кривой - он тебе испортит ФС и хранимые в ней данные, и "поставить новый без перерыва работы" тебе не удасться.

Насчет отсуствия кнопки Reset - спросите любого драйверописателя, и он скажет вам, что кривой драйвер может поставить всю систему раком (я не имею в виду пропись памяти с помощью DMA). И это не зависит от того, где именно он выполняется - в ядре или userspace, так что абсолютной надежности не будет. Хотя общая надежность и удобство разработки повысятся, конечно.

>Анонимный брат, если драйвер ФС кривой - он тебе испортит ФС и хранимые в ней данные, и "поставить новый без перерыва работы" тебе не удасться.

во первых, на среднем компьютере используется штук 5 разных fs, и если драйвер fat12 испортил дискету, или глючит драйвер minix fs смонтированной на /mnt/чистапозырить/- это еще не повод вешаться

во вторых, если есть один драйвер(fs), который нет смысла выносить из ядра, это еще не повод отказаться от вынесения из ядра многочисленных драйверов вебкамер/твтюнеров/звуковух/6-кнопочных радиомышей/UPS/BT/etc, суммарный объем кода(и ошибок) в которых заметно выше, чем суммарный объем кода и ошибок в драйверах Ext3&ReiserFS - как в целом, так среди установленных на конкретной машине.
(PS лично мне легче представить не скачкообразный переход на Linux поверх микроядра, а плавный переход на Linux с существующим ядром + прослойку для юзерспейсе драйверов)

> на среднем компьютере используется штук 5 разных fs

у меня - всего 2 :)

> и если драйвер fat12 испортил дискету, или глючит драйвер minix fs смонтированной на /mnt/чистапозырить/- это еще не повод вешаться

Ну так и Linux не вешается :)

> это еще не повод отказаться от вынесения из ядра многочисленных драйверов вебкамер/твтюнеров/звуковух/6-кнопочных радиомышей/UPS/BT/etc

Не повод, конечно. Надо выносить (жаль, что Линусу и К религия мешает это сделать). Но речь в принципе не может идти об "отказе от кнопки Reset", вот о чем я говорю.

> (PS лично мне легче представить не скачкообразный переход на Linux поверх микроядра, а плавный переход на Linux с существующим ядром + прослойку для юзерспейсе драйверов

Хотелось бы, но заметных подвижек пока нет.

> Есть идея что надежны программеры а не языки :)

Есть идея, что программеры НЕнадежны. :) Человеческий фактор -- fault by design. Задача языка -- не позволить сделать человеку очевидных ошибок и при этом не слишком мешать ему этим.

> Насчет отсуствия кнопки Reset - спросите любого драйверописателя, и он скажет вам, что кривой драйвер может поставить всю систему раком (я не имею в виду пропись памяти с помощью DMA). И это не зависит от того, где именно он выполняется - в ядре или userspace, так что абсолютной надежности не будет.

Если юзер-спейсный драйвер ставит раком систему, то это проблемы ядерной части, т.к. сделать это он может только через некоторый ядерный интерфейс, а не сам по себе.

> Если юзер-спейсный драйвер ставит раком систему, то это проблемы ядерной части,

Неверно в корне.

> т.к. сделать это он может только через некоторый ядерный интерфейс

Верно до банальности.

Ядро ВЫНУЖДЕНО предоставлять драйверу такие API, при помощи которых драйвер может убить систему (намеренно или по ошибке). На PCI это неустранимо by design (потому что это общая шина без всякого разграничения доступа). Конечно, на какой-нибудь будущей аппаратной архитектуре, где у каждого устройства свой IRQ, диапазон ввода/вывода, контролируемый аппаратно (а контролирующей аппаратурой рулит микроядро), а весь DMA проходит через IOMMU... Но пока такой архитектуры не существует.

> Хотелось бы, но заметных подвижек пока нет.

FUSE не заметили?

>> Хотелось бы, но заметных подвижек пока нет.

>FUSE не заметили?

Того, что речь о драйверах аппаратуры - не заметили?

>Ядро ВЫНУЖДЕНО предоставлять драйверу такие API, при помощи которых драйвер может убить систему (намеренно или по ошибке).

Хорошее микроядро не допустит недопустимых действий. Будет выбор из набора действий, а не выполнения любого действия.

>> (PS лично мне легче представить не скачкообразный переход на Linux поверх микроядра, а плавный переход на Linux с существующим ядром + прослойку для юзерспейсе драйверов

>Хотелось бы, но заметных подвижек пока нет.

А как же FUSE (как так)?

> Ядро ВЫНУЖДЕНО предоставлять драйверу такие API, при помощи которых драйвер может убить систему

Тогда какой вообще смысл выносить такой драйвер в юзер-спэйс? GP на ring0 и сейчас для Линукса не фатально.

> Но пока такой архитектуры не существует.

IMHO никогда и не будет.

>> Ядро ВЫНУЖДЕНО предоставлять драйверу такие API, при помощи которых драйвер может убить систему

>Тогда какой вообще смысл выносить такой драйвер в юзер-спэйс?

количество ошибок, опасных для всей системы, все-таки снижается-
- если 90% драйверов смогут корректно самовосстанавливаться после 90% ошибок- виндусятники будут таскать зависшие компьютеры в гарантию, как сейчас- зависшие телефоны и телевизоры (когда я нажимал ресет- и так не помню))

к тому-же микроядра аля Minix вроде устойчивы к руткитам в драйверах, а просто вешать сервера- довольно скучно

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

>>Хотелось бы, но заметных подвижек пока нет.

>А как же FUSE (как так)?

Речь идет о драйверах аппаратуры, не о драйверах файловых систем.

>Хорошее микроядро не допустит недопустимых действий.

Откуда ему знать, какое действие над железкой является допустимым? Откуда ему знать, какие аргументы делают полезное действие смертельным? Всё это зависит от конкретного устройства, о котором микроядро не знает ровным счетом ничего.

> Будет выбор из набора действий, а не выполнения любого действия.

Среди этого набора по определению будут действия, способные при неправильном использовании убить систему.

>Откуда ему знать, какое действие над железкой является допустимым?

Возьмём частную модель Unix-way: программа (модуль) - система (микроядро). Любая программа с другой взаимодействует только по каналам. Нет использования разделяемой памяти. Что в таком случае может быть недопустимым в действии программы, чтобы повесить полностью систему, не учитывая при этом ошибок системы (то есть учитывая только ошибки программы)? Неиспользование ограничений и kill не предлагать.

>Среди этого набора по определению будут действия, способные при неправильном использовании убить систему.

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

>>>Хотелось бы, но заметных подвижек пока нет.

>>А как же FUSE (как так)?

> Речь идет о драйверах аппаратуры, не о драйверах файловых систем.

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

> реплика была к тому, что несмотря на монолитность ядра отростки в юзерспейс так и вываливаются. Естественная эволюция. Пока драйвера fs - далее полезет железо.

Proof-of-concept драйверы в userspace появились минимум 3 года назад. До сих пор в стандартном ядре нет ничего, что облегчало бы их написание. Единственная попытка - патчи GregKH (я постил сюда новость о них) прозябают в -mm, не говоря уже о том, что они безнадежно неадекватны для написания драйвера более-менее сложного устройства.

Если же учесть, что сам Линус _резко_ против вынесения драйверов в userspace (его _технические_ доводы ИМХО неубедительны - там скорее психология), то будущее таких драйверов выглядит унылым. Единственная надежда - на Свисту: если там будут userspace драйверы, может, народ начнет действовать. Ирония :/

> Возьмём частную модель Unix-way: программа (модуль) - система (микроядро).

Давай не будем рассуждать о сферических конях в вакууме (а если сильно хочется - подумай, что запущенная от root программа может сделать с системой). Возьмем конкретный пример - при обмене через DMA на устройство передается массив специфичных для данного устройства дескрипторов, в которых есть (в числе прочего) шинные адреса участков памяти, в которые устройство должно передать данные. Если драйвер сделает ошибку в вычислении этих адресов, устройство затрет некоторую память - любую. Микроядро не может проверить правильность передаваемых адресов - формат дескриптора специфичен для устройства.

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

Я тоже люблю чеканные формулировки. Они такие... гладкие и красивые.

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

Как это "любую"? Микроядро что, не "знает", какая память для чего уже выделена? И не может "понять", что, к примеру, в область памяти, выделенную под кэш винта, нельзя записывать данные, идущими от звуковухи?

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

>Как это "любую"?

Вот так - любую.

> Микроядро что, не "знает", какая память для чего уже выделена?

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

>Микроядро вполне может это знать. Но устройству на это глубоко начхать - оно работает на более низком уровне, ничего о не зная о микроядре (да и макроядре тоже :)), и не обращая (естественно) внимания на защиту памяти.

Ну да, остаётся только добавить, что памяти тоже глубоко начхать на микроядро (да и на макроядро тоже), так как она тоже работает на низком уровне и отдаётся любому процессу, которому понравилась. А диспетчер памяти? Да для красоты!

Остаётся только узнать, как драйвер, работая в юзерспейс, может передать данные устройству, минуя микроядро, которое теоретически знает, куда можно записывать, а куда нельзя.

> А диспетчер памяти? Да для красоты!

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

> Остаётся только узнать, как драйвер, работая в юзерспейс, может передать данные устройству, минуя микроядро, которое теоретически знает, куда можно записывать, а куда нельзя.

Вообще-то речь шла о передаче данных от устройства в память, но не вопрос... Начни с этого: http://www.linuxsymposium.org/proceedings/reprints/Reprint-Chubb-OLS2004.pdf

>В частности то, что диспетчер памяти реализуется с опорой на поддержку ЦП, а обмен "устройство-память" работает мимо него.

Я говорю про зависимость работы "устройство-память" от работы "драйвер-ядро"

>Вообще-то речь шла о передаче данных от устройства в память,

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

Начни >Начни с этого: http://www.linuxsymposium.org/proceedings/reprints/Reprint-Chubb-OLS2004.pdf

Спасибо. Вот я думаю, чем бы заняться ночью на русскоязычном сайте после довольно внятного объяснения Профессором основ, неплохо изложенных переводчиком.

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

:-D А как оно сможет работать? Чьим желаниям^Wкомандам оно будет подчиняться?

> после довольно внятного объяснения Профессором основ, неплохо изложенных переводчиком.

ИМХО, ты не понял того, что сказал Профессор.

>:-D А как оно сможет работать? Чьим желаниям^Wкомандам оно будет подчиняться?

микроядра? Оно будет контролировать правильность работы драйвера устройства на тему взаимодействия шины и памяти.

>ИМХО, ты не понял того, что сказал Профессор.

>>Моя точка зрения заключается в том, что следует избегать разделяемые структуры данных везде, где можно. Системы должны строиться из наименьших модулей, полностью скрывающих свои внутренние структуры данных от кого бы то ни было. Они должны иметь чётко сформулированные «тонкие» интерфейсы, которыми остальные модули могут воспользоваться для выполнения заданий.

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

Что же здесь непонятного?

>>:-D А как оно сможет работать? Чьим желаниям^Wкомандам оно будет подчиняться?

>микроядра?

Если микроядро знает, как управлять любым устройством, тогда конечно. Слушай, а драйверы - они вообще нужны? И если да, то зачем?

> Что же здесь непонятного?

Непонятно, как MMU защищает память от посягательств со стороны устройста (ты ведь не говоришь "IOMMU"). Непонятно, как это всё относится к драйверам устройств и их возможности убить систему. Непонятно, как это всё относится к принципиально разделяемым _аппаратным_ ресурсам вроде IRQ и общей шины. То есть - как все эти замечательные идеи относятся к тому, чем вынуждены манипулировать драйверы.

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

Зачем любым устройством? Разве драйвера шины недостаточно?

>Непонятно, как...

Так ты спроси у профессора, он всё объяснит. Мне же ясно как день, что если есть блоки неразделяемой памяти и обмен между ними осуществляется через каналы, то нет геморроя.

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

>Зачем любым устройством? Разве драйвера шины недостаточно?

Нет

>>Непонятно, как...

> Так ты спроси у профессора, он всё объяснит.

Я спросил не потому, что не знаю. Если бы _ты_ попытался объяснить, понял бы и сам.

> ясно как день, что если есть блоки неразделяемой памяти и обмен между ними осуществляется через каналы

На том уровне, на котором оперируют драйверы, вся память - разделяемая, а каналов нет.

>Нет

Почему?

>Если бы _ты_ попытался объяснить, понял бы и сам.

Самообразование - рулёз, конечно, но только для специалистов в этой области.

>На том уровне, на котором оперируют драйверы, вся память - разделяемая

А как же возможность распределения системных ресурсов?

>>Нет

>Почему?

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

>>Если бы _ты_ попытался объяснить, понял бы и сам.

>Самообразование - рулёз, конечно, но только для специалистов в этой области.

Если ты не специалист и не хочешь разобраться, тебе не стоит лезть в узкоспециальные дискуссии.

>>На том уровне, на котором оперируют драйверы, вся память - разделяемая

>А как же возможность распределения системных ресурсов?

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

>Если ты не специалист и не хочешь разобраться, тебе не стоит лезть в узкоспециальные дискуссии.

Выбор ядра - это вовсе не узкоспециализированная дискуссия.

А разбираться можно, но только с точными ссылками на русские источники или собственными качественными статьями.ответами, а не отмазы типа "учебный курс" и 14 - тистраничный pdf'ик с архитектурой совсем не того, чего нужно. Особенно в том случае, когда ответ - несколько строк. Если вы хотите донести истину, почему бы самому не сформировать полный и понятный ответ? Если не хотите, зчем участвовать в дискуссии?

>>Если ты не специалист и не хочешь разобраться, тебе не стоит лезть в узкоспециальные дискуссии.

>Выбор ядра - это вовсе не узкоспециализированная дискуссия.

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

> отмазы типа "учебный курс" и 14 - тистраничный pdf'ик с архитектурой совсем не того, чего нужно

> Если вы хотите донести истину, почему бы самому не сформировать полный и понятный ответ? Если не хотите, зчем участвовать в дискуссии?

Я хочу (хотел), но у меня не получилось. Мы говорим на разных языках. Или о разных вещах. pdf и учебный курс - это было для того, чтобы найти хотя бы общий язык.

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

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

Дело не в некоторых сбоях для чистого микроядра, а в наличие такого минимального кода, который исключит сбои полностью.

>pdf и учебный курс - это было для того, чтобы найти хотя бы общий язык.

"Будь проще - и люди к тебе потянутся".

> в случае с адресами памяти в потоке данных устройства со специфичным для устройства форматом, будет, я думаю, не так сложно организовать правильное написание компоненты шифровки/расшифровки данных, касающихся адресов

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

Почему же сразу не были рассмотрены наиболее интересные случаи?

>Почему же сразу не были рассмотрены наиболее интересные случаи?

Были. Ты этого просто не понял. "Ядро ВЫНУЖДЕНО предоставлять драйверу такие API, при помощи которых драйвер может убить систему (намеренно или по ошибке). На PCI это неустранимо by design (потому что это общая шина без всякого разграничения доступа). Конечно, на какой-нибудь будущей аппаратной архитектуре, где у каждого устройства свой IRQ, диапазон ввода/вывода, контролируемый аппаратно (а контролирующей аппаратурой рулит микроядро), а весь DMA проходит через IOMMU..."

>Проблема minix безусловно в лицензии, поскольку судя по коментариям идею разделяют многие, а вот бесплатно работать на негрософт никто не хочет.

По твоему негрософту оно надо? В начале вендового века оно может и надо было - сейчас в MS Research работают все кому надо и не надо, а программистов они могут нанимать пачками. _Код_ негрософт давно не заимствует. А идеи открыты. В крайнем случае покупает. Minix оно красть как основу своей операционки в любом случае не будет.

>Открыв под BSD они на что надеются, на помощь сообщества? И на то, что компании будут пользоваться их кодом бесплатно? А это нужно сообществу?

А ты что делишь сообщество и компании? IBM это компания или сообщество? А RedHat?

>а обмен "устройство-память" работает мимо него.

Хотя я с DMA работал когда деревья не были большими - но что-то в памяти у меня всплывает что чтобы настроить DMA нужно сказать куда и/или откуда. И тут уже диспетчер может заорать мол вы гоните куда вы меня тащите.

> в памяти у меня всплывает что чтобы настроить DMA нужно сказать куда и/или откуда. И тут уже диспетчер может заорать

Диспетчер памяти ничего не поймет. В DMA даже адреса не те, с которыми диспетчер памяти работает.

> Надёжность ОС - микроядро. Это не так?

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

> Надёжность пользовательского софта - жаба. Обработка исключений сделана очень красиво. Есть реальные альтернативы?

ruby

>>Проблема minix безусловно в лицензии, поскольку судя по коментариям идею разделяют многие, а вот бесплатно работать на негрософт никто не хочет.

>По твоему негрософту оно надо?
>r

Нам предлагаешь нахаляву доработать до того уровня пока им не станет надо ?

>а программистов они могут нанимать пачками.
это не мешает им делать отстойные продукты.

>Minix оно красть ..

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

>> Надёжность ОС - микроядро. Это не так?

>не так. микроядро не панацея.

Его даже Танненбаум не называет панацеей :)

> пока софт пишут люди от ошибок не застрахована ни одна ОС. другое дело, что в микроядре, за счет большего количества уровней абстракций, проще отслеживать код, но и в линухе, за счет модульности, его не намного сложнее отслеживать

Дело не в уровнях абстракций или не в модульности, а в изоляции сбоев (fault containment). Linux не меннее модульный, чем любая микроядерная ОС, но в нем сбой в модуле может "вынести" всю систему (банально прописав память). В микроядерной ОС такие сбои возможны только при манипуляциях драйверов с аппаратурой.

Другое дело, что за такую надежность явно придется заплатить производительностью - в функции обработки прерывания Minix3-драйвера rtl8169 почти 20 системных вызовов! Всё это выглядит как-то игрушечно. На сайте Minix3 я не нашел результатов бенчмарок - это неспроста :( Зато много свиста о том, что они не гонятся за производительностью.

>> Надёжность пользовательского софта - жаба. Обработка исключений сделана очень красиво. Есть реальные альтернативы?

>ruby

Нет статической типизации - для больших проектов подходит плохо.

> ruby

Смешно.

>ruby

както я попроболвал - вроде даже заработало, но не копался. Вопрос: 1. оно исключения обрабатывает не хуже жабки? 2. насколько долго и стабильно работает приложение по руби без перезагрузки?

А более подробно?

Динамически типизированный скриптовый язык. Что еще подробней сказать?