Комментарии 64
Спасибо за информацию, с нетерпением жду продолжения цикла.
Вопрос по переключению контекстов: разве эта процедура не является весьма процессорно-зависимой?
И да, и нет.
С одной стороны, алгоритм одинаков для любого процессора. Необходимо сохранить текущее состояние потока, а именно, его регистры, маску сигналов и т.п. И загрузить тоже самое для следующего потока.
С другой стороны, у каждой процессорной архитектуры свой набор регистров. И время переключения контекстов будет зависеть как от архитектуры, так и от скорости процессора.
С одной стороны, алгоритм одинаков для любого процессора. Необходимо сохранить текущее состояние потока, а именно, его регистры, маску сигналов и т.п. И загрузить тоже самое для следующего потока.
С другой стороны, у каждой процессорной архитектуры свой набор регистров. И время переключения контекстов будет зависеть как от архитектуры, так и от скорости процессора.
Я так понимаю, что фундаментом неспешности переключения между процессами в UNIX как раз-таки было время работы ядра, когда, образно говоря, принималось решение, кто будет работать следующим (поправьте, если ошибаюсь), снимались всякие статистические показатели и т.п. В этом свете процесс рисовался мне чем-то конкретным и потоки в нем были просто одной из характеристик.
А в QNX получается наоборот? Процесс — всего лишь абстракция, характеристика потока, как пользователя определенного участка адресного пространства?
А в QNX получается наоборот? Процесс — всего лишь абстракция, характеристика потока, как пользователя определенного участка адресного пространства?
Извините, но вода.
Как же она их решает, если основной простой во время переключения контекстов между процессами возникает из-за аппаратных причин: процессору необходимо время для выполнения всех проверок при загрузке сегментных регистров. При переключении контекстов потоков сегментные регистры и так уже имеют правильные значения, так как все современные ОС используют плоское адресное пространство.
Подробнее, например, см. wiki.osdev.org/Context_Switching#Performance_Considerations
Однако, архитектура QNX Neutrino решает проблему производительности переключения контекстов. И в QNX практически нет разницы в скорости переключения контекстов между процессами и потоками.
Как же она их решает, если основной простой во время переключения контекстов между процессами возникает из-за аппаратных причин: процессору необходимо время для выполнения всех проверок при загрузке сегментных регистров. При переключении контекстов потоков сегментные регистры и так уже имеют правильные значения, так как все современные ОС используют плоское адресное пространство.
Подробнее, например, см. wiki.osdev.org/Context_Switching#Performance_Considerations
Понял. Эта тема, думаю, будет интересна многим. Хорошо, попробую подготовить для неё материал.
Кстати, насколько мне известно, например, в Linux потоки реализованы на основе процессов. Т.е. механизм переключения контекстов потоков должен быть сложнее, чем в QNX.
Кстати, насколько мне известно, например, в Linux потоки реализованы на основе процессов. Т.е. механизм переключения контекстов потоков должен быть сложнее, чем в QNX.
> Кстати, насколько мне известно, например, в Linux потоки реализованы на основе процессов.
Грубо говоря, в Linux вообще нет такого понятия, как поток. Любой поток, для ядра и шедулера в нем, является самым обычным процессом. Единственное отличие заключается в том, что такой процесс разделяет адресное пространство с другим(и) процессом(ами).
Грубо говоря, в Linux вообще нет такого понятия, как поток. Любой поток, для ядра и шедулера в нем, является самым обычным процессом. Единственное отличие заключается в том, что такой процесс разделяет адресное пространство с другим(и) процессом(ами).
> Как же она их решает, если основной простой во время переключения контекстов между процессами возникает из-за аппаратных причин
Вообще-то нет. На *современных Intel* процессорах аппаратная составляющая является лишь небольшой частью.
Вот хорошая презентация от Paul Turner www.linuxplumbersconf.org/2013/ocw//system/presentations/1653/original/LPC%20-%20User%20Threading.pdf
Вкратце, futex занимает ~1ms при этом большая часть тратится в CPU scheduler. Забавно ведь текущий scheduler (CFQ scheduler) разрабатывался как упорщенный вариант для O(1), но со временем сам так оброс всевозможными corner cases что стал медленным. В гугл просто реализовали сисколл который пропускает CPU scheduler и напрямую переключает указанные процессы. Переключение происходит примерно в 10 раз быстрее.
Вообще-то нет. На *современных Intel* процессорах аппаратная составляющая является лишь небольшой частью.
Вот хорошая презентация от Paul Turner www.linuxplumbersconf.org/2013/ocw//system/presentations/1653/original/LPC%20-%20User%20Threading.pdf
Вкратце, futex занимает ~1ms при этом большая часть тратится в CPU scheduler. Забавно ведь текущий scheduler (CFQ scheduler) разрабатывался как упорщенный вариант для O(1), но со временем сам так оброс всевозможными corner cases что стал медленным. В гугл просто реализовали сисколл который пропускает CPU scheduler и напрямую переключает указанные процессы. Переключение происходит примерно в 10 раз быстрее.
>> Как же она их решает, если основной простой во время переключения контекстов между процессами возникает из-за аппаратных причин
Собственно, тот же вопрос возник при прочтении. Документация по QNX поясняет только «у нас упрощенное ядро, маленький контекст, поэтому мы его и переключаем быстрее».
Однако бенчмарки вот здесь www.qnx.com/download/group.html?programid=7963 (требует регистрации) действительно показывают реально быстрое переключение контекста, в разы или десятки раз быстрее Линукса. Это, видимо, связано с тем, что в QNX Neutrino полноценно реализовано ARM Fast Context Switch Extension. То есть виртуальное адресное пространство разбивается на слоты по 32 мегабайта и каждый процесс адресует только один свой слот. Понятно, что есть недостатки — процессу нужно в 32 мегабайта уместить код, данные, кучи, стеки потоков и разделяемые объекту. И самих процессов может быть строго ограниченное число (63 в Neutrino). Но есть крупное достоинство — при переключении контекста не флашатся кеши и поэтому он очень быстрый. Патчи для поддержки ARM FCSE для Линукса существуют, но, насколько я знаю, они не в мейнстриме.
Собственно, тот же вопрос возник при прочтении. Документация по QNX поясняет только «у нас упрощенное ядро, маленький контекст, поэтому мы его и переключаем быстрее».
Однако бенчмарки вот здесь www.qnx.com/download/group.html?programid=7963 (требует регистрации) действительно показывают реально быстрое переключение контекста, в разы или десятки раз быстрее Линукса. Это, видимо, связано с тем, что в QNX Neutrino полноценно реализовано ARM Fast Context Switch Extension. То есть виртуальное адресное пространство разбивается на слоты по 32 мегабайта и каждый процесс адресует только один свой слот. Понятно, что есть недостатки — процессу нужно в 32 мегабайта уместить код, данные, кучи, стеки потоков и разделяемые объекту. И самих процессов может быть строго ограниченное число (63 в Neutrino). Но есть крупное достоинство — при переключении контекста не флашатся кеши и поэтому он очень быстрый. Патчи для поддержки ARM FCSE для Линукса существуют, но, насколько я знаю, они не в мейнстриме.
это ответ на комментарий выше
аппаратный MMU дает большое преимущество, особенно в I/O
Вот уже не в первый раз сталкиваюсь с таким распространенным мнением, звучащим как «Если что-то не сделано в Линуксе — это не существует!» (варианты: «маркетинговый бред!», «невозможно в принципе!»).
Вы правы для ARMv4 архитектуры применяется такая технология и есть такие ограничения. Для ARMv6 (более современные процессоры) ограничения другие, по ссылке внизу есть табличка:
www.qnx.com/developers/docs/6.4.1/neutrino/user_guide/limits.html
www.qnx.com/developers/docs/6.4.1/neutrino/user_guide/limits.html
очень интересно, спасибо за статью.
а что, как там насчет пропатчить KDE под QNX? если вы понимаете о чем я.
а что, как там насчет пропатчить KDE под QNX? если вы понимаете о чем я.
Пропатчим. ;-}
Qt вполне успешно пропатчили, так что KDE вряд ли будет проблемой (при желании) :)
Большое спасибо, заинтересовало. С нетерпением жду продолжения. :]
Наверное стоит явно в заголовке упомянуть, что тут речь идет именно о QNX 6 (Neutrino). За статью спасибо!
Спасибо за статью. Помимо решения проблемы долгого переключения контекста, ещё очень интересно, как решается проблема падения таких процессов как менеджер памяти или драйвер жесткого диска.
Как считать драйвер с диска, если у нас упал драйвер диска?
Если упадёт менеджер памяти, пропадут ли все данные о распределении памяти между остальными процессами? (Практически это означает необходимость перезапустить всю систему (кроме микроядра).)
Как считать драйвер с диска, если у нас упал драйвер диска?
Если упадёт менеджер памяти, пропадут ли все данные о распределении памяти между остальными процессами? (Практически это означает необходимость перезапустить всю систему (кроме микроядра).)
Драйвер жёсткого диска можно перезапустить, например, с RAM-диска или из загрузочного образа, в котором тоже может быть файловая система, доступная для чтения. Можно запустить любую программу по сети.
Управляет памятью в QNX администратор ресурсов. Он выполняет очень важные задачи и очень хорошо отлажен. Обычно этот процесс падает при сбоях аппаратуры, что не предполагает дальнейшей работы ОС. Если администратор процессов упадёт, то сложно будет работать с системой. Память уже будет точно не перераспределить, но она не должна потеряться. Тут наверное нужен эксперимент. ;-}
Управляет памятью в QNX администратор ресурсов. Он выполняет очень важные задачи и очень хорошо отлажен. Обычно этот процесс падает при сбоях аппаратуры, что не предполагает дальнейшей работы ОС. Если администратор процессов упадёт, то сложно будет работать с системой. Память уже будет точно не перераспределить, но она не должна потеряться. Тут наверное нужен эксперимент. ;-}
Я просто думал, может у QNX есть внутри ядра механизм хранения образов драйверов, чтобы их перезапустить в случае чего.
А насчёт менеджера ресурсов — это любимая часть споров вокруг концепции микроядра — зачем выносить из ядра то, что при падении всё равно приведёт к падению всей системы.
Впрочем, когда смотришь на объём ядер Linux, Windows — идея микроядра кажется такой привлекательной. А уж как хочется иметь GUI лежащий поверх ОСРВ с гарантированным временем реакции…
А насчёт менеджера ресурсов — это любимая часть споров вокруг концепции микроядра — зачем выносить из ядра то, что при падении всё равно приведёт к падению всей системы.
Впрочем, когда смотришь на объём ядер Linux, Windows — идея микроядра кажется такой привлекательной. А уж как хочется иметь GUI лежащий поверх ОСРВ с гарантированным временем реакции…
Какой-то специальный механизм для хранения образов драйверов и не нужен. Достаточно стандартных технологий.
Менеджер ресурсов это несколько другое (по крайней мере в терминологии QNX). Менеджер ресурсов это программа, которая отвечает за элемент (или несколько) путевого имени. Например, для реализации /dev/ser1 требуется менеджер ресурсов.
Администратор процессов вынесен из ядра (хотя и составляет с ним единый модуль) по нескольким причинам. Самое главное, это реализация идеи микроядра QNX — только передача сообщений. Плюс к этому облегчается отладка и тестирование самого ядра. Ну и, конечно, в общем случае, администратор ресурсов не является необходимой частью системы и может либо вовсе не использоваться, либо быть заменён на другой.
Менеджер ресурсов это несколько другое (по крайней мере в терминологии QNX). Менеджер ресурсов это программа, которая отвечает за элемент (или несколько) путевого имени. Например, для реализации /dev/ser1 требуется менеджер ресурсов.
Администратор процессов вынесен из ядра (хотя и составляет с ним единый модуль) по нескольким причинам. Самое главное, это реализация идеи микроядра QNX — только передача сообщений. Плюс к этому облегчается отладка и тестирование самого ядра. Ну и, конечно, в общем случае, администратор ресурсов не является необходимой частью системы и может либо вовсе не использоваться, либо быть заменён на другой.
>Впрочем, когда смотришь на объём ядер Linux, Windows — идея микроядра кажется такой привлекательной. А уж как хочется иметь GUI лежащий поверх ОСРВ с гарантированным временем реакции…
а при чем тут объем? общее количество кода все равно останется тем же, просто его отдельные структурные единицы будет висеть не в общем адресном пространстве.
а при чем тут объем? общее количество кода все равно останется тем же, просто его отдельные структурные единицы будет висеть не в общем адресном пространстве.
В общем случае общий объём кода будет сопоставим, но… При каждой модификации монолитного ядра надо будет тестировать его целиком, в то время как при написании (доработке) драйвера в QNX, достаточно будет протестировать только сам драйвер.
Не забывайте о надёжности системы. В случае монолитного ядра любой драйвер может нагадить неизвестно где. А в микроядерной архитектуре каждый процесс работает в своём собственно адресном пространстве и изолирован от других процессов.
Не забывайте о надёжности системы. В случае монолитного ядра любой драйвер может нагадить неизвестно где. А в микроядерной архитектуре каждый процесс работает в своём собственно адресном пространстве и изолирован от других процессов.
>При каждой модификации монолитного ядра надо будет тестировать его целиком, в то время как при написании (доработке) драйвера в QNX, достаточно будет протестировать только сам драйвер.
это еще с какой стати? в монолитном драйвер точно так же может быть структурно отделен от остальной части системы.
>в микроядерной архитектуре каждый процесс работает в своём собственно адресном пространстве и изолирован от других процессов.
в случае микроядра у драйвера может тихо поехать указатель на структурку, в результате он пошлет сообщение говно на шину и она повиснет, что ничем не лучше затирания чужих данных.
изоляция адресного пространства спасает только от узкого набора ошибок, от которых надо не ограждаться хитрой архитектурой а вылавливать на тестировании.
это еще с какой стати? в монолитном драйвер точно так же может быть структурно отделен от остальной части системы.
>в микроядерной архитектуре каждый процесс работает в своём собственно адресном пространстве и изолирован от других процессов.
в случае микроядра у драйвера может тихо поехать указатель на структурку, в результате он пошлет сообщение говно на шину и она повиснет, что ничем не лучше затирания чужих данных.
изоляция адресного пространства спасает только от узкого набора ошибок, от которых надо не ограждаться хитрой архитектурой а вылавливать на тестировании.
> это еще с какой стати? в монолитном драйвер точно так же может быть структурно отделен от остальной части системы.
Очень просто. Если может случиться ошибка, то она точно случится. Вероятность не имеет значения, т.к. количество инсталляций может быть очень огромно. Если адресное пространство одно (а это так для монолитного ядра), то проверять надо весь модуль целиком (в данном случае всё ядро). Иначе no warranty.
> в случае микроядра у драйвера может тихо поехать указатель на структурку, в результате он пошлет сообщение говно на шину и она повиснет, что ничем не лучше затирания чужих данных.
Во-первых, такая ошибка нетипична и должна отлавливаться на стресс-тестах. Во-вторых, ничего страшного от кривого сообщения не происходит. Вернётся в ответ ENOSYS, ENOTSUP или ещё что-то в этом роде вот и всё.
Очень просто. Если может случиться ошибка, то она точно случится. Вероятность не имеет значения, т.к. количество инсталляций может быть очень огромно. Если адресное пространство одно (а это так для монолитного ядра), то проверять надо весь модуль целиком (в данном случае всё ядро). Иначе no warranty.
> в случае микроядра у драйвера может тихо поехать указатель на структурку, в результате он пошлет сообщение говно на шину и она повиснет, что ничем не лучше затирания чужих данных.
Во-первых, такая ошибка нетипична и должна отлавливаться на стресс-тестах. Во-вторых, ничего страшного от кривого сообщения не происходит. Вернётся в ответ ENOSYS, ENOTSUP или ещё что-то в этом роде вот и всё.
>Если адресное пространство одно (а это так для монолитного ядра), то проверять надо весь модуль целиком (в данном случае всё ядро). Иначе no warranty.
почему у вас критерием модульности является адресное пространство? я считаю, это некорректно.
>ничего страшного от кривого сообщения не происходит.
нет, вы не поняли, что я имел ввиду: сообщение в терминах IPC будет корректным, но payload из-за ошибок работы с памятью будет содержать кривые данные, запись которых в устройство будет либо его вешать, либо нарушать работу *других* драйверов.
без интеграционного теста, который проверит всю систему вы это точно так же не поймаете.
почему у вас критерием модульности является адресное пространство? я считаю, это некорректно.
>ничего страшного от кривого сообщения не происходит.
нет, вы не поняли, что я имел ввиду: сообщение в терминах IPC будет корректным, но payload из-за ошибок работы с памятью будет содержать кривые данные, запись которых в устройство будет либо его вешать, либо нарушать работу *других* драйверов.
без интеграционного теста, который проверит всю систему вы это точно так же не поймаете.
О критерии модульности я пока не говорил. Хотя, на мой взгляд, разумно считать модулями процессы.
Сообщение не может быть некорректным в терминах IPC, т.к. ядро передаёт в виде сообщения просто набор байт и ему нет дела до содержимого. Для микроядра формат сообщения не важен, в нём есть смысл только для отправителя и получателя.
Да, программа может из-за какой-то своей (вернее, программиста) ошибки слать кривые данные. Но я пока не очень понимаю, как это приведёт к зависанию хоть чего-то. Принимающая сторона должна проверить данные на корректность, а уж кривые они или нет — никто не знает. Ну будут в сеть уходить кривые пакеты, кто из-за этого повиснет? А уж как работа одного драйвера будет влиять на другой драйвер — непонятно.
> без интеграционного теста, который проверит всю систему вы это точно так же не поймаете.
Такие тесты в обязательном порядке проводятся в QNX.
Я так понял, что можно долго спорить на пустом месте. Предлагаю отложить эту дискуссию. Один из следующих топиков будет посвящён передаче сообщений в QNX, тогда должно стать яснее и появятся более конкретные вопросы.
Сообщение не может быть некорректным в терминах IPC, т.к. ядро передаёт в виде сообщения просто набор байт и ему нет дела до содержимого. Для микроядра формат сообщения не важен, в нём есть смысл только для отправителя и получателя.
Да, программа может из-за какой-то своей (вернее, программиста) ошибки слать кривые данные. Но я пока не очень понимаю, как это приведёт к зависанию хоть чего-то. Принимающая сторона должна проверить данные на корректность, а уж кривые они или нет — никто не знает. Ну будут в сеть уходить кривые пакеты, кто из-за этого повиснет? А уж как работа одного драйвера будет влиять на другой драйвер — непонятно.
> без интеграционного теста, который проверит всю систему вы это точно так же не поймаете.
Такие тесты в обязательном порядке проводятся в QNX.
Я так понял, что можно долго спорить на пустом месте. Предлагаю отложить эту дискуссию. Один из следующих топиков будет посвящён передаче сообщений в QNX, тогда должно стать яснее и появятся более конкретные вопросы.
>Но я пока не очень понимаю, как это приведёт к зависанию хоть чего-то.
>А уж как работа одного драйвера будет влиять на другой драйвер — непонятно.
ну вот живет на железке какой-то ASIC с пачкой своих прерываний и подключенный по I2C.
«путаем педали» в драйвере соседнего I2C устройства и со словами «ой» получаем крах системы, потомучто ASIC воспринял эту чушь, как команду на маскировку/размаскировку прерывания, отключение усилка или еще что-то фатальное.
ну не бывает изоляции — все равно все друг на друга как-то влияют.
>Такие тесты в обязательном порядке проводятся в QNX.
ну так к чему спорить? все равно получившийся продукт весь тестируется вне зависимости от того, кто там на каком кольце защиты висит и какую память адресует.
>А уж как работа одного драйвера будет влиять на другой драйвер — непонятно.
ну вот живет на железке какой-то ASIC с пачкой своих прерываний и подключенный по I2C.
«путаем педали» в драйвере соседнего I2C устройства и со словами «ой» получаем крах системы, потомучто ASIC воспринял эту чушь, как команду на маскировку/размаскировку прерывания, отключение усилка или еще что-то фатальное.
ну не бывает изоляции — все равно все друг на друга как-то влияют.
>Такие тесты в обязательном порядке проводятся в QNX.
ну так к чему спорить? все равно получившийся продукт весь тестируется вне зависимости от того, кто там на каком кольце защиты висит и какую память адресует.
> Ну будут в сеть уходить кривые пакеты, кто из-за этого повиснет?
От кривых (не соответствующих спецификации) сообщений/пакетов всё ещё и как виснет. И даже приводит к arbitrary code execution уязвимостям. Примеров — тысячи, потому что распарсить пакет сложной структуры — та ещё задача, а если нужно ещё и не упасть при обработке некорректного пакета, то вдвойне более сложная.
От кривых (не соответствующих спецификации) сообщений/пакетов всё ещё и как виснет. И даже приводит к arbitrary code execution уязвимостям. Примеров — тысячи, потому что распарсить пакет сложной структуры — та ещё задача, а если нужно ещё и не упасть при обработке некорректного пакета, то вдвойне более сложная.
Приведите примеры, пожалуйста. Примеры таких пакетов и примеры таких ошибок.
Я уже не говорю о том, что ошибку программиста (вернее её последствия) мы вынесли из системы (имеется в виду QNX и микроядро). Но изначально я только лишь сказал, что сама система надёжнее.
И вероятность такой волшебной ошибки, чтобы сетевой драйвер микроядерной системы слал пакеты-убийцы, соответствует аналогичной вероятности для Linux системы, например. Но о таких ошибках я не слышал ни в QNX, ни в Linux. Считаю это пустой демагогией.
Я уже не говорю о том, что ошибку программиста (вернее её последствия) мы вынесли из системы (имеется в виду QNX и микроядро). Но изначально я только лишь сказал, что сама система надёжнее.
И вероятность такой волшебной ошибки, чтобы сетевой драйвер микроядерной системы слал пакеты-убийцы, соответствует аналогичной вероятности для Linux системы, например. Но о таких ошибках я не слышал ни в QNX, ни в Linux. Считаю это пустой демагогией.
>сетевой драйвер микроядерной системы
да при чем тут сетевой?
ну вот смотрите псевдокодом:
если buffer — указатеь на данные, которые были освобождены и затерты мусором, то какая разница, мы сунем указатель на этот мусор соседнему потоку или скукожим содержимое в IPC сообщение, которое отправим в изолированный драйвер i2c контроллера?
ну вот нихрена же разницы — что так, что так в устройство будет записан одинаковый мусор. если устройство — критичный компонент системы, типа PMIC, то «ой» наступит одинаково и в досе и в линупсе и в qnx.
да при чем тут сетевой?
ну вот смотрите псевдокодом:
i2c_send(&client, address, buffer);
если buffer — указатеь на данные, которые были освобождены и затерты мусором, то какая разница, мы сунем указатель на этот мусор соседнему потоку или скукожим содержимое в IPC сообщение, которое отправим в изолированный драйвер i2c контроллера?
ну вот нихрена же разницы — что так, что так в устройство будет записан одинаковый мусор. если устройство — критичный компонент системы, типа PMIC, то «ой» наступит одинаково и в досе и в линупсе и в qnx.
В Вашем примере, может быть, и нет разницы. Но разница будет, если этот пример немного перевернуть:
В случае микроядра драйвер портит жизнь только себе, а в случае монолитного ядра указатель buffer может указывать на данные любого другого драйвера. Или даже не драйвера вовсе.
i2c_recive(&client, address, buffer);В случае микроядра драйвер портит жизнь только себе, а в случае монолитного ядра указатель buffer может указывать на данные любого другого драйвера. Или даже не драйвера вовсе.
> Приведите примеры, пожалуйста. Примеры таких пакетов и примеры таких ошибок.
Если говорить именно о сетевых пакетах, то легендарный Ping of death, думаю, знают все. В сниффере Wireshark просто пачками находят уязвимости в коде парсинга сетевых пакетов. Из свежего в мире Windows secunia.com/advisories/43299 (и это не совпадение, ошибки такого рода исправляют каждую patch tuesday). Достаточно примеров?
> И вероятность такой волшебной ошибки, чтобы сетевой драйвер микроядерной системы слал пакеты-убийцы
А речь шла о другом. О том, что каждый драйвер в QNX принимает сообщения и должен их парсить. И вот тут нужно предусмотреть все необходимые проверки, что, как доказывает практика парсинга сетевых протоколов и различных форматов данных, является очень непростой задачей.
Если говорить именно о сетевых пакетах, то легендарный Ping of death, думаю, знают все. В сниффере Wireshark просто пачками находят уязвимости в коде парсинга сетевых пакетов. Из свежего в мире Windows secunia.com/advisories/43299 (и это не совпадение, ошибки такого рода исправляют каждую patch tuesday). Достаточно примеров?
> И вероятность такой волшебной ошибки, чтобы сетевой драйвер микроядерной системы слал пакеты-убийцы
А речь шла о другом. О том, что каждый драйвер в QNX принимает сообщения и должен их парсить. И вот тут нужно предусмотреть все необходимые проверки, что, как доказывает практика парсинга сетевых протоколов и различных форматов данных, является очень непростой задачей.
>Достаточно примеров?
Пока недостаточно. Первый пример это какой-то раритет, во втором случае очередная дырка винды. И во втором случае надо готовить специальный ответ, на особый запрос. Случайно этого не добьёшься.
Я просил привести примеры, когда ошибка в одной системе приводила к отправке кривого пакета и краху другой системы, которая этот сетевой пакет получила. Ведь об этом Вы изначально говорили. Вы привели примеры ошибок в системах, когда они готовы умереть приняв пакет подготовленный злоумышленником особым образом.
> А речь шла о другом. О том, что каждый драйвер в QNX принимает сообщения и должен их парсить.
Вы опять пытаетесь завалить сервер? Так это другая задача. Это ни в коем случае не может быть ошибкой драйвера. Драйвер должен работать тупо: читать из устройства и писать в устройство. Думать должен тот, кто работает через драйвер. В случае QNX Вы можете завалить железку, которой управляет драйвер. Это Ваше личное дело. В случае монолитного ядра, Вы можете с помощью драйвера завалить даже железку, которой он не управляет. Или само монолитное ядро. Вот и вся разница.
Пока недостаточно. Первый пример это какой-то раритет, во втором случае очередная дырка винды. И во втором случае надо готовить специальный ответ, на особый запрос. Случайно этого не добьёшься.
Я просил привести примеры, когда ошибка в одной системе приводила к отправке кривого пакета и краху другой системы, которая этот сетевой пакет получила. Ведь об этом Вы изначально говорили. Вы привели примеры ошибок в системах, когда они готовы умереть приняв пакет подготовленный злоумышленником особым образом.
> А речь шла о другом. О том, что каждый драйвер в QNX принимает сообщения и должен их парсить.
Вы опять пытаетесь завалить сервер? Так это другая задача. Это ни в коем случае не может быть ошибкой драйвера. Драйвер должен работать тупо: читать из устройства и писать в устройство. Думать должен тот, кто работает через драйвер. В случае QNX Вы можете завалить железку, которой управляет драйвер. Это Ваше личное дело. В случае монолитного ядра, Вы можете с помощью драйвера завалить даже железку, которой он не управляет. Или само монолитное ядро. Вот и вся разница.
> Случайно этого не добьёшься.
Добьёшься. Все эти ошибки, особенно в закрытом коде винды, находят случайным тестированием (гуглите fuzzing).
> Вы привели примеры ошибок в системах, когда они готовы умереть приняв пакет подготовленный злоумышленником особым образом.
Приняв особо подготовленный пакет они выполняют код из этого пакета (именно в этом и суть эксплуатации). А приняв просто испорченный пакет (грубо говоря, испорчено то же поле, но в остальных нет кода эксплоита) они вполне себе упадут.
> Драйвер должен работать тупо: читать из устройства и писать в устройство. Думать должен тот, кто работает через драйвер.
К счастью программистов, так не бывает. Не бывает, чтобы вся «думалка» была на одном уровне абстракции. Драйвер ФС взаимодействует с пользовательскими программами, думает и взаимодействует с драйвером блочного устройства, которым оказывается драйвер RAID, который тоже думает и взаимодействует с другим драйвером блочного устройства, который тоже думает и взаимодействует с драйвером контроллера, который тоже немного думает и, наконец, взаимодействует с железом.
Добьёшься. Все эти ошибки, особенно в закрытом коде винды, находят случайным тестированием (гуглите fuzzing).
> Вы привели примеры ошибок в системах, когда они готовы умереть приняв пакет подготовленный злоумышленником особым образом.
Приняв особо подготовленный пакет они выполняют код из этого пакета (именно в этом и суть эксплуатации). А приняв просто испорченный пакет (грубо говоря, испорчено то же поле, но в остальных нет кода эксплоита) они вполне себе упадут.
> Драйвер должен работать тупо: читать из устройства и писать в устройство. Думать должен тот, кто работает через драйвер.
К счастью программистов, так не бывает. Не бывает, чтобы вся «думалка» была на одном уровне абстракции. Драйвер ФС взаимодействует с пользовательскими программами, думает и взаимодействует с драйвером блочного устройства, которым оказывается драйвер RAID, который тоже думает и взаимодействует с другим драйвером блочного устройства, который тоже думает и взаимодействует с драйвером контроллера, который тоже немного думает и, наконец, взаимодействует с железом.
Т.е. Вы мне решили рассказать, как работают драйверы? Хорошо, постою послушаю.
Только уже сейчас я не понял, о чём думают все эти драйверы в Вашем примере. Какая разница драйверу файловой системы, с каким драйвером общаться? Хранятся ли блоки в ОЗУ, на диске или во flash? Если драйверу файловой системы нужно подстраиваться под каждый драйвер блочного устройства, то это не UNIX way. Это, должно быть, негодные драйверы, по моему скромному мнению. И я скажу почему. При замене или доработке одного драйвера, придётся обновлять всю цепочку.
Только уже сейчас я не понял, о чём думают все эти драйверы в Вашем примере. Какая разница драйверу файловой системы, с каким драйвером общаться? Хранятся ли блоки в ОЗУ, на диске или во flash? Если драйверу файловой системы нужно подстраиваться под каждый драйвер блочного устройства, то это не UNIX way. Это, должно быть, негодные драйверы, по моему скромному мнению. И я скажу почему. При замене или доработке одного драйвера, придётся обновлять всю цепочку.
Драйверу ФС нужно думать о том, как преобразовать высокоуровневый запрос пользователя в запросы чтения/записи блоков.
>Какая разница драйверу файловой системы, с каким драйвером общаться? Хранятся ли блоки в ОЗУ, на диске или во flash?
огромная.
на флеше нельзя менять данные маленькими порциями и у него есть ресурс перезаписи, а у hdd напротив есть seek time.
для флеш-накопителей без транслейшн-леера вообще нужно специальные файловые системы юзать, которые старяются данные дописывать, а не писать поверх.
огромная.
на флеше нельзя менять данные маленькими порциями и у него есть ресурс перезаписи, а у hdd напротив есть seek time.
для флеш-накопителей без транслейшн-леера вообще нужно специальные файловые системы юзать, которые старяются данные дописывать, а не писать поверх.
Так. Вы всё правильно говорите. Теперь сделайте ещё один маленький шажок вперёд. И мы придём к тому, что не драйвер должен думать, а администратор системы. Если администратор (или архитектор) системы решил, что на flash ему нужна обычная файловая система с поддержкой ATIME, то это его личное дело.
И, кстати, в QNX, на ряду с файловыми системами QNX4 и QNX6 (да, они называются также, как и сама ОС), есть ещё и файловая система для flash — FFS3.
Если же файловая система будет сама решать, как и что ей делать, то это будет противоречить философии UNIX. Не думаю, что из такого противореция получится что-то хорошее.
Мне кажется, что идёт разговор слепого с глухим. Вы почему-то никак не хотите меня понять. Наверное, я просто что-то неправильно объясняю.
И, кстати, в QNX, на ряду с файловыми системами QNX4 и QNX6 (да, они называются также, как и сама ОС), есть ещё и файловая система для flash — FFS3.
Если же файловая система будет сама решать, как и что ей делать, то это будет противоречить философии UNIX. Не думаю, что из такого противореция получится что-то хорошее.
Мне кажется, что идёт разговор слепого с глухим. Вы почему-то никак не хотите меня понять. Наверное, я просто что-то неправильно объясняю.
>В случае монолитного ядра, Вы можете с помощью драйвера завалить даже железку, которой он не управляет.
а кто мне помешает это сделать в микроядерной? поломалась память в моем процессе — и данные вместо моего устройства уже поехали соседнему на шине.
а кто мне помешает это сделать в микроядерной? поломалась память в моем процессе — и данные вместо моего устройства уже поехали соседнему на шине.
Скажите, к чему скорее приведёт испорченный указатель: к проблемам в собственном процессе или к проблемам в другом процессе? Если Вы не будете лукавить, то выберете первый вариант, хотя и второй вариант возможен. И можно придумать тысячи способов повредить другому процессу. Но суммарная вероятность всех этих способов будет пренебрежимо мала. Вот об этом я и говорю.
Кто Вам сказал, что если в процессе, который работает в микроядерной ОС поломается память (учтите, что сама память не ломается, её ломает программист), то он начнёт слать данные по шине (по какой шине?) другому устройству? Отвечать необязательно.
Кто Вам сказал, что если в процессе, который работает в микроядерной ОС поломается память (учтите, что сама память не ломается, её ломает программист), то он начнёт слать данные по шине (по какой шине?) другому устройству? Отвечать необязательно.
Странно, почему речь идет только о QNX драйвере, который принимает сообщения и должен их парсить. Драйвер в QNX действительно парсит пакеты в части его касающейся и никоим образом не занимается разбором содержимого пакета данных для устройства или программы. Я всегда считал, что и в других системах аналогичный подход — драйвер по сути выполняет транспорт между прикладной задачей и устройством.
Спорить об ошибках, приводящих к краху одной или другой системы — неблагодарное занятие. Всегда можно придумать такие ошибки, от которых нет «защиты» и вводить ее в драйвер просто нецелесообразно.
Спорить об ошибках, приводящих к краху одной или другой системы — неблагодарное занятие. Всегда можно придумать такие ошибки, от которых нет «защиты» и вводить ее в драйвер просто нецелесообразно.
Одно только разнесение по разным адресным пространствам сильно снижает вероятность ошибок.
>Одно только разнесение по разным адресным пространствам сильно снижает вероятность ошибок.
откуда при написании примерно одинакового количества кода приблизительно одинаковой сложности возьмется меньшее количество ошибок? тем более, что с микроядром написание драйвера может быть сложнее.
или вы имели ввиду вероятность фатального сбоя?
откуда при написании примерно одинакового количества кода приблизительно одинаковой сложности возьмется меньшее количество ошибок? тем более, что с микроядром написание драйвера может быть сложнее.
или вы имели ввиду вероятность фатального сбоя?
Вероятность ошибки примерно равна. Но последствия ошибки получаются разные. Так что, наверное, whiteglasses имел в виду крах операционной системы (в нашем случае ядра). Тут я согласен.
Написание драйвера для QNX это рядовая задача. И написание это пол дела, так и отладка — одно удовольствие. Обычным GDB и без всяких изысков можно отлаживать, практически в любом месте (кроме обработчиков прерывания) можно вставлять контрольную печать в виде printf(). На фоне этого о написании драйверов для Windows и Linux стараюсь не думать…
Написание драйвера для QNX это рядовая задача. И написание это пол дела, так и отладка — одно удовольствие. Обычным GDB и без всяких изысков можно отлаживать, практически в любом месте (кроме обработчиков прерывания) можно вставлять контрольную печать в виде printf(). На фоне этого о написании драйверов для Windows и Linux стараюсь не думать…
>так что, наверное, whiteglasses имел в виду крах операционной системы (в нашем случае ядра)
так я еще большую тайну открою: кривой доступ к памяти и вылет процесса в ядре, например линукса, совершенно не всегда приводит к его краху, если он не произошел в обработчике прерывания.
проблема конечно в том, что он сам не переподнимется, но хотябы насрать в лог, сбросить кеши и более-менее штатно уйти в ребут вполне возможно.
>Написание драйвера для QNX это рядовая задача. И написание это пол дела, так и отладка — одно удовольствие.
как будто для написания драйвера для линукса нужно танцевать ритуальный танец и брать справку из жека. пишу в перерывах между комментариями на хабре:
habrahabr.ru/blogs/linux/123266/#comment_4048002
>практически в любом месте (кроме обработчиков прерывания) можно вставлять контрольную печать в виде printf()
что-то я не понимаю, какая проблема в линуксовых драйверах с printf(), кроме того, что он называется printk()?
так я еще большую тайну открою: кривой доступ к памяти и вылет процесса в ядре, например линукса, совершенно не всегда приводит к его краху, если он не произошел в обработчике прерывания.
проблема конечно в том, что он сам не переподнимется, но хотябы насрать в лог, сбросить кеши и более-менее штатно уйти в ребут вполне возможно.
>Написание драйвера для QNX это рядовая задача. И написание это пол дела, так и отладка — одно удовольствие.
как будто для написания драйвера для линукса нужно танцевать ритуальный танец и брать справку из жека. пишу в перерывах между комментариями на хабре:
habrahabr.ru/blogs/linux/123266/#comment_4048002
>практически в любом месте (кроме обработчиков прерывания) можно вставлять контрольную печать в виде printf()
что-то я не понимаю, какая проблема в линуксовых драйверах с printf(), кроме того, что он называется printk()?
Я знаю об этой страшной тайне. Достигается это тем, что в ядре Linux есть обработчик исключения, который отключает нерадивый модуль. По мне так это как раз и есть усложнение и «хитрая архитектура», о которой Вы говорили.
Хорошо, что проблему с Linux Вы признаёте. Она тут действительно есть. Хотя заметьте, я говорил о монолитном ядре как таковом, а это не только Linux.
Чтобы написать драйвер для Linux справка из жека, конечно, не нужна. Но мне приходилось писать драйвер для Linux, несколько драйверов приходилось разбирать… Даже если отбросить проблемы с запутанностью кода, могу Вам точно сказать, что драйвер для QNX пишется проще. В простейшем случае (если это драйвер какого-нибудь АЦП), то и API других драйверов знать не нужно.
Согласитесь, что printf() и printk() это уже две разные функции. И это только маленький пример.
Я не хочу ничего плохого сказать про Linux, у него есть свои плюсы, но есть и минусы, которых может не быть в других операционную системах. Если бы QNX ничем в лучшую сторону не отличался от Linux, то не было бы миллионов инсталляций QNX.
Хорошо, что проблему с Linux Вы признаёте. Она тут действительно есть. Хотя заметьте, я говорил о монолитном ядре как таковом, а это не только Linux.
Чтобы написать драйвер для Linux справка из жека, конечно, не нужна. Но мне приходилось писать драйвер для Linux, несколько драйверов приходилось разбирать… Даже если отбросить проблемы с запутанностью кода, могу Вам точно сказать, что драйвер для QNX пишется проще. В простейшем случае (если это драйвер какого-нибудь АЦП), то и API других драйверов знать не нужно.
Согласитесь, что printf() и printk() это уже две разные функции. И это только маленький пример.
Я не хочу ничего плохого сказать про Linux, у него есть свои плюсы, но есть и минусы, которых может не быть в других операционную системах. Если бы QNX ничем в лучшую сторону не отличался от Linux, то не было бы миллионов инсталляций QNX.
>могу Вам точно сказать, что драйвер для QNX пишется проще
объясните, чем конкретно проще. я подозреваю, что это субъективно — вы просто привыкли к QNX, а архитектура ядра линукса вам ненастолько знакома.
>В простейшем случае (если это драйвер какого-нибудь АЦП), то и API других драйверов знать не нужно.
ну так я вам точно так же могу сказать — в простейшем случае, в линуксе надо знать только API той подсистемы, для которой пишется драйвер и общий API регистрации устройств и драйверов.
объясните, чем конкретно проще. я подозреваю, что это субъективно — вы просто привыкли к QNX, а архитектура ядра линукса вам ненастолько знакома.
>В простейшем случае (если это драйвер какого-нибудь АЦП), то и API других драйверов знать не нужно.
ну так я вам точно так же могу сказать — в простейшем случае, в линуксе надо знать только API той подсистемы, для которой пишется драйвер и общий API регистрации устройств и драйверов.
Простите, я несколько неясно выразился. В QNX для написания простого драйвера не надо знать «API той подсистемы, для которой пишется драйвер». Более того, в QNX нет как такового «общего API регистрации и драйверов». Есть такое понятие как регистрация путевого имени или устройства в /dev/, но это делается просто и называется менеджер ресурсов.
Вы подали мне интересную мысль. Буду готовить тему с пошаговой инструкцией написания драйвера для QNX. ;-}
Может быть Вы и правы, я, наверное, привык к QNX. Но есть мнения наших заказчиков, иногда могу сравнить, как пишутся одни и те же драйверы для Linux и QNX (бывают такие системы, где требуется поддержка нескольких ОС). Пока всё это подтверждает моё мнение.
Вы подали мне интересную мысль. Буду готовить тему с пошаговой инструкцией написания драйвера для QNX. ;-}
Может быть Вы и правы, я, наверное, привык к QNX. Но есть мнения наших заказчиков, иногда могу сравнить, как пишутся одни и те же драйверы для Linux и QNX (бывают такие системы, где требуется поддержка нескольких ОС). Пока всё это подтверждает моё мнение.
>Вы подали мне интересную мысль. Буду готовить тему с пошаговой инструкцией написания драйвера для QNX. ;-}
да, покажите что-то простое и деревянное, но показывающее инфраструктуру.
>В QNX для написания простого драйвера не надо знать «API той подсистемы, для которой пишется драйвер»
и как я напишу драйвер для i2c устройства, если не знаю API работы с контроллером i2c шины?
да, покажите что-то простое и деревянное, но показывающее инфраструктуру.
>В QNX для написания простого драйвера не надо знать «API той подсистемы, для которой пишется драйвер»
и как я напишу драйвер для i2c устройства, если не знаю API работы с контроллером i2c шины?
>да, покажите что-то простое и деревянное, но показывающее инфраструктуру
Кстати, идея: определяется некая базовая функциональность «простого и деревянного» драйвера, после чего автор пишет статью о написании драйвера под QNX, а ты — аналогичную статью для Linux. На живом примере сразу будут видны ключевые сходства/различия/особенности и пр.
Кстати, идея: определяется некая базовая функциональность «простого и деревянного» драйвера, после чего автор пишет статью о написании драйвера под QNX, а ты — аналогичную статью для Linux. На живом примере сразу будут видны ключевые сходства/различия/особенности и пр.
Я не против. Надо только согласовать всё. Пишите в личку.
>Пишите в личку.
Думаю, вам лучше напрямую связаться с muromec, чтобы не играть в испорченный телефон.
Думаю, вам лучше напрямую связаться с muromec, чтобы не играть в испорченный телефон.
Как и обещал, подготовил топик по планированию потоков в QNX6.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ОСРВ QNX: Немного о микроядре, потоках и процессах