Пока недостаточно. Первый пример это какой-то раритет, во втором случае очередная дырка винды. И во втором случае надо готовить специальный ответ, на особый запрос. Случайно этого не добьёшься.
Я просил привести примеры, когда ошибка в одной системе приводила к отправке кривого пакета и краху другой системы, которая этот сетевой пакет получила. Ведь об этом Вы изначально говорили. Вы привели примеры ошибок в системах, когда они готовы умереть приняв пакет подготовленный злоумышленником особым образом.
> А речь шла о другом. О том, что каждый драйвер в QNX принимает сообщения и должен их парсить.
Вы опять пытаетесь завалить сервер? Так это другая задача. Это ни в коем случае не может быть ошибкой драйвера. Драйвер должен работать тупо: читать из устройства и писать в устройство. Думать должен тот, кто работает через драйвер. В случае QNX Вы можете завалить железку, которой управляет драйвер. Это Ваше личное дело. В случае монолитного ядра, Вы можете с помощью драйвера завалить даже железку, которой он не управляет. Или само монолитное ядро. Вот и вся разница.
В Вашем примере, может быть, и нет разницы. Но разница будет, если этот пример немного перевернуть:
i2c_recive(&client, address, buffer);
В случае микроядра драйвер портит жизнь только себе, а в случае монолитного ядра указатель buffer может указывать на данные любого другого драйвера. Или даже не драйвера вовсе.
Приведите примеры, пожалуйста. Примеры таких пакетов и примеры таких ошибок.
Я уже не говорю о том, что ошибку программиста (вернее её последствия) мы вынесли из системы (имеется в виду QNX и микроядро). Но изначально я только лишь сказал, что сама система надёжнее.
И вероятность такой волшебной ошибки, чтобы сетевой драйвер микроядерной системы слал пакеты-убийцы, соответствует аналогичной вероятности для Linux системы, например. Но о таких ошибках я не слышал ни в QNX, ни в Linux. Считаю это пустой демагогией.
Решил в заголовке не менять, во вступлении написано, что это о QNX6. Всё-таки именно о QNX6 сейчас полезнее рассказывать, т.к. QNX4 всем известен, кто им занимается, и некоммерческой лицензии на него нет.
Простите, я несколько неясно выразился. В QNX для написания простого драйвера не надо знать «API той подсистемы, для которой пишется драйвер». Более того, в QNX нет как такового «общего API регистрации и драйверов». Есть такое понятие как регистрация путевого имени или устройства в /dev/, но это делается просто и называется менеджер ресурсов.
Вы подали мне интересную мысль. Буду готовить тему с пошаговой инструкцией написания драйвера для QNX. ;-}
Может быть Вы и правы, я, наверное, привык к QNX. Но есть мнения наших заказчиков, иногда могу сравнить, как пишутся одни и те же драйверы для Linux и QNX (бывают такие системы, где требуется поддержка нескольких ОС). Пока всё это подтверждает моё мнение.
О критерии модульности я пока не говорил. Хотя, на мой взгляд, разумно считать модулями процессы.
Сообщение не может быть некорректным в терминах IPC, т.к. ядро передаёт в виде сообщения просто набор байт и ему нет дела до содержимого. Для микроядра формат сообщения не важен, в нём есть смысл только для отправителя и получателя.
Да, программа может из-за какой-то своей (вернее, программиста) ошибки слать кривые данные. Но я пока не очень понимаю, как это приведёт к зависанию хоть чего-то. Принимающая сторона должна проверить данные на корректность, а уж кривые они или нет — никто не знает. Ну будут в сеть уходить кривые пакеты, кто из-за этого повиснет? А уж как работа одного драйвера будет влиять на другой драйвер — непонятно.
> без интеграционного теста, который проверит всю систему вы это точно так же не поймаете.
Такие тесты в обязательном порядке проводятся в QNX.
Я так понял, что можно долго спорить на пустом месте. Предлагаю отложить эту дискуссию. Один из следующих топиков будет посвящён передаче сообщений в QNX, тогда должно стать яснее и появятся более конкретные вопросы.
Я знаю об этой страшной тайне. Достигается это тем, что в ядре Linux есть обработчик исключения, который отключает нерадивый модуль. По мне так это как раз и есть усложнение и «хитрая архитектура», о которой Вы говорили.
Хорошо, что проблему с Linux Вы признаёте. Она тут действительно есть. Хотя заметьте, я говорил о монолитном ядре как таковом, а это не только Linux.
Чтобы написать драйвер для Linux справка из жека, конечно, не нужна. Но мне приходилось писать драйвер для Linux, несколько драйверов приходилось разбирать… Даже если отбросить проблемы с запутанностью кода, могу Вам точно сказать, что драйвер для QNX пишется проще. В простейшем случае (если это драйвер какого-нибудь АЦП), то и API других драйверов знать не нужно.
Согласитесь, что printf() и printk() это уже две разные функции. И это только маленький пример.
Я не хочу ничего плохого сказать про Linux, у него есть свои плюсы, но есть и минусы, которых может не быть в других операционную системах. Если бы QNX ничем в лучшую сторону не отличался от Linux, то не было бы миллионов инсталляций QNX.
> это еще с какой стати? в монолитном драйвер точно так же может быть структурно отделен от остальной части системы.
Очень просто. Если может случиться ошибка, то она точно случится. Вероятность не имеет значения, т.к. количество инсталляций может быть очень огромно. Если адресное пространство одно (а это так для монолитного ядра), то проверять надо весь модуль целиком (в данном случае всё ядро). Иначе no warranty.
> в случае микроядра у драйвера может тихо поехать указатель на структурку, в результате он пошлет сообщение говно на шину и она повиснет, что ничем не лучше затирания чужих данных.
Во-первых, такая ошибка нетипична и должна отлавливаться на стресс-тестах. Во-вторых, ничего страшного от кривого сообщения не происходит. Вернётся в ответ ENOSYS, ENOTSUP или ещё что-то в этом роде вот и всё.
Вероятность ошибки примерно равна. Но последствия ошибки получаются разные. Так что, наверное, whiteglasses имел в виду крах операционной системы (в нашем случае ядра). Тут я согласен.
Написание драйвера для QNX это рядовая задача. И написание это пол дела, так и отладка — одно удовольствие. Обычным GDB и без всяких изысков можно отлаживать, практически в любом месте (кроме обработчиков прерывания) можно вставлять контрольную печать в виде printf(). На фоне этого о написании драйверов для Windows и Linux стараюсь не думать…
В общем случае общий объём кода будет сопоставим, но… При каждой модификации монолитного ядра надо будет тестировать его целиком, в то время как при написании (доработке) драйвера в QNX, достаточно будет протестировать только сам драйвер.
Не забывайте о надёжности системы. В случае монолитного ядра любой драйвер может нагадить неизвестно где. А в микроядерной архитектуре каждый процесс работает в своём собственно адресном пространстве и изолирован от других процессов.
Какой-то специальный механизм для хранения образов драйверов и не нужен. Достаточно стандартных технологий.
Менеджер ресурсов это несколько другое (по крайней мере в терминологии QNX). Менеджер ресурсов это программа, которая отвечает за элемент (или несколько) путевого имени. Например, для реализации /dev/ser1 требуется менеджер ресурсов.
Администратор процессов вынесен из ядра (хотя и составляет с ним единый модуль) по нескольким причинам. Самое главное, это реализация идеи микроядра QNX — только передача сообщений. Плюс к этому облегчается отладка и тестирование самого ядра. Ну и, конечно, в общем случае, администратор ресурсов не является необходимой частью системы и может либо вовсе не использоваться, либо быть заменён на другой.
Драйвер жёсткого диска можно перезапустить, например, с RAM-диска или из загрузочного образа, в котором тоже может быть файловая система, доступная для чтения. Можно запустить любую программу по сети.
Управляет памятью в QNX администратор ресурсов. Он выполняет очень важные задачи и очень хорошо отлажен. Обычно этот процесс падает при сбоях аппаратуры, что не предполагает дальнейшей работы ОС. Если администратор процессов упадёт, то сложно будет работать с системой. Память уже будет точно не перераспределить, но она не должна потеряться. Тут наверное нужен эксперимент. ;-}
Понял. Эта тема, думаю, будет интересна многим. Хорошо, попробую подготовить для неё материал.
Кстати, насколько мне известно, например, в Linux потоки реализованы на основе процессов. Т.е. механизм переключения контекстов потоков должен быть сложнее, чем в QNX.
Вы правы для ARMv4 архитектуры применяется такая технология и есть такие ограничения. Для ARMv6 (более современные процессоры) ограничения другие, по ссылке внизу есть табличка:
Пока недостаточно. Первый пример это какой-то раритет, во втором случае очередная дырка винды. И во втором случае надо готовить специальный ответ, на особый запрос. Случайно этого не добьёшься.
Я просил привести примеры, когда ошибка в одной системе приводила к отправке кривого пакета и краху другой системы, которая этот сетевой пакет получила. Ведь об этом Вы изначально говорили. Вы привели примеры ошибок в системах, когда они готовы умереть приняв пакет подготовленный злоумышленником особым образом.
> А речь шла о другом. О том, что каждый драйвер в QNX принимает сообщения и должен их парсить.
Вы опять пытаетесь завалить сервер? Так это другая задача. Это ни в коем случае не может быть ошибкой драйвера. Драйвер должен работать тупо: читать из устройства и писать в устройство. Думать должен тот, кто работает через драйвер. В случае QNX Вы можете завалить железку, которой управляет драйвер. Это Ваше личное дело. В случае монолитного ядра, Вы можете с помощью драйвера завалить даже железку, которой он не управляет. Или само монолитное ядро. Вот и вся разница.
В случае микроядра драйвер портит жизнь только себе, а в случае монолитного ядра указатель buffer может указывать на данные любого другого драйвера. Или даже не драйвера вовсе.
Я уже не говорю о том, что ошибку программиста (вернее её последствия) мы вынесли из системы (имеется в виду QNX и микроядро). Но изначально я только лишь сказал, что сама система надёжнее.
И вероятность такой волшебной ошибки, чтобы сетевой драйвер микроядерной системы слал пакеты-убийцы, соответствует аналогичной вероятности для Linux системы, например. Но о таких ошибках я не слышал ни в QNX, ни в Linux. Считаю это пустой демагогией.
Вы подали мне интересную мысль. Буду готовить тему с пошаговой инструкцией написания драйвера для QNX. ;-}
Может быть Вы и правы, я, наверное, привык к QNX. Но есть мнения наших заказчиков, иногда могу сравнить, как пишутся одни и те же драйверы для Linux и QNX (бывают такие системы, где требуется поддержка нескольких ОС). Пока всё это подтверждает моё мнение.
Сообщение не может быть некорректным в терминах IPC, т.к. ядро передаёт в виде сообщения просто набор байт и ему нет дела до содержимого. Для микроядра формат сообщения не важен, в нём есть смысл только для отправителя и получателя.
Да, программа может из-за какой-то своей (вернее, программиста) ошибки слать кривые данные. Но я пока не очень понимаю, как это приведёт к зависанию хоть чего-то. Принимающая сторона должна проверить данные на корректность, а уж кривые они или нет — никто не знает. Ну будут в сеть уходить кривые пакеты, кто из-за этого повиснет? А уж как работа одного драйвера будет влиять на другой драйвер — непонятно.
> без интеграционного теста, который проверит всю систему вы это точно так же не поймаете.
Такие тесты в обязательном порядке проводятся в QNX.
Я так понял, что можно долго спорить на пустом месте. Предлагаю отложить эту дискуссию. Один из следующих топиков будет посвящён передаче сообщений в QNX, тогда должно стать яснее и появятся более конкретные вопросы.
Хорошо, что проблему с Linux Вы признаёте. Она тут действительно есть. Хотя заметьте, я говорил о монолитном ядре как таковом, а это не только Linux.
Чтобы написать драйвер для Linux справка из жека, конечно, не нужна. Но мне приходилось писать драйвер для Linux, несколько драйверов приходилось разбирать… Даже если отбросить проблемы с запутанностью кода, могу Вам точно сказать, что драйвер для QNX пишется проще. В простейшем случае (если это драйвер какого-нибудь АЦП), то и API других драйверов знать не нужно.
Согласитесь, что printf() и printk() это уже две разные функции. И это только маленький пример.
Я не хочу ничего плохого сказать про Linux, у него есть свои плюсы, но есть и минусы, которых может не быть в других операционную системах. Если бы QNX ничем в лучшую сторону не отличался от Linux, то не было бы миллионов инсталляций QNX.
Очень просто. Если может случиться ошибка, то она точно случится. Вероятность не имеет значения, т.к. количество инсталляций может быть очень огромно. Если адресное пространство одно (а это так для монолитного ядра), то проверять надо весь модуль целиком (в данном случае всё ядро). Иначе no warranty.
> в случае микроядра у драйвера может тихо поехать указатель на структурку, в результате он пошлет сообщение говно на шину и она повиснет, что ничем не лучше затирания чужих данных.
Во-первых, такая ошибка нетипична и должна отлавливаться на стресс-тестах. Во-вторых, ничего страшного от кривого сообщения не происходит. Вернётся в ответ ENOSYS, ENOTSUP или ещё что-то в этом роде вот и всё.
Написание драйвера для QNX это рядовая задача. И написание это пол дела, так и отладка — одно удовольствие. Обычным GDB и без всяких изысков можно отлаживать, практически в любом месте (кроме обработчиков прерывания) можно вставлять контрольную печать в виде printf(). На фоне этого о написании драйверов для Windows и Linux стараюсь не думать…
Не забывайте о надёжности системы. В случае монолитного ядра любой драйвер может нагадить неизвестно где. А в микроядерной архитектуре каждый процесс работает в своём собственно адресном пространстве и изолирован от других процессов.
Менеджер ресурсов это несколько другое (по крайней мере в терминологии QNX). Менеджер ресурсов это программа, которая отвечает за элемент (или несколько) путевого имени. Например, для реализации /dev/ser1 требуется менеджер ресурсов.
Администратор процессов вынесен из ядра (хотя и составляет с ним единый модуль) по нескольким причинам. Самое главное, это реализация идеи микроядра QNX — только передача сообщений. Плюс к этому облегчается отладка и тестирование самого ядра. Ну и, конечно, в общем случае, администратор ресурсов не является необходимой частью системы и может либо вовсе не использоваться, либо быть заменён на другой.
Управляет памятью в QNX администратор ресурсов. Он выполняет очень важные задачи и очень хорошо отлажен. Обычно этот процесс падает при сбоях аппаратуры, что не предполагает дальнейшей работы ОС. Если администратор процессов упадёт, то сложно будет работать с системой. Память уже будет точно не перераспределить, но она не должна потеряться. Тут наверное нужен эксперимент. ;-}
Кстати, насколько мне известно, например, в Linux потоки реализованы на основе процессов. Т.е. механизм переключения контекстов потоков должен быть сложнее, чем в QNX.
www.qnx.com/developers/docs/6.4.1/neutrino/user_guide/limits.html