если buffer — указатеь на данные, которые были освобождены и затерты мусором, то какая разница, мы сунем указатель на этот мусор соседнему потоку или скукожим содержимое в IPC сообщение, которое отправим в изолированный драйвер i2c контроллера?
ну вот нихрена же разницы — что так, что так в устройство будет записан одинаковый мусор. если устройство — критичный компонент системы, типа PMIC, то «ой» наступит одинаково и в досе и в линупсе и в qnx.
>Но я пока не очень понимаю, как это приведёт к зависанию хоть чего-то.
>А уж как работа одного драйвера будет влиять на другой драйвер — непонятно.
ну вот живет на железке какой-то ASIC с пачкой своих прерываний и подключенный по I2C.
«путаем педали» в драйвере соседнего I2C устройства и со словами «ой» получаем крах системы, потомучто ASIC воспринял эту чушь, как команду на маскировку/размаскировку прерывания, отключение усилка или еще что-то фатальное.
ну не бывает изоляции — все равно все друг на друга как-то влияют.
>Такие тесты в обязательном порядке проводятся в QNX.
ну так к чему спорить? все равно получившийся продукт весь тестируется вне зависимости от того, кто там на каком кольце защиты висит и какую память адресует.
>могу Вам точно сказать, что драйвер для QNX пишется проще
объясните, чем конкретно проще. я подозреваю, что это субъективно — вы просто привыкли к QNX, а архитектура ядра линукса вам ненастолько знакома.
>В простейшем случае (если это драйвер какого-нибудь АЦП), то и API других драйверов знать не нужно.
ну так я вам точно так же могу сказать — в простейшем случае, в линуксе надо знать только API той подсистемы, для которой пишется драйвер и общий API регистрации устройств и драйверов.
>Если адресное пространство одно (а это так для монолитного ядра), то проверять надо весь модуль целиком (в данном случае всё ядро). Иначе no warranty.
почему у вас критерием модульности является адресное пространство? я считаю, это некорректно.
>ничего страшного от кривого сообщения не происходит.
нет, вы не поняли, что я имел ввиду: сообщение в терминах IPC будет корректным, но payload из-за ошибок работы с памятью будет содержать кривые данные, запись которых в устройство будет либо его вешать, либо нарушать работу *других* драйверов.
без интеграционного теста, который проверит всю систему вы это точно так же не поймаете.
>так что, наверное, whiteglasses имел в виду крах операционной системы (в нашем случае ядра)
так я еще большую тайну открою: кривой доступ к памяти и вылет процесса в ядре, например линукса, совершенно не всегда приводит к его краху, если он не произошел в обработчике прерывания.
проблема конечно в том, что он сам не переподнимется, но хотябы насрать в лог, сбросить кеши и более-менее штатно уйти в ребут вполне возможно.
>Написание драйвера для QNX это рядовая задача. И написание это пол дела, так и отладка — одно удовольствие.
как будто для написания драйвера для линукса нужно танцевать ритуальный танец и брать справку из жека. пишу в перерывах между комментариями на хабре:
>При каждой модификации монолитного ядра надо будет тестировать его целиком, в то время как при написании (доработке) драйвера в QNX, достаточно будет протестировать только сам драйвер.
это еще с какой стати? в монолитном драйвер точно так же может быть структурно отделен от остальной части системы.
>в микроядерной архитектуре каждый процесс работает в своём собственно адресном пространстве и изолирован от других процессов.
в случае микроядра у драйвера может тихо поехать указатель на структурку, в результате он пошлет сообщение говно на шину и она повиснет, что ничем не лучше затирания чужих данных.
изоляция адресного пространства спасает только от узкого набора ошибок, от которых надо не ограждаться хитрой архитектурой а вылавливать на тестировании.
>Одно только разнесение по разным адресным пространствам сильно снижает вероятность ошибок.
откуда при написании примерно одинакового количества кода приблизительно одинаковой сложности возьмется меньшее количество ошибок? тем более, что с микроядром написание драйвера может быть сложнее.
а кто мне помешает это сделать в микроядерной? поломалась память в моем процессе — и данные вместо моего устройства уже поехали соседнему на шине.
всех человеков, переводящих технические термины «близко по смыслу» нужно долго и больно лупить по голове чугуниевым контекстом.
да при чем тут сетевой?
ну вот смотрите псевдокодом:
если buffer — указатеь на данные, которые были освобождены и затерты мусором, то какая разница, мы сунем указатель на этот мусор соседнему потоку или скукожим содержимое в IPC сообщение, которое отправим в изолированный драйвер i2c контроллера?
ну вот нихрена же разницы — что так, что так в устройство будет записан одинаковый мусор. если устройство — критичный компонент системы, типа PMIC, то «ой» наступит одинаково и в досе и в линупсе и в qnx.
ну хоть кто-то заметил подвох!
вот кстати давно хочется такую штуку, которая хоть файлы нормально синхронизирует.
inb4 dropbox: не кромссплатформенно, не секюрно, негибко и вообще не особо умнее rsync.
драйвер контроллера вполне может и без ФС тихо насрать в лог, сделать ретрай и ФС ничего не узнает.
кроме того, что-то я не помню такого поведения, например у линуксовых фс, при котором ядерный драйвер САМ обновлял таблицу сбойных блоков.
обычно как раз диск сыпется, в логах срач, бедблоки сиди ищи руками и руками же в фс их список закидывай.
возможно мой опыт в данном вопросе не такой широкий, так как у меня нет коробочки с сотней жестких дисков для хранения разных версий Евангелиона.
практически возможны варианты — ядро делает ретрай записи или фс обрабатывает ошибку и что-то делает (уход в ro, паника. итд).
это же под виндами происходило, да?
да, покажите что-то простое и деревянное, но показывающее инфраструктуру.
>В QNX для написания простого драйвера не надо знать «API той подсистемы, для которой пишется драйвер»
и как я напишу драйвер для i2c устройства, если не знаю API работы с контроллером i2c шины?
>А уж как работа одного драйвера будет влиять на другой драйвер — непонятно.
ну вот живет на железке какой-то ASIC с пачкой своих прерываний и подключенный по I2C.
«путаем педали» в драйвере соседнего I2C устройства и со словами «ой» получаем крах системы, потомучто ASIC воспринял эту чушь, как команду на маскировку/размаскировку прерывания, отключение усилка или еще что-то фатальное.
ну не бывает изоляции — все равно все друг на друга как-то влияют.
>Такие тесты в обязательном порядке проводятся в QNX.
ну так к чему спорить? все равно получившийся продукт весь тестируется вне зависимости от того, кто там на каком кольце защиты висит и какую память адресует.
помню, раскукоживал в одном месте такой рассадник информации длиной в 1000 постов, накопившееся за полгода и удалял лишние — ужас
объясните, чем конкретно проще. я подозреваю, что это субъективно — вы просто привыкли к QNX, а архитектура ядра линукса вам ненастолько знакома.
>В простейшем случае (если это драйвер какого-нибудь АЦП), то и API других драйверов знать не нужно.
ну так я вам точно так же могу сказать — в простейшем случае, в линуксе надо знать только API той подсистемы, для которой пишется драйвер и общий API регистрации устройств и драйверов.
почему у вас критерием модульности является адресное пространство? я считаю, это некорректно.
>ничего страшного от кривого сообщения не происходит.
нет, вы не поняли, что я имел ввиду: сообщение в терминах IPC будет корректным, но payload из-за ошибок работы с памятью будет содержать кривые данные, запись которых в устройство будет либо его вешать, либо нарушать работу *других* драйверов.
без интеграционного теста, который проверит всю систему вы это точно так же не поймаете.
так я еще большую тайну открою: кривой доступ к памяти и вылет процесса в ядре, например линукса, совершенно не всегда приводит к его краху, если он не произошел в обработчике прерывания.
проблема конечно в том, что он сам не переподнимется, но хотябы насрать в лог, сбросить кеши и более-менее штатно уйти в ребут вполне возможно.
>Написание драйвера для QNX это рядовая задача. И написание это пол дела, так и отладка — одно удовольствие.
как будто для написания драйвера для линукса нужно танцевать ритуальный танец и брать справку из жека. пишу в перерывах между комментариями на хабре:
habrahabr.ru/blogs/linux/123266/#comment_4048002
>практически в любом месте (кроме обработчиков прерывания) можно вставлять контрольную печать в виде printf()
что-то я не понимаю, какая проблема в линуксовых драйверах с printf(), кроме того, что он называется printk()?
это еще с какой стати? в монолитном драйвер точно так же может быть структурно отделен от остальной части системы.
>в микроядерной архитектуре каждый процесс работает в своём собственно адресном пространстве и изолирован от других процессов.
в случае микроядра у драйвера может тихо поехать указатель на структурку, в результате он пошлет сообщение говно на шину и она повиснет, что ничем не лучше затирания чужих данных.
изоляция адресного пространства спасает только от узкого набора ошибок, от которых надо не ограждаться хитрой архитектурой а вылавливать на тестировании.
откуда при написании примерно одинакового количества кода приблизительно одинаковой сложности возьмется меньшее количество ошибок? тем более, что с микроядром написание драйвера может быть сложнее.
или вы имели ввиду вероятность фатального сбоя?
эээ… он же занимается, например, выделением памяти, как система будет без него работать?