архив
Комментарии к статье
Сергей Кузнецов: Драйверы вне ядра - мнения Таненбаума и Гейтса сходятся?
Тема действительно старая, как и большинство идей (если не все идеи) в области операционных систем. Но мне очень нравится настойчивость Эндрью. И ведь на самом деле получается. А что касается Гейтса, то, во-первых, я бы не стал брать в кавычки "соображения", поскольку можно по разному к нему относиться, но отказать ему в уме и сообразительности, по-моему, нельзя. Во-вторых, если он действительно читал книжки Таненбаума и вспомнил об этой идее при ответе на вопрос, то честь ему и хвала. Не все миллиардеры читают хорошие книжки. А мне лично будет очень любопытно, если в Windows действительно разгрузят ядро.
Вряд ли они его разгрузят
Потому как основой их стратегией на сегодня
являеться ограничение доступа к внутреностям их оси
Попытка заставить програмиста пользоваться только интерфесами и фреймворками
Не добавят так же и потому, что тогда придеться давать юзверю возможность ручного управления
"соображения" -- это просто чтоб подчеркнуть,
что сам Билл, лично, дизайном ядра не занимаеться
у него для этого.. башковитых хватает
Потому как основой их стратегией на сегодня
являеться ограничение доступа к внутреностям их оси
Попытка заставить програмиста пользоваться только интерфесами и фреймворками
Не добавят так же и потому, что тогда придеться давать юзверю возможность ручного управления
"соображения" -- это просто чтоб подчеркнуть,
что сам Билл, лично, дизайном ядра не занимаеться
у него для этого.. башковитых хватает
Спасибо Сергею Кузнецову за позитив :)
У Гейтса все сходится только в одном: отобрать у юзера доступ в ядро их системы нафиг, чтобы вы не дай боже не сломали их драгоценный DRM.
> Попытка заставить програмиста пользоваться только интерфесами и фреймворками
А чтоб вы не могли поломать цифорвой ошейник в виде DRM.Ну и всякую спайварную дрянь типа WGA замочить.В 64-битной висте очень интересно сделано с подписью драйверов ядра, почитайте технические доки у MS на сайте, весьма познавательно.По сути MS все и за всех в итоге решает, какой драйвер вам загрузить можно а какой - низзя.А до кучи можно и вендоров железа на бабки ставить - не отвалишь денег, хрен подпишешь драйвер, железо будет никому нафиг не надо.Еруто придумано, да?Весь кернел-моде режим "модерируется" микрософтом.Красота... от вирусов конечно надолго это не спасет, но вот от ЮЗЕРА (т.е. вас) это (вашу) систему защищает неплохо.
А чтоб вы не могли поломать цифорвой ошейник в виде DRM.Ну и всякую спайварную дрянь типа WGA замочить.В 64-битной висте очень интересно сделано с подписью драйверов ядра, почитайте технические доки у MS на сайте, весьма познавательно.По сути MS все и за всех в итоге решает, какой драйвер вам загрузить можно а какой - низзя.А до кучи можно и вендоров железа на бабки ставить - не отвалишь денег, хрен подпишешь драйвер, железо будет никому нафиг не надо.Еруто придумано, да?Весь кернел-моде режим "модерируется" микрософтом.Красота... от вирусов конечно надолго это не спасет, но вот от ЮЗЕРА (т.е. вас) это (вашу) систему защищает неплохо.
"...QNX является коммерческой UNIX-подобной системой реального времени с закрытыми кодами [17]... Однако на основе последних проспектов мы заключаем, что Neutrino является гибридным ядром, поскольку менеджер процессов работает в адресном пространстве ядра..."
Зря Вы так считаете :-) ! PM не в адресном пространстве ядра. Читаем "QNX Architecture" на сайте QSSL
Зря Вы так считаете :-) ! PM не в адресном пространстве ядра. Читаем "QNX Architecture" на сайте QSSL
Если авторы статьи в чем-то ошибаются, нужно дать им знать. Но я что-то не могу найти на http://www.qssl.com/ материал под названием "Архитектура QNX". Есть "Microkernel Architecture" (http://www.qssl.com/products/rtos/microkernel.html), но там ничего не говорится про менеджер процессов. Неплохо было бы в комментариях давать прямые ссылки на материалы для экономии общего времени.
Что касаеться MINIX 3 -- очередное творение кабинетного ученого
Основная "фича" -- надежность
В том виде как она там предлагаеться (ho-plug драйвера), в таком виде (сейчас?) никому не нужна
Рассмотрим ситуации
Домашний\офисный комп -- перезагрузки из-за сбойных драйверов неприятны, но отнюдь НЕ критичны
Зато негарантированная работа драйвера после восставновления.. это означает, что когда вы посылаете напечатать стостраничный отчет, где-то в середина драйвер сбиваеться и печать возобновляеться с первого листа :)))) до следующего сбоя... :)) оч нужная фича
Сервер -- набор драйверов там строго ограничен и гарантированно отлично протестирован.. зачем там эта "фича"???
Единстенный вариант для которого может быть удобна такая супернадежность -- для сервера удаленного тестирования драйверов :)))
Представте.. вы заливаете свой глючный драйвер на комп где-то_там.. он естественно вылетает.. но вы все равно имеете возможность посмотреть логи ;)
Основная "фича" -- надежность
В том виде как она там предлагаеться (ho-plug драйвера), в таком виде (сейчас?) никому не нужна
Рассмотрим ситуации
Домашний\офисный комп -- перезагрузки из-за сбойных драйверов неприятны, но отнюдь НЕ критичны
Зато негарантированная работа драйвера после восставновления.. это означает, что когда вы посылаете напечатать стостраничный отчет, где-то в середина драйвер сбиваеться и печать возобновляеться с первого листа :)))) до следующего сбоя... :)) оч нужная фича
Сервер -- набор драйверов там строго ограничен и гарантированно отлично протестирован.. зачем там эта "фича"???
Единстенный вариант для которого может быть удобна такая супернадежность -- для сервера удаленного тестирования драйверов :)))
Представте.. вы заливаете свой глючный драйвер на комп где-то_там.. он естественно вылетает.. но вы все равно имеете возможность посмотреть логи ;)
дайте мне подходящий дрйвер и я ядро переверну!
Очень интересно было бы знать, по каким признакам госп. Аку-Аку отличает кабинетных ученых от ученых некабинентных. Насколько я знаю Таненбаума, он наименее кабинетен из всех знакомых мне профессоров. На абсолютно практической конференции Usenix он является одним из основных авторитетов. И мне кажется, что в настоящее время он один из наиболее авторитетных исследователей в области эволюционных подходов к совершенствованию операционных систем. Я не собираюсь спорить по поводу правильности подхода Minix 3 к повышению надежности операционных систем, здесь каждый имеет право на собственное мнение, но лично мне всегда претит излишняя уверенность в правоте.
>>...но лично мне всегда претит излишняя уверенность в правоте.
если вас так беспокоит мое "нахальство"
то скажу что правота не моя, а фактической ситуации (еще со времен появления ядра Линукса)
и ничего оскорбительного против Таненбаума я не писал.. с чего бы мне выступать против такого уважаемого и знающего человека?
единственно.. мое кредо "сначала истина, а потом авторитет"
исследования Таненбаума -- важны, но именно как академические (кабинетные) и могут быть полезны.. когда-нибудь потом
если вас так беспокоит мое "нахальство"
то скажу что правота не моя, а фактической ситуации (еще со времен появления ядра Линукса)
и ничего оскорбительного против Таненбаума я не писал.. с чего бы мне выступать против такого уважаемого и знающего человека?
единственно.. мое кредо "сначала истина, а потом авторитет"
исследования Таненбаума -- важны, но именно как академические (кабинетные) и могут быть полезны.. когда-нибудь потом
Я не спец в данном вопросе, но настораживает вот что: ни слова не сказано о надежности средств обеспечения надежности. Такая славная вещь, как "сервер реинкарняции". А сколько ошибок в нем? Если мало строк кода, то мала функциональность и наоборот . А ведь согласно "некоторым источникам" ошибки есть все равно. Не так ли?
Аку-Аку.
Прежде чем рассуждать об этом, Вы могли бы попоробовать Миникс 3. Его можно запросто скачать и под ВМВарей запустить. Почитать манаул по Миниксу. Там очень подробно описана архитектура и демон "восстановления".
А заодно купите журнал "Хакер" и посмотрите, какие методы используют, для распространения вирусов, троянов и прочей гадости в Виндоус.
Вот после этого, у Вас есть полное право рассуждать по этой теме.
На мой взгляд, архитектура ОС предложенная Танненбаумом еще несколько лет назад, является более устойчивой к сбоям и "вредным" изменениям, чем используемые ныне в Виндоус и Линуксе.
Прежде чем рассуждать об этом, Вы могли бы попоробовать Миникс 3. Его можно запросто скачать и под ВМВарей запустить. Почитать манаул по Миниксу. Там очень подробно описана архитектура и демон "восстановления".
А заодно купите журнал "Хакер" и посмотрите, какие методы используют, для распространения вирусов, троянов и прочей гадости в Виндоус.
Вот после этого, у Вас есть полное право рассуждать по этой теме.
На мой взгляд, архитектура ОС предложенная Танненбаумом еще несколько лет назад, является более устойчивой к сбоям и "вредным" изменениям, чем используемые ныне в Виндоус и Линуксе.
Подозреваю, что на замечание госп. Alex'а должен ответить я, хотя это мог бы сделать любой опытный программист. Конечно, в любой программе могут содержаться ошибки. Чем больше и сложнее программа, тем больше в ней ошибок и тем сложнее их выловить. Наиболее сложными и трудно обнаруживаемыми ошибками являются те, которые редко проявляются. В архитектуре MINIX 3 объем кода, ошибки в котором фатальны для системы в целом, существенно меньше, чем в других ОС. Сам этот код архитектурно проще. Поэтому вероятность его достаточно полной отладки становится выше. В принципе, становится возможным исчерпывающее тестирование, хотя на практике в условиях университета его вряд ли возможно выполнить. Но повышается вероятность постепенного вылавливания всех ошибок при использовании системы другими людьми, поскольку код открыт и сравнительно прост. Естественно, минимальность и простота кода минимального ядра и сервера реинкарнации не означает снижение функциональных возможностей ОС в целом. Просто эта функциональность обеспечивается компонентами, выполняемыми в пользовательском режиме.
>>Вот после этого, у Вас есть полное право
>>рассуждать по этой теме.
Ну вот и я нарвался на "специалиста" (по посту уровня подготовки не видать ;)) ) готового поучать
Что ж.. может быть -- поделом
>>На мой взгляд, архитектура ОС предложенная
>>Танненбаумом еще несколько лет назад, является
>>более устойчивой к сбоям и "вредным"
>>изменениям, чем используемые ныне в Виндоус и
>>Линуксе.
Устойчива ТА система, в которой НЕ происходит сбоев, а не та которая умеет их "быстренько и прикольненько" исправлять.
Потому как основной фактор такой нестабильности -- человек.
Исходя из этого можно предположить даже меньшую устойчивость из-за вмешательства человека в работу ядра (настраивать сервер реинкарнаций, кто будет?)
А вот какраз исчерпывающего анализа факторов ненадежности и тем самым аргументированного подтверждения необходимости указанных "фич" -- нету (возможно есть в другой статье)
Есть только псевдоумное "а кто откажеться от большей надежности?"
>>рассуждать по этой теме.
Ну вот и я нарвался на "специалиста" (по посту уровня подготовки не видать ;)) ) готового поучать
Что ж.. может быть -- поделом
>>На мой взгляд, архитектура ОС предложенная
>>Танненбаумом еще несколько лет назад, является
>>более устойчивой к сбоям и "вредным"
>>изменениям, чем используемые ныне в Виндоус и
>>Линуксе.
Устойчива ТА система, в которой НЕ происходит сбоев, а не та которая умеет их "быстренько и прикольненько" исправлять.
Потому как основной фактор такой нестабильности -- человек.
Исходя из этого можно предположить даже меньшую устойчивость из-за вмешательства человека в работу ядра (настраивать сервер реинкарнаций, кто будет?)
А вот какраз исчерпывающего анализа факторов ненадежности и тем самым аргументированного подтверждения необходимости указанных "фич" -- нету (возможно есть в другой статье)
Есть только псевдоумное "а кто откажеться от большей надежности?"
>>Вот после этого, у Вас есть полное право
>>рассуждать по этой теме.
Ну вот и я нарвался на "специалиста" (по посту уровня подготовки не видать ;)) ) готового поучать
Что ж.. может быть -- поделом
>>На мой взгляд, архитектура ОС предложенная
>>Танненбаумом еще несколько лет назад, является
>>более устойчивой к сбоям и "вредным"
>>изменениям, чем используемые ныне в Виндоус и
>>Линуксе.
Устойчива ТА система, в которой НЕ происходит сбоев, а не та которая умеет их "быстренько и прикольненько" исправлять.
Потому как основной фактор такой нестабильности -- человек.
Исходя из этого можно предположить даже меньшую устойчивость из-за вмешательства человека в работу ядра (настраивать сервер реинкарнаций, кто будет?)
А вот какраз исчерпывающего анализа факторов ненадежности и тем самым аргументированного подтверждения необходимости указанных "фич" -- нету (возможно есть в другой статье)
Есть только псевдоумное "а кто откажеться от большей надежности?"
>>рассуждать по этой теме.
Ну вот и я нарвался на "специалиста" (по посту уровня подготовки не видать ;)) ) готового поучать
Что ж.. может быть -- поделом
>>На мой взгляд, архитектура ОС предложенная
>>Танненбаумом еще несколько лет назад, является
>>более устойчивой к сбоям и "вредным"
>>изменениям, чем используемые ныне в Виндоус и
>>Линуксе.
Устойчива ТА система, в которой НЕ происходит сбоев, а не та которая умеет их "быстренько и прикольненько" исправлять.
Потому как основной фактор такой нестабильности -- человек.
Исходя из этого можно предположить даже меньшую устойчивость из-за вмешательства человека в работу ядра (настраивать сервер реинкарнаций, кто будет?)
А вот какраз исчерпывающего анализа факторов ненадежности и тем самым аргументированного подтверждения необходимости указанных "фич" -- нету (возможно есть в другой статье)
Есть только псевдоумное "а кто откажеться от большей надежности?"
Ну вынесут драйвера из ядра. Всё равно для каких-нибудь специальных нужд понадобяться модули, работающие внутри ядра, хотя они и могут называться отличным от "драйвера" словом. Процесс пойдет по кругу...
Вот-вот...
Захочиться ВГ DRM какой непробиваемый на уровне ядра поцепить :)))
Или супер-пупер Just-in-time-C#-VM :)))))
Захочиться ВГ DRM какой непробиваемый на уровне ядра поцепить :)))
Или супер-пупер Just-in-time-C#-VM :)))))
нужен компромиссный подход
Аку-Аку, вторник, 5 декабря 2006 г. 13:51:54:
Вы пишете:
...
Домашний\офисный комп -- перезагрузки из-за сбойных драйверов неприятны, но отнюдь НЕ критичны
Зато негарантированная работа драйвера после восставновления.. это означает, что когда вы посылаете напечатать стостраничный отчет, где-то в середина драйвер сбиваеться и печать возобновляеться с первого листа :)))) до следующего сбоя... :)) оч нужная фича
...
По поводу перезгрузок очень многие считают сильно иначе. На некоторых офисных компьютерах выполняют дорогостоящие операции и перезагрузки, мягко говоря, весьма не кстати.
А про начало печати с первой страницы вы сами придумали и, как вы правильно заметили, это никому не надо. Уверен, вы можете придумать и что-то стоящее.
Вы пишете:
...
Домашний\офисный комп -- перезагрузки из-за сбойных драйверов неприятны, но отнюдь НЕ критичны
Зато негарантированная работа драйвера после восставновления.. это означает, что когда вы посылаете напечатать стостраничный отчет, где-то в середина драйвер сбиваеться и печать возобновляеться с первого листа :)))) до следующего сбоя... :)) оч нужная фича
...
По поводу перезгрузок очень многие считают сильно иначе. На некоторых офисных компьютерах выполняют дорогостоящие операции и перезагрузки, мягко говоря, весьма не кстати.
А про начало печати с первой страницы вы сами придумали и, как вы правильно заметили, это никому не надо. Уверен, вы можете придумать и что-то стоящее.
>>По поводу перезгрузок очень многие считают
>>сильно иначе.
имеються в виду перегрузки из-за использования некачественных драйверов (для которых Миних и называеться панацеей)
и для которых имееться вполне логичное решение -- использовать качественные драйвера
>> На некоторых офисных компьютерах выполняют
>>дорогостоящие операции и перезагрузки, мягко
>>говоря, весьма не кстати.
А чем в таком случае поможет реинкарнация драйвера
который например обслуживает обращение к диску сервиса базы данных
Вы внимательно читали?
Сервер реинкарнаций НЕ ОБЕСПЕЧИВАЕТ прерваной из-за сбоя сесии работы с драйвером,
так же как и возможные повреждения информации внесенные некорректно работающим драйвером
>>А про начало печати с первой страницы вы сами
>>придумали и, как вы правильно заметили, это
>>никому не надо.
Это какраз пример демонстрирующий выше написаное
>> Уверен, вы можете придумать и что-то стоящее.
Спасибо.. и думаю, да -- смогу
Но вряд ли это будет система восстановления глючно работающих драйверов ;))
>>сильно иначе.
имеються в виду перегрузки из-за использования некачественных драйверов (для которых Миних и называеться панацеей)
и для которых имееться вполне логичное решение -- использовать качественные драйвера
>> На некоторых офисных компьютерах выполняют
>>дорогостоящие операции и перезагрузки, мягко
>>говоря, весьма не кстати.
А чем в таком случае поможет реинкарнация драйвера
который например обслуживает обращение к диску сервиса базы данных
Вы внимательно читали?
Сервер реинкарнаций НЕ ОБЕСПЕЧИВАЕТ прерваной из-за сбоя сесии работы с драйвером,
так же как и возможные повреждения информации внесенные некорректно работающим драйвером
>>А про начало печати с первой страницы вы сами
>>придумали и, как вы правильно заметили, это
>>никому не надо.
Это какраз пример демонстрирующий выше написаное
>> Уверен, вы можете придумать и что-то стоящее.
Спасибо.. и думаю, да -- смогу
Но вряд ли это будет система восстановления глючно работающих драйверов ;))
>> Уверен, вы можете придумать и что-то стоящее.
Например вот такая идея
Современные процесоры поддерживают страничный обмен с виртуальной памятью.
Но тем не менее, скажем образ програмы когда грузиться в память, остаеться там практически весь
Хотя большая часть кода программы выполняеться редко и\или только в начале.
Вот можно было бы заняться проблемами такой оптимизации исполняемого кода, чтобы в памяти можно было оставлять только несколько 4k страниц из мегабайтового объектного файла, и только те что постоянно используеться.
Думаю такая работ и интересна и актуальна,
особенно учитывая тенденцию роста скоростей и количества ядер.
Например можно было бы помещать такие часто используемые страницы полностью в кешпамять (механизмами ОСи)
Например вот такая идея
Современные процесоры поддерживают страничный обмен с виртуальной памятью.
Но тем не менее, скажем образ програмы когда грузиться в память, остаеться там практически весь
Хотя большая часть кода программы выполняеться редко и\или только в начале.
Вот можно было бы заняться проблемами такой оптимизации исполняемого кода, чтобы в памяти можно было оставлять только несколько 4k страниц из мегабайтового объектного файла, и только те что постоянно используеться.
Думаю такая работ и интересна и актуальна,
особенно учитывая тенденцию роста скоростей и количества ядер.
Например можно было бы помещать такие часто используемые страницы полностью в кешпамять (механизмами ОСи)
Ох уж и достали меня эти глючные драйверы.
Реально надо специфицировать аппаратные интерфейсы и аппаратную поддержку и защиту строить аппаратную.
А то каждый производитель своей железки (сетевой карты к примеру) имеет свой интерфейс для ее программирования (разные порты, разные dma ).
Реально надо специфицировать аппаратные интерфейсы и аппаратную поддержку и защиту строить аппаратную.
А то каждый производитель своей железки (сетевой карты к примеру) имеет свой интерфейс для ее программирования (разные порты, разные dma ).
То как заглохла данная тема.. только еще раз подтверждает её малоперспективность.
Статья и концепция микроядерных ОС верная.
Мешает на практике инерция мышления, а главное - инерция "больших систем". Это - корень бед и переходящих из поколения в поколение проблем. Это так особенно в технически сложных областях, таких как построение ОС.
Наблюдаемая не более чем 10% потеря производительности при переключении пользовательских процессов CPU не существенна на фоне резкого повышения надёжности ОС. Особенно в нынешних и будущих быстрых процессорах.
Будущее - за мультисерверной операционной системой, полностью использующей заложенные аппаратно ещё в 1985 году (фактически с Intel386 CPU*) возможности по изоляции пользовательских задач в защищённом режиме процессора, с драйверами устройств, работающими в пользовательском режиме.
* Но в те времена - при существовавших тогда тактовых частотах - вопрос производительности стоял на первом месте...
Реинкарнация драйверов - мечта всех, кому приходится сталкиваться со сбоями этой подсистемы...
Замечу только, авторами или оформителями статьи была допущена небольшая ошибка: в иллюстрациях 6-7 вместо фактически использованных миллисекунд указаны микросекунды (что в 1000 раз меньше)... :)
Мешает на практике инерция мышления, а главное - инерция "больших систем". Это - корень бед и переходящих из поколения в поколение проблем. Это так особенно в технически сложных областях, таких как построение ОС.
Наблюдаемая не более чем 10% потеря производительности при переключении пользовательских процессов CPU не существенна на фоне резкого повышения надёжности ОС. Особенно в нынешних и будущих быстрых процессорах.
Будущее - за мультисерверной операционной системой, полностью использующей заложенные аппаратно ещё в 1985 году (фактически с Intel386 CPU*) возможности по изоляции пользовательских задач в защищённом режиме процессора, с драйверами устройств, работающими в пользовательском режиме.
* Но в те времена - при существовавших тогда тактовых частотах - вопрос производительности стоял на первом месте...
Реинкарнация драйверов - мечта всех, кому приходится сталкиваться со сбоями этой подсистемы...
Замечу только, авторами или оформителями статьи была допущена небольшая ошибка: в иллюстрациях 6-7 вместо фактически использованных миллисекунд указаны микросекунды (что в 1000 раз меньше)... :)
>>Статья и концепция микроядерных ОС верная.
А никто и не оспаривает её методологическую ценность. Эксперименты проводить -- нужно.
>>Мешает на практике инерция мышления, а главное
>>- инерция "больших систем". Это - корень бед и
>>переходящих из поколения в поколение проблем.
Это -- заключение неспециалиста. Явно.
НЕ СУЩЕСТВУЕТ общей методики поэтапной модернизации.. а тем более больших информационных систем.
Система -- каждый раз создаеться "с нуля" (с учетом предыдущего опыта)
>>Наблюдаемая не более чем 10% потеря
>>производительности при переключении
>>пользовательских процессов CPU не существенна
>>на фоне резкого повышения надёжности ОС.
Еще раз.. В ЧЕМ ВЫ УСМАТРИВАЕТЕ "повышение надежности".. дажэе у самого автора, ЭТО -- всего лишь предположение.
Общая же инженерная наука говорит другое -- более простая по устройству система, состоящая из меньшего количества подсистем -- БОЛЕЕ НАДЕЖНА (при прочьих равных)
А уж если в системе появляеться звено (сервер реинкарнаций) зависящее от человеческого фактора, ТО.. вся система преобретает надежность этого, самого слабого, звена. И никакие ухищрения ТУТ не помогут.
>>Будущее - за мультисерверной операционной
>>системой, полностью использующей заложенные
>>аппаратно ещё в 1985 году (фактически с
>>Intel386 CPU*) возможности по изоляции
>>пользовательских задач в защищённом режиме
>>процессора, с драйверами устройств, работающими
>>в пользовательском режиме.
Будущее.. за многоядерными системами.
Подходящую операционку для которых -- еще только НУЖНО разработать.
>>Реинкарнация драйверов - мечта всех, кому
>>приходится сталкиваться со сбоями этой
>>подсистемы...
И плодить недоотлаженный код драйверов :))))
Ведь это програмистская аксиома.
Чем ниже требования к коду, тем ниже его качество.
А никто и не оспаривает её методологическую ценность. Эксперименты проводить -- нужно.
>>Мешает на практике инерция мышления, а главное
>>- инерция "больших систем". Это - корень бед и
>>переходящих из поколения в поколение проблем.
Это -- заключение неспециалиста. Явно.
НЕ СУЩЕСТВУЕТ общей методики поэтапной модернизации.. а тем более больших информационных систем.
Система -- каждый раз создаеться "с нуля" (с учетом предыдущего опыта)
>>Наблюдаемая не более чем 10% потеря
>>производительности при переключении
>>пользовательских процессов CPU не существенна
>>на фоне резкого повышения надёжности ОС.
Еще раз.. В ЧЕМ ВЫ УСМАТРИВАЕТЕ "повышение надежности".. дажэе у самого автора, ЭТО -- всего лишь предположение.
Общая же инженерная наука говорит другое -- более простая по устройству система, состоящая из меньшего количества подсистем -- БОЛЕЕ НАДЕЖНА (при прочьих равных)
А уж если в системе появляеться звено (сервер реинкарнаций) зависящее от человеческого фактора, ТО.. вся система преобретает надежность этого, самого слабого, звена. И никакие ухищрения ТУТ не помогут.
>>Будущее - за мультисерверной операционной
>>системой, полностью использующей заложенные
>>аппаратно ещё в 1985 году (фактически с
>>Intel386 CPU*) возможности по изоляции
>>пользовательских задач в защищённом режиме
>>процессора, с драйверами устройств, работающими
>>в пользовательском режиме.
Будущее.. за многоядерными системами.
Подходящую операционку для которых -- еще только НУЖНО разработать.
>>Реинкарнация драйверов - мечта всех, кому
>>приходится сталкиваться со сбоями этой
>>подсистемы...
И плодить недоотлаженный код драйверов :))))
Ведь это програмистская аксиома.
Чем ниже требования к коду, тем ниже его качество.
Дали блин бабам тему для болтовни!!! Я считаю что подобные разработки очень даже полезны, большинство ламеров Линух тоже за стоящую ОС не считают. А вообщето к большинству заданных сдесь вопросов можно применить выражение "Грамотно сформулированный вопрос не требует ответа!!"
ааа...
Tanenbaum is nothing but architect astronaut with academical background
Tanenbaum is nothing but architect astronaut with academical background
Можно сделать операционную систему, которую можно будет компилировать по усмотрению пользователя как микроядерную или как монолитную
To: Светочка, четверг, 19 июля 2007 г. 23:54:53:
> Можно сделать операционную систему, которую можно будет компилировать по усмотрению пользователя как микроядерную или как монолитную<
Так Линукс таковой и является, есть ведь возможность большую часть ядра компилировать как модули.
> Можно сделать операционную систему, которую можно будет компилировать по усмотрению пользователя как микроядерную или как монолитную<
Так Линукс таковой и является, есть ведь возможность большую часть ядра компилировать как модули.
To В.А.
Linux, к сожалению, не может быть скомпилирован как микроядерная система.
Linux, к сожалению, не может быть скомпилирован как микроядерная система.
To: Светочка, пятница, 20 июля 2007 г. 15:12:23:
>Linux, к сожалению, не может быть скомпилирован как микроядерная система.<
Светочка, а с какого размера ядро считать микро? Надеюсь, вы понимаете, что что-то просто невозможно компилировать как модуль? Например, работа с некоторой файловой системой в ядро должна быть вкомпилирована монолитно. Или вы считаете, что микроядерные - это те системы, у которых есть диспетчер модулей а-ля Миникс?
>Linux, к сожалению, не может быть скомпилирован как микроядерная система.<
Светочка, а с какого размера ядро считать микро? Надеюсь, вы понимаете, что что-то просто невозможно компилировать как модуль? Например, работа с некоторой файловой системой в ядро должна быть вкомпилирована монолитно. Или вы считаете, что микроядерные - это те системы, у которых есть диспетчер модулей а-ля Миникс?
To В.А., вы глубоко ошибаетесь, модульность и микроядерность разые вещи, почитайте хотябы на википедии
основные отличия именно в межмодульном воимодействии
основные отличия именно в межмодульном воимодействии
To: Сайрус, пятница, 20 июля 2007 г. 21:24:42:
>To В.А., вы глубоко ошибаетесь, модульность и микроядерность разые вещи<
Спасибо. Хотя всё-таки это не совсем разные вещи. В микроядре, как я понял, модули выполняются как пользовательские процессы, а в модульном - в пространстве ядра. Размер значения не имеет :-). Просто виденные мною дискуссии акцентировали внимание именно на размерах ядра, а не функциях.
>To В.А., вы глубоко ошибаетесь, модульность и микроядерность разые вещи<
Спасибо. Хотя всё-таки это не совсем разные вещи. В микроядре, как я понял, модули выполняются как пользовательские процессы, а в модульном - в пространстве ядра. Размер значения не имеет :-). Просто виденные мною дискуссии акцентировали внимание именно на размерах ядра, а не функциях.
Вопрос:
А когда Билл Гейтс с Танненбаумом умрут? Тоже в один день?
Танненбаум ваще казёл, он переходит на сторону негрософта, кидая нас , opensourseников!
А когда Билл Гейтс с Танненбаумом умрут? Тоже в один день?
Танненбаум ваще казёл, он переходит на сторону негрософта, кидая нас , opensourseников!
Теме этой минимум 20, а то и 30 лет.
Я практически занимаюсь разработкой драйверов под Линукс более 10 лет.
Мое мнение такое - на сегодня в Линуксе существует 3 способа загрузки драйвера - в соответствии с установками конфигурации ядра - n - то есть не загружать :-), y - то есть выполнить в качестве части монолитного ядра, и, наконец - m - то есть загружать в виде модуля, хотя и не монолитной части ядра, но модуля исполняемого в режиме ядра. А вот варианта - u - то есть пользовательского драйвера на уровне собственно ядра не предусмотрено, хотя для подсистемы USB (и некоторых других) такие варианты имеются.
Отсутствие user land драйверов под Линуксом обусловленно принципиальными установками Линуса/Сталлмана на необходимость поддержания Линукса в целом как ОС с открытыми кодами. Создание "сертифицированной" Линусом системы драйверов работающих в пользовательском режиме эквивалентно созданию бинарного интерфейса, что существенно облегчит поддержку бинарных драйверов устройств для Линукса, что неприемлемо по идеологическо-техническим соображениям.
Микрософт и его сателлиты это опасный противник, и отсутствие драйверов пользовательского уровня в Линуксе это именно средство обороны, которое несколько затрудняет жизнь разработчикам драйверов, но однако, стратегические преимущества превалируют.
А Таненбаум этого не хочет понимать. Ну что же - на то он и НЕ Линус.
Я практически занимаюсь разработкой драйверов под Линукс более 10 лет.
Мое мнение такое - на сегодня в Линуксе существует 3 способа загрузки драйвера - в соответствии с установками конфигурации ядра - n - то есть не загружать :-), y - то есть выполнить в качестве части монолитного ядра, и, наконец - m - то есть загружать в виде модуля, хотя и не монолитной части ядра, но модуля исполняемого в режиме ядра. А вот варианта - u - то есть пользовательского драйвера на уровне собственно ядра не предусмотрено, хотя для подсистемы USB (и некоторых других) такие варианты имеются.
Отсутствие user land драйверов под Линуксом обусловленно принципиальными установками Линуса/Сталлмана на необходимость поддержания Линукса в целом как ОС с открытыми кодами. Создание "сертифицированной" Линусом системы драйверов работающих в пользовательском режиме эквивалентно созданию бинарного интерфейса, что существенно облегчит поддержку бинарных драйверов устройств для Линукса, что неприемлемо по идеологическо-техническим соображениям.
Микрософт и его сателлиты это опасный противник, и отсутствие драйверов пользовательского уровня в Линуксе это именно средство обороны, которое несколько затрудняет жизнь разработчикам драйверов, но однако, стратегические преимущества превалируют.
А Таненбаум этого не хочет понимать. Ну что же - на то он и НЕ Линус.
2 vleo
Тогда как это понимать?
http://osnews.com/story.php/18304/Linux-Kernel-2.6.23-To-Have-Stable-Userspace-Driver-API/
В ядро Linux 2.6.23 включен стабильный Userspace Driver API
Тогда как это понимать?
http://osnews.com/story.php/18304/Linux-Kernel-2.6.23-To-Have-Stable-Userspace-Driver-API/
В ядро Linux 2.6.23 включен стабильный Userspace Driver API
То В.А
>В микроядре, как я понял, модули выполняются как
>пользовательские процессы, а в модульном - в
>пространстве ядра
Опять так и хочется повторить вам что: "модульность и микроядерность разые вещи" и Линух "не может быть скомпилирован как микроядерная система"
>В микроядре, как я понял, модули выполняются как
>пользовательские процессы, а в модульном - в
>пространстве ядра
Опять так и хочется повторить вам что: "модульность и микроядерность разые вещи" и Линух "не может быть скомпилирован как микроядерная система"
>Тогда как это понимать?
>..........
>В ядро Linux 2.6.23 включен стабильный Userspace
>Driver API
А так и понимать, что это фактически всего лишь "мост", позволяющий осуществлять работу с аппаратурой из пользовательского режима, через сервис предоставляемый ядром. Так что это отнюдь не делает архитектуру линуха микроядерной. В винде к примеру тоже есть ряд API функций позволяющий работать в таком же режиме, но это всего лишь навсего транзит.
>..........
>В ядро Linux 2.6.23 включен стабильный Userspace
>Driver API
А так и понимать, что это фактически всего лишь "мост", позволяющий осуществлять работу с аппаратурой из пользовательского режима, через сервис предоставляемый ядром. Так что это отнюдь не делает архитектуру линуха микроядерной. В винде к примеру тоже есть ряд API функций позволяющий работать в таком же режиме, но это всего лишь навсего транзит.
2 406-й
Имел в виду вот это
>...что существенно облегчит поддержку бинарных драйверов устройств...
>...стратегические преимущества...
>...неприемлемо по идеологическо-техническим соображениям...
Имел в виду вот это
>...что существенно облегчит поддержку бинарных драйверов устройств...
>...стратегические преимущества...
>...неприемлемо по идеологическо-техническим соображениям...
to fyjybv
>Имел в виду вот это .....
Понятно.
"Ну что же - на то он и НЕ Линус" :-)))
>Имел в виду вот это .....
Понятно.
"Ну что же - на то он и НЕ Линус" :-)))
2vleo, вторник, 24 июля 2007 г. 20:27:08:
\\А вот варианта - u - то есть пользовательского
\\драйвера на уровне собственно ядра не
\\предусмотрено, хотя для подсистемы USB (и
\\некоторых других) такие варианты имеются.
Что есть драйвер, а что есть надстройка над драйвером?
\\Отсутствие user land драйверов под Линуксом
\\обусловленно принципиальными установками Линуса/
\\Сталлмана на необходимость поддержания Линукса
\\в целом как ОС с открытыми кодами.
Это тут причем. Зачем валить все в кучу.
Ядром занимаеться Линус. (у Столмана свое ядро ;) )
Причем тут идеология к тех. реализации?
\\Создание "сертифицированной" Линусом системы
\\драйверов работающих в пользовательском режиме
\\эквивалентно созданию бинарного интерфейса, что
\\существенно облегчит поддержку бинарных
\\драйверов устройств для Линукса, что
\\неприемлемо по идеологическо-техническим
\\соображениям.
Нет.. просто потому что при работе в пользовательском режиме они будут тормознутее.
А что такое бинарный интерфейс (в данном контексте)???
\\Микрософт и его сателлиты это опасный
\\противник, и отсутствие драйверов
\\пользовательского уровня в Линуксе это именно
\\средство обороны,
???
Где у мелкософта драйвера пользовательского уровня? Чем это защищает?
\\но однако, стратегические преимущества
\\превалируют.
Какие???
\\А Таненбаум этого не хочет понимать. Ну что же
\\- на то он и НЕ Линус.
Не знаю как сам профессор.
Я вот лично заходил на рускоязычный форум пользователей его системы. Хотел пообщаться на тему надежности ОС.
Но убедился, что там находяться всего лишь малограмотные фанаты, которых хлебом не корми, а дай поюзать какую-то новомодную штучку.
А вместо логических доводов, есть только слепо-глухо-немое кивание на авторитетов.
\\А вот варианта - u - то есть пользовательского
\\драйвера на уровне собственно ядра не
\\предусмотрено, хотя для подсистемы USB (и
\\некоторых других) такие варианты имеются.
Что есть драйвер, а что есть надстройка над драйвером?
\\Отсутствие user land драйверов под Линуксом
\\обусловленно принципиальными установками Линуса/
\\Сталлмана на необходимость поддержания Линукса
\\в целом как ОС с открытыми кодами.
Это тут причем. Зачем валить все в кучу.
Ядром занимаеться Линус. (у Столмана свое ядро ;) )
Причем тут идеология к тех. реализации?
\\Создание "сертифицированной" Линусом системы
\\драйверов работающих в пользовательском режиме
\\эквивалентно созданию бинарного интерфейса, что
\\существенно облегчит поддержку бинарных
\\драйверов устройств для Линукса, что
\\неприемлемо по идеологическо-техническим
\\соображениям.
Нет.. просто потому что при работе в пользовательском режиме они будут тормознутее.
А что такое бинарный интерфейс (в данном контексте)???
\\Микрософт и его сателлиты это опасный
\\противник, и отсутствие драйверов
\\пользовательского уровня в Линуксе это именно
\\средство обороны,
???
Где у мелкософта драйвера пользовательского уровня? Чем это защищает?
\\но однако, стратегические преимущества
\\превалируют.
Какие???
\\А Таненбаум этого не хочет понимать. Ну что же
\\- на то он и НЕ Линус.
Не знаю как сам профессор.
Я вот лично заходил на рускоязычный форум пользователей его системы. Хотел пообщаться на тему надежности ОС.
Но убедился, что там находяться всего лишь малограмотные фанаты, которых хлебом не корми, а дай поюзать какую-то новомодную штучку.
А вместо логических доводов, есть только слепо-глухо-немое кивание на авторитетов.
to Аку-Аку
>Где у мелкософта драйвера пользовательского
>уровня?
Винда поддерживает несколько драйверов пользовательского режима:
- драйверы виртуальных устройств;
- драйверы принтеров;
- драйверы файловой системы;
- PnP драйверы
- прочие;
Драйверы режима ядра:
- WDM драйверы (шины, функциональные, фильтров);
- многоуровневые драйверы (классов устройств, порт, минипорт драйверы).
(Из книги Русиновича и Соломона "внутреннее устройство Win 2000 и XP")
>Где у мелкософта драйвера пользовательского
>уровня?
Винда поддерживает несколько драйверов пользовательского режима:
- драйверы виртуальных устройств;
- драйверы принтеров;
- драйверы файловой системы;
- PnP драйверы
- прочие;
Драйверы режима ядра:
- WDM драйверы (шины, функциональные, фильтров);
- многоуровневые драйверы (классов устройств, порт, минипорт драйверы).
(Из книги Русиновича и Соломона "внутреннее устройство Win 2000 и XP")
А по остальным моментам? Более одиозным
Хочеться всетаки понять откуда ветер дует и почему это "облегчение поддержки бинарных
драйверов устройств для Линукса" небезопасно?
\\Винда поддерживает несколько драйверов
\\пользовательского режима:
Нууу.. если так, то в линухе тоже полно таких драйверов.. называються они демонами ;)
Все же.. это больше терминологическая неточность.
Например драйверы принтера -- это не совсем драйвера.. (по структуре)
Демон печати в Линухе использует такой же подход.
Хочеться всетаки понять откуда ветер дует и почему это "облегчение поддержки бинарных
драйверов устройств для Линукса" небезопасно?
\\Винда поддерживает несколько драйверов
\\пользовательского режима:
Нууу.. если так, то в линухе тоже полно таких драйверов.. называються они демонами ;)
Все же.. это больше терминологическая неточность.
Например драйверы принтера -- это не совсем драйвера.. (по структуре)
Демон печати в Линухе использует такой же подход.
to Аку-Аку
>Нууу.. если так, то в линухе тоже полно таких
>драйверов.. называються они демонами
Драйвер - это программа, которая управляет каким-либо "устройством" (физическим или виртуальным - неважно). Демон - фоновый процесс, и не обязательно в принципе он должен чем-то управлять.
Просто многие не понимают, что в архитектурах и Линуха и Винды, всё управление осуществляется через ядро, и неважно, что некоторая часть кода может работать в пользовательском режиме. Так что драйвера пользовательского режима в этих и подобных им архитектурах, это лишь верхушка айсберга. Микроядро же тем и отличается, что вообще не дерижирует устройствами, а только управляет памятью и планирует процессы (или потоки - это зависит от реализации).
>Нууу.. если так, то в линухе тоже полно таких
>драйверов.. называються они демонами
Драйвер - это программа, которая управляет каким-либо "устройством" (физическим или виртуальным - неважно). Демон - фоновый процесс, и не обязательно в принципе он должен чем-то управлять.
Просто многие не понимают, что в архитектурах и Линуха и Винды, всё управление осуществляется через ядро, и неважно, что некоторая часть кода может работать в пользовательском режиме. Так что драйвера пользовательского режима в этих и подобных им архитектурах, это лишь верхушка айсберга. Микроядро же тем и отличается, что вообще не дерижирует устройствами, а только управляет памятью и планирует процессы (или потоки - это зависит от реализации).
То есть являеться драйвером процессора и памяти. ;)
Это все понятно.. про небезопасность где?
PS Может зайдеш на форум minix.ru и там расскажеш... оно им ОЙ как требуеться (чтоб кто-то азы рассказал)
Это все понятно.. про небезопасность где?
PS Может зайдеш на форум minix.ru и там расскажеш... оно им ОЙ как требуеться (чтоб кто-то азы рассказал)
to Аку-Аку
>про небезопасность где?
и в винде и в линухе (короче в любом монолитном ядре) ошибка в драйвере режима ядра может привести к модификации практически любой страницы памяти (коду исполняющемся в нулевом кольце защиты доступно практически всё адресное пространство, и даже виртуальные таблицы дескрипторов виртуальных адресов), за исключением только тех, что имеют атрибут "только чтение". Так что драйвер режима ядра потенциально опасен. Драйверу же пользовательского режима в микроядерных системах доступно только его закрытое виртуальное адресное пространство, поэтому вред от его сбоя на первый взгляд минимален. Вроде бы всё хорошо. Но Винда и Линух потому и монолитны, что производительность микроядра очень низка (потоки то всё равно планируются ядром и межпроцессное взаимодействие тоже дорого обходится ввиду частого переключения их защищённого режима в пользовательский). К тому же сбой в ядре легче диагностируется и его последствий посему легче избежать.
Есть ещё так называемые экзоядерные архитектуры. Суть их в том, что часть кода драйвера загружается в адрессные пространства приложений, нуждающихся в его услугах. Тем самым увеличивается производительность (приложение наиболее непосредственно общается с драйверными библиотеками).
Тем не менее, на сегодняшний день наиболее перспективными решениями являются решения на базе технологий виртуализации (паравиртуализация на основе гипервизора не катит). И здесь кстати мелкософт далеко впереди вовремя сориентировавшись и прикупив конторку которая занималась исследованиями в этой области. Их экспериментальная система singular - передовик этой области.
>про небезопасность где?
и в винде и в линухе (короче в любом монолитном ядре) ошибка в драйвере режима ядра может привести к модификации практически любой страницы памяти (коду исполняющемся в нулевом кольце защиты доступно практически всё адресное пространство, и даже виртуальные таблицы дескрипторов виртуальных адресов), за исключением только тех, что имеют атрибут "только чтение". Так что драйвер режима ядра потенциально опасен. Драйверу же пользовательского режима в микроядерных системах доступно только его закрытое виртуальное адресное пространство, поэтому вред от его сбоя на первый взгляд минимален. Вроде бы всё хорошо. Но Винда и Линух потому и монолитны, что производительность микроядра очень низка (потоки то всё равно планируются ядром и межпроцессное взаимодействие тоже дорого обходится ввиду частого переключения их защищённого режима в пользовательский). К тому же сбой в ядре легче диагностируется и его последствий посему легче избежать.
Есть ещё так называемые экзоядерные архитектуры. Суть их в том, что часть кода драйвера загружается в адрессные пространства приложений, нуждающихся в его услугах. Тем самым увеличивается производительность (приложение наиболее непосредственно общается с драйверными библиотеками).
Тем не менее, на сегодняшний день наиболее перспективными решениями являются решения на базе технологий виртуализации (паравиртуализация на основе гипервизора не катит). И здесь кстати мелкософт далеко впереди вовремя сориентировавшись и прикупив конторку которая занималась исследованиями в этой области. Их экспериментальная система singular - передовик этой области.
406-й, четверг, 26 июля 2007 г. 21:42:49:
Вот это уже серьозный разговор.
Жаль только вовремя ответа не заметил (на форуме такого бы не случилось)
\\>про небезопасность где?
\\и в винде и в линухе (короче в любом монолитном \\ядре) ошибка в драйвере режима ядра может \\привести к модификации практически любой \\страницы памяти (коду исполняющемся в нулевом \\кольце защиты доступно практически всё адресное \\пространство, и даже виртуальные таблицы \\дескрипторов виртуальных адресов), за \\исключением только тех, что имеют атрибут \\"только чтение". Так что драйвер режима ядра \\потенциально опасен.
Да, правда.. но только при условии что он действительно баговый, или специально создан злоумышленником.
И даже если баговый... специфика драйвера такова, что он или правильный, или мертвый.. то есть -- если сбоит, его меняют
Драйвера же пользовательского режима, потенциально позволяют более безалаберное к себе отношение -- "ну и что, что сбоит.. все равно реинкарнирует"
\\Драйверу же пользовательского режима в \\микроядерных системах доступно только его \\закрытое виртуальное адресное пространство, \\поэтому вред от его сбоя на первый взгляд \\минимален. Вроде бы всё хорошо.
Действительно. Есть своя память, которую можна засырать временными структурами.. а то и вообще, уборщик мусора туду поцепить.
Зачем думать об эффективном алгоритме драйвера, он ведь все равно -- "безопасный"? ;)
\\ Но Винда и Линух потому и монолитны, что \\производительность микроядра очень низка \\(потоки то всё равно планируются ядром и \\межпроцессное взаимодействие тоже дорого \\обходится ввиду частого переключения их \\защищённого режима в пользовательский). К тому \\же сбой в ядре легче диагностируется и его \\последствий посему легче избежать.
Чем проще, тем надежнее. Общеинженерный принцып.
\\Есть ещё так называемые экзоядерные \\архитектуры. Суть их в том, что часть кода \\драйвера загружается в адрессные пространства \\приложений, нуждающихся в его услугах. Тем \\самым увеличивается производительность \\(приложение наиболее непосредственно общается с \\драйверными библиотеками).
Это так, как в ДОСе было. :)))
\\Тем не менее, на сегодняшний день наиболее \\перспективными решениями являются решения на \\базе технологий виртуализации \\(паравиртуализация на основе гипервизора не катит).
А вот об этом, поподробнее.
Насколько я знаю, виртуализация не устраняет необходимости иметь ядро и драйвера в нем.. или тут есть что-то новое?
Сбой же виртуальной машины -- это все равно сбой.
Из-за которого например может быть повреждена файловая система и т.п.
Да и гипрвизор -- в нем ведь тоже аналог драйверов нужен.. та же проблема надежности.
\\ И здесь кстати мелкософт далеко впереди \\вовремя сориентировавшись и прикупив конторку \\которая занималась исследованиями в этой \\области. Их экспериментальная система singular \\- передовик этой области.
На сколько я знаю.
Их Сингуларити -- вообще непричем к виртуализации.
Там у них предлагаеться заведомо глупая система, основанная на недопущении програмиста до низкого уровня, вообще. Да еще и с их гребаным дотНЕТом. :)))
По сути, то что они там хотят сделать -- это Визуал Васик для системного програмиста. :))) во, уроды
Вот это уже серьозный разговор.
Жаль только вовремя ответа не заметил (на форуме такого бы не случилось)
\\>про небезопасность где?
\\и в винде и в линухе (короче в любом монолитном \\ядре) ошибка в драйвере режима ядра может \\привести к модификации практически любой \\страницы памяти (коду исполняющемся в нулевом \\кольце защиты доступно практически всё адресное \\пространство, и даже виртуальные таблицы \\дескрипторов виртуальных адресов), за \\исключением только тех, что имеют атрибут \\"только чтение". Так что драйвер режима ядра \\потенциально опасен.
Да, правда.. но только при условии что он действительно баговый, или специально создан злоумышленником.
И даже если баговый... специфика драйвера такова, что он или правильный, или мертвый.. то есть -- если сбоит, его меняют
Драйвера же пользовательского режима, потенциально позволяют более безалаберное к себе отношение -- "ну и что, что сбоит.. все равно реинкарнирует"
\\Драйверу же пользовательского режима в \\микроядерных системах доступно только его \\закрытое виртуальное адресное пространство, \\поэтому вред от его сбоя на первый взгляд \\минимален. Вроде бы всё хорошо.
Действительно. Есть своя память, которую можна засырать временными структурами.. а то и вообще, уборщик мусора туду поцепить.
Зачем думать об эффективном алгоритме драйвера, он ведь все равно -- "безопасный"? ;)
\\ Но Винда и Линух потому и монолитны, что \\производительность микроядра очень низка \\(потоки то всё равно планируются ядром и \\межпроцессное взаимодействие тоже дорого \\обходится ввиду частого переключения их \\защищённого режима в пользовательский). К тому \\же сбой в ядре легче диагностируется и его \\последствий посему легче избежать.
Чем проще, тем надежнее. Общеинженерный принцып.
\\Есть ещё так называемые экзоядерные \\архитектуры. Суть их в том, что часть кода \\драйвера загружается в адрессные пространства \\приложений, нуждающихся в его услугах. Тем \\самым увеличивается производительность \\(приложение наиболее непосредственно общается с \\драйверными библиотеками).
Это так, как в ДОСе было. :)))
\\Тем не менее, на сегодняшний день наиболее \\перспективными решениями являются решения на \\базе технологий виртуализации \\(паравиртуализация на основе гипервизора не катит).
А вот об этом, поподробнее.
Насколько я знаю, виртуализация не устраняет необходимости иметь ядро и драйвера в нем.. или тут есть что-то новое?
Сбой же виртуальной машины -- это все равно сбой.
Из-за которого например может быть повреждена файловая система и т.п.
Да и гипрвизор -- в нем ведь тоже аналог драйверов нужен.. та же проблема надежности.
\\ И здесь кстати мелкософт далеко впереди \\вовремя сориентировавшись и прикупив конторку \\которая занималась исследованиями в этой \\области. Их экспериментальная система singular \\- передовик этой области.
На сколько я знаю.
Их Сингуларити -- вообще непричем к виртуализации.
Там у них предлагаеться заведомо глупая система, основанная на недопущении програмиста до низкого уровня, вообще. Да еще и с их гребаным дотНЕТом. :)))
По сути, то что они там хотят сделать -- это Визуал Васик для системного програмиста. :))) во, уроды
406-й, среда, 25 июля 2007 г. 13:51:17
Если драйверы принтеров в Виндовс находятся в user-space, то почему тогда дрова МФУ Lexmark 4010 вызывыют синий экран смерти, к примеру. Можно еще вспомнить "знаменитые" драйверы Mustek.
singular, это дотнет без низкоуровневых вызовов.
А почему никто не вспоминает fuse. Определенная разумная альтернатива ведь?
Если драйверы принтеров в Виндовс находятся в user-space, то почему тогда дрова МФУ Lexmark 4010 вызывыют синий экран смерти, к примеру. Можно еще вспомнить "знаменитые" драйверы Mustek.
singular, это дотнет без низкоуровневых вызовов.
А почему никто не вспоминает fuse. Определенная разумная альтернатива ведь?
Вам приходилось заглядывать в файлы этих драйверов, видеть что они из себя представляют?
\\singular, это дотнет без низкоуровневых вызовов.
да нет.. если и дотнет, то именно его managed часть, доведенная до абсурда.
там все строиться на том, что любой написанный код будет иметь пасспорт, удостоверяющий что он праильно написан. :))) (заведомая глупость.. поймет каждый кто недавно ставил драйвера и отвечал "пофиг" на вопрос об их цыфровой подписи ;) )
а для того чтобы хоть как-то этого добиться, они решили полностью закрыть доступ к машкодам.
Я просто всцыкаюсь от этой их уверенности, что вся проблема в низкоурвневом коде, и что без его использования система не будет глючить. :)))))) (видно уже самих мелкософтовцев достало их гребанное ядро)
\\singular, это дотнет без низкоуровневых вызовов.
да нет.. если и дотнет, то именно его managed часть, доведенная до абсурда.
там все строиться на том, что любой написанный код будет иметь пасспорт, удостоверяющий что он праильно написан. :))) (заведомая глупость.. поймет каждый кто недавно ставил драйвера и отвечал "пофиг" на вопрос об их цыфровой подписи ;) )
а для того чтобы хоть как-то этого добиться, они решили полностью закрыть доступ к машкодам.
Я просто всцыкаюсь от этой их уверенности, что вся проблема в низкоурвневом коде, и что без его использования система не будет глючить. :)))))) (видно уже самих мелкософтовцев достало их гребанное ядро)
Аку-Аку, среда, 22 августа 2007 г. 13:26:52
>>Вам приходилось заглядывать в файлы этих драйверов, видеть что они из себя представляют?
Честно говоря, нет. Так все ж не пойму, если дрова в юзер-спейс, то какого падает Венда? Или это из серии вирусов в mp3 и wmf в Виндовс? :)
>>Вам приходилось заглядывать в файлы этих драйверов, видеть что они из себя представляют?
Честно говоря, нет. Так все ж не пойму, если дрова в юзер-спейс, то какого падает Венда? Или это из серии вирусов в mp3 и wmf в Виндовс? :)
>Так все ж не пойму, если дрова в юзер-спейс
Они не совсем в юзер-спейс. Могу посмотреть точнее, если интересует.
Они не совсем в юзер-спейс. Могу посмотреть точнее, если интересует.
>Могу посмотреть точнее, если интересует.
Чего я парюсь-то? Вот же написано у 406-й, среда, 25 июля 2007 г. 13:51:17:
Драйверы, которые в режиме ядра, и вызывают синий экран (как и kernel panic в Linux).
Чего я парюсь-то? Вот же написано у 406-й, среда, 25 июля 2007 г. 13:51:17:
Драйверы, которые в режиме ядра, и вызывают синий экран (как и kernel panic в Linux).
аноним, четверг, 23 августа 2007 г. 01:44:32
Тогда это что?
>>406-й, среда, 25 июля 2007 г. 13:51:17
>>Винда поддерживает несколько драйверов пользовательского режима:
- драйверы виртуальных устройств;
- драйверы принтеров...
Тогда это что?
>>406-й, среда, 25 июля 2007 г. 13:51:17
>>Винда поддерживает несколько драйверов пользовательского режима:
- драйверы виртуальных устройств;
- драйверы принтеров...
Aku-Aku 2006-11-16 14:43:12.10002+03
Тема очень давняя
Тот же Таненбаум еще с Торвальдсом на эту тему пререкался ;)
А "соображения" Билла Гейтса совпали,
потому что он книжки того же Таненбаума читал ;)
(или может кто думает что он сам ядро для своих виндов клепал :)) )