Я тоже считаю, что RIM не станет выпускать смартфон, который не совместим с остальными. Тут, скорее всего, слухи врут. А вот добавить поддержку ActiveSync вполне могут.
Или, может быть, что-то по администрированию. Например, создание загрузочного образа для какого-то оборудования? Мне кажется, что тоже интересная тема.
Да, я тоже думаю, что адаптивная декомпозиция тема самостоятельная и может быть раскрыта позже. А вот передача сообщений и прочий IPC это необходимая ступенька для качественного описания Qnet.
Да, думаю, что дойдём и до кода. Шибко грязных хаков не обещаю, но, думаю, будет интересно. Хотя все желающие смотреть на код могут найти его в избытке в справочной системе уже сейчас.
О чём в следующий раз рассказать? Про адаптивную декомпозицию или про передачу сообщений? Я бы про передачу сообщений рассказал, после этого можно было бы про QNX сеть Qnet написать.
Ну да, но одно дело написать программу, а другое дело ОС реального времени, которая используется в коммерческой эксплуатации по всему миру уже более 10 лет (это только QNX6).
Скажите, к чему скорее приведёт испорченный указатель: к проблемам в собственном процессе или к проблемам в другом процессе? Если Вы не будете лукавить, то выберете первый вариант, хотя и второй вариант возможен. И можно придумать тысячи способов повредить другому процессу. Но суммарная вероятность всех этих способов будет пренебрежимо мала. Вот об этом я и говорю.
Кто Вам сказал, что если в процессе, который работает в микроядерной ОС поломается память (учтите, что сама память не ломается, её ломает программист), то он начнёт слать данные по шине (по какой шине?) другому устройству? Отвечать необязательно.
Так. Вы всё правильно говорите. Теперь сделайте ещё один маленький шажок вперёд. И мы придём к тому, что не драйвер должен думать, а администратор системы. Если администратор (или архитектор) системы решил, что на flash ему нужна обычная файловая система с поддержкой ATIME, то это его личное дело.
И, кстати, в QNX, на ряду с файловыми системами QNX4 и QNX6 (да, они называются также, как и сама ОС), есть ещё и файловая система для flash — FFS3.
Если же файловая система будет сама решать, как и что ей делать, то это будет противоречить философии UNIX. Не думаю, что из такого противореция получится что-то хорошее.
Мне кажется, что идёт разговор слепого с глухим. Вы почему-то никак не хотите меня понять. Наверное, я просто что-то неправильно объясняю.
Лично я говорил о преимуществах микроядерной архитектуры перед монолитной. И я уже устал повторять, что ошибка в драйве микроядерной ОС будет иметь более локальные последствия, чем в монолитной системе. Больше на эту тему не буду тут распространяться.
Т.е. Вы мне решили рассказать, как работают драйверы? Хорошо, постою послушаю.
Только уже сейчас я не понял, о чём думают все эти драйверы в Вашем примере. Какая разница драйверу файловой системы, с каким драйвером общаться? Хранятся ли блоки в ОЗУ, на диске или во flash? Если драйверу файловой системы нужно подстраиваться под каждый драйвер блочного устройства, то это не UNIX way. Это, должно быть, негодные драйверы, по моему скромному мнению. И я скажу почему. При замене или доработке одного драйвера, придётся обновлять всю цепочку.
Пока недостаточно. Первый пример это какой-то раритет, во втором случае очередная дырка винды. И во втором случае надо готовить специальный ответ, на особый запрос. Случайно этого не добьёшься.
Я просил привести примеры, когда ошибка в одной системе приводила к отправке кривого пакета и краху другой системы, которая этот сетевой пакет получила. Ведь об этом Вы изначально говорили. Вы привели примеры ошибок в системах, когда они готовы умереть приняв пакет подготовленный злоумышленником особым образом.
> А речь шла о другом. О том, что каждый драйвер в QNX принимает сообщения и должен их парсить.
Вы опять пытаетесь завалить сервер? Так это другая задача. Это ни в коем случае не может быть ошибкой драйвера. Драйвер должен работать тупо: читать из устройства и писать в устройство. Думать должен тот, кто работает через драйвер. В случае QNX Вы можете завалить железку, которой управляет драйвер. Это Ваше личное дело. В случае монолитного ядра, Вы можете с помощью драйвера завалить даже железку, которой он не управляет. Или само монолитное ядро. Вот и вся разница.
В Вашем примере, может быть, и нет разницы. Но разница будет, если этот пример немного перевернуть:
i2c_recive(&client, address, buffer);
В случае микроядра драйвер портит жизнь только себе, а в случае монолитного ядра указатель buffer может указывать на данные любого другого драйвера. Или даже не драйвера вовсе.
Приведите примеры, пожалуйста. Примеры таких пакетов и примеры таких ошибок.
Я уже не говорю о том, что ошибку программиста (вернее её последствия) мы вынесли из системы (имеется в виду QNX и микроядро). Но изначально я только лишь сказал, что сама система надёжнее.
И вероятность такой волшебной ошибки, чтобы сетевой драйвер микроядерной системы слал пакеты-убийцы, соответствует аналогичной вероятности для Linux системы, например. Но о таких ошибках я не слышал ни в QNX, ни в Linux. Считаю это пустой демагогией.
Да, думаю, что дойдём и до кода. Шибко грязных хаков не обещаю, но, думаю, будет интересно. Хотя все желающие смотреть на код могут найти его в избытке в справочной системе уже сейчас.
Кто Вам сказал, что если в процессе, который работает в микроядерной ОС поломается память (учтите, что сама память не ломается, её ломает программист), то он начнёт слать данные по шине (по какой шине?) другому устройству? Отвечать необязательно.
И, кстати, в QNX, на ряду с файловыми системами QNX4 и QNX6 (да, они называются также, как и сама ОС), есть ещё и файловая система для flash — FFS3.
Если же файловая система будет сама решать, как и что ей делать, то это будет противоречить философии UNIX. Не думаю, что из такого противореция получится что-то хорошее.
Мне кажется, что идёт разговор слепого с глухим. Вы почему-то никак не хотите меня понять. Наверное, я просто что-то неправильно объясняю.
Только уже сейчас я не понял, о чём думают все эти драйверы в Вашем примере. Какая разница драйверу файловой системы, с каким драйвером общаться? Хранятся ли блоки в ОЗУ, на диске или во flash? Если драйверу файловой системы нужно подстраиваться под каждый драйвер блочного устройства, то это не UNIX way. Это, должно быть, негодные драйверы, по моему скромному мнению. И я скажу почему. При замене или доработке одного драйвера, придётся обновлять всю цепочку.
Пока недостаточно. Первый пример это какой-то раритет, во втором случае очередная дырка винды. И во втором случае надо готовить специальный ответ, на особый запрос. Случайно этого не добьёшься.
Я просил привести примеры, когда ошибка в одной системе приводила к отправке кривого пакета и краху другой системы, которая этот сетевой пакет получила. Ведь об этом Вы изначально говорили. Вы привели примеры ошибок в системах, когда они готовы умереть приняв пакет подготовленный злоумышленником особым образом.
> А речь шла о другом. О том, что каждый драйвер в QNX принимает сообщения и должен их парсить.
Вы опять пытаетесь завалить сервер? Так это другая задача. Это ни в коем случае не может быть ошибкой драйвера. Драйвер должен работать тупо: читать из устройства и писать в устройство. Думать должен тот, кто работает через драйвер. В случае QNX Вы можете завалить железку, которой управляет драйвер. Это Ваше личное дело. В случае монолитного ядра, Вы можете с помощью драйвера завалить даже железку, которой он не управляет. Или само монолитное ядро. Вот и вся разница.
В случае микроядра драйвер портит жизнь только себе, а в случае монолитного ядра указатель buffer может указывать на данные любого другого драйвера. Или даже не драйвера вовсе.
Я уже не говорю о том, что ошибку программиста (вернее её последствия) мы вынесли из системы (имеется в виду QNX и микроядро). Но изначально я только лишь сказал, что сама система надёжнее.
И вероятность такой волшебной ошибки, чтобы сетевой драйвер микроядерной системы слал пакеты-убийцы, соответствует аналогичной вероятности для Linux системы, например. Но о таких ошибках я не слышал ни в QNX, ни в Linux. Считаю это пустой демагогией.