Чтобы быть рутом - нужно знать пароль. А чтобы стать сервисом (драйвером) этого не нужно или Вы предлагаете чтобы пользователь вводил какой-то пароль каждый раз когда регаеться сервис? Знаю в форточки тоже этого пароля нету - но для прикладного программиста думаю легче сфорганить прогу под микроядро, чем драйвер под форточку, так как нужно чтобы бсод не было! имхо
AntiB В принципе, да. Но ты лучше почитай небезызвестный спор Торвальдса и Таненбаума. Монолит vs микроядро. Linux vs Minix. SII RSX-11M -- это проявление программерского максимализма. Понятно ведь, что драйвер фс в ядре, будет обеспечивать бОльшую производительность. Так зачем его оттуда выкидывать? Чтобы было просто приделывать другие фс? Ну так для этого, в лине, например, создана специальная файловая система fuse, которая позволяет без проблем создавать драйвер фс в user-space. Из таких драйверов я регулярно использую sshfs, драйвер которой, по сути, лишь адаптер к пакету openssh. Критичные для работы системы фс, типа ext2/3, nfs, продолжают жить в ядре. И ведь, если представить linux систему, в ядре которой нету ни одного драйвера фс, то это ж что получается? Ни тебе udev, ни proc, ни sysfs... Если ядро, каждый раз, когда я буду заглядывать в /proc, чтобы получить список процессов, будет перенаправлять мои запросы от VFS к user-space драйверу, а тот будет используя какие-то специальные интерфейсы ядра узнавать требуемую мне информацию, то это будет уже не linux, а реализация linux поверх windows. И тормозить оно будет... То же самое, с выкидыванием стека tcp/ip из ядра. Зачем? Чтобы ядро стало поменьше, и не так пугало бы своими мегабайтами сорцов неофитов? Или чтобы оно помедленнее работало? Данунафиг. Единственной причиной может быть безопасность: ошибка в ядерном стеке tcp/ip может стать ходом в ring0 для зловредного кода с удалённой тачки. В случае же, когда стек tcp/ip -- это процесс, или процессы работающие в ring3, такого рода дыра приведёт лишь к тому, что зловредный код влезет в некий процесс в ring3, который имея необходимые привилегии для работы с сетевой картой, не имеет больше никаких прав в системе вообще.
нет, SII, в принципе понял, что я имел в виду да, где-то так все системные сервисы работают с правами рута сервисы пользовательского уровня как замена драйверам будут так же работать с правами рута в чем проблема?
r90 Отчасти это было вынужденное решение: виртуальной-то адрес всего 16 разрядов на PDP-11 Там же никакой сегментной организации памяти нет. Но на самом деле вынос драйвера файловой системы ядра практически не приводит к падению производительности по той простой причине, что время переключения контекста многократно меньше времени, необходимого на саму операцию ввода-вывода. На память помню две весьма показательные характеристики: дисковые накопители DEC RK06 (советский аналог СМ-5408) неформатированной ёмкостью 14 Мб имели время позиционирования головок с самого внешнего цилиндра на самый внутренний или обратно порядка 0,8 с (секунды!), а скорость обмена данными между накопителем (точней, контроллером) и памятью машины составляла не более 64 Кб/с. Ну а переключение контекста... Конечно, в абсолютных цифрах оно было куда больше, чем на нынешних процах, но ведь самые скорострельные PDPшки не достигали и 5 млн. оп/с, а цифра в 300-400 тыс. оп/с была очень распространённой -- а ведь сейчас пиковое быстродействие процессоров на ПК достигает (в теории) нескольких миллиардов операций в секунду. Но в процентном отношении переключение контекста тогда выполнялось намного быстрее: никаких тебе падений кэшей (за отсутствием такового на большинстве машин), никаких теневых сегментных регистров (другой механизм виртуальной памяти)... В общем, контекст переключался в сотни, а то и тысячи раз быстрее, чем работали диски и тем более другие устройства, а поэтому вынос поддержки файловых систем "наружу" на производительности не сказывался. А вот вынос из ядра модулей, реализующих чисто программные системные вызовы (например, выделить память, запустить задачу и т.п.) очень прилично "посадит" производительность по сравнению с хорошей монолитной реализацией. Зависит больше от кривизны проекта и реализации, чем от монолитности/микроядерности как таковой.
пропускная способность сети в любом случае будет нивелировать снижение производительности, которая возникнет при реализации сетевой подсистемы вне ядра кроме того, я еще раз повторю, стек протоколов - это чистый прикладной уровень, который вообще никак не связан с системными механизмами, которые тем не менее он вынужден использовать, находясь в ядре + единожды реализовав сетевую подсистему в виде сервиса пользовательского уровня (POSIX-совместимым образом), его можно использовать во всех POSIX-совместимых ОС это тоже немаловажно
одной из задач микроядра как раз является управление памятью и процессами (зависимым от архитектуры образом) обобщенные системные сервисы типа clone()/mmap() в Linux должны быть реализованы в микроядре и использоваться подсистемами управления процессами/памятью, которые могут быть без проблем вынесены на пользовательский уровень опять таки, вся логика строится вокруг крайне малого количество экспортируемых микроядром интерфейсов
rei3er как говорит один знакомый: "А кто нам обещал лёгкой жизни??") эмуль, как минимум, позволит пресечь попытку записать что-нить по занятому адресу. конечно, с точки зрения ресурсоёмкости подход далёк от идеала, но для первичного тестового режима нового драйвера попрёт.
Определимся с терминами: -- Микроядерная система (на примере QNX): именно система, а не микроядро в отдельности представляет собой набор модулей где каждая функция выделена - ядро только одна из них и связаны они специальным протоколом - в микроядерной системе ядерный протокол основная часть. Предназначена в основном для обеспечения максимальной гибкости и необслуживаемости (см Barbos) применяется во всяких пром компах средней и высокой мощности. Внутренее устройство достаточно сложное и хитрое, так скажем в QNX ядро поддерживает простейшую фс и при падении важнейших драйверов может их перегрузить из бут файла. Ядро в QNX представляет собой в основном просто диспетчер соединений реализующий ядерный протокол. Тк его размер ~32Kb оно полностью грузится в кэш и не выгружается больше. Скорость проца минимум в 10 раз быстрее скорости памяти, так что переключения происходят довольно быстро. На практике QNX консоль тормозит всего раза в полтора по сравнению с линухом. На www.qnx.com можно скачать пробную версию и гнутый софт к ней. На qnx.com.ru отличные статьи и форум по qnx и другим микроядерным (Barbos настоятельно рекомендую сперва сходить туда, а не изобретать велосипед, лучше чем есть изобретете вряд-ли, а головной боли поимеете), кроме того система отлично документирована (дока в поставке). Для коммерческого использования эта ось очень дорогая. кроме нее есть свободные QNX подобные системы - ChorusOS к примеру. Насчет защищенности QNX. Драйвер (менеджер ресурсов) написать действительно легче и запустить не из под рута можно. да только вы не сможете выгрузить или подменить драйвер на который не имеете прав. и железо на которое нет прав у драйвера не доступно. Пишите драйвер, калечите свое железо и все. -- Монолитная система: Монолитные системы применяются в интегрированых на кристалл компах, конроллерах, где периферию заменить невозможно в принципе (AVR, PIC,..). В них основной упор делается на плотность кода и быстродействие (или точные задержки). Тк даже у близких кристаллов есть свои тонкости, перенос системы обычно больше похож на написание новой по образцу старой. Кстати говоря насчет простоты и быстроты разработки монолитов, скажите почему НОКИЯ так редко обновляет аппаратную часть (раз в 3-4 года)? Относительно надежности - смарты той-же НОКИИ (по форумам одни из самых надежных) время от времени зачем-то перегружаются... -- Все остальные. сюда входят и монолиты с подгружаемыми модулями и микро со встроеными в ядро загрузчиками, менеджерами памяти, портов, итд являются имхо композитами. Это первые системы и наиболее распространенные. Их конструируют исходя из требований проекта. Это был обзор только по дробности. Есть и другие критерии.
AntiB Лучше так: микроядро - хуже производительность, но выше реактивность на внешние события. Монолит - наоборот. Еще, говоря про микроядерные оси, все почему-от забыли про масштабируемость, т.е. возможность иметь вполне рабочую одну и ту же ось как размером несколько сотен мегабайт, так и несколько десятков килобайт. На монолитах это в принципе невозможно. _basmp_ Если есть регистрация (MyQNX account), то рабочую полнофункциональную версию QNX 6.X Neutrino (точнее, вариант инсталляции под названием Momentics), бесплатную для некоммерческого использования. Если нет - то 60-дневную.
drmad почему невозможно - вполне, просто используем возможность модульности и всё - монолит тоже можно розбить на модули. В етом думаю монолит не уступает микроядру, но в микроядрах хорошо что эсть устоичивость против ошибок в драйверах и ядре
SII Не проверял, но уверен, что приводит. В ядре есть дисковый кэш, занимающий, как правило всю свободную оперативку. У меня это, как правило, около половины гигабайта. Если файл лежит там, то жёсткий диск даже не шевельнётся при обращении к этому файлу. Я когда в лине в первый раз смонтировал дискету, и скопировал туда около метра, был немало удивлён тем, что копирование произошло практически мгновенно и дискета не шуршала. Когда же я дискету попытался отмонтировать, мне всё стало ясно. Мне сложно оценить относительную частоту попадания по дисковому кешу, скажем, в windows, но если речь идёт о *nix -- то она существенна. Все настройки лежат в файлах. А уж если речь идёт о специальных задачах, типа пересборки системы... ууу... Глазом видно влияние количества свободной оперативки на скорость компиляции. rei3er На десктопе да.
AntiB Приснопоминаемая RSX-11M содержала десятка три, если не больше, модулей ядра, не считая драйверов -- и всё это компоновалось в один файл во время генерации системы. Ну, плюс драйверы могли загружаться отдельно, уже после загрузки самой оси (если такая возможность включалась в ядро при генерации). Так что с модульностью в монолитах никаких проблем нет.
r90 Для того, чтобы это проверить, надо свою ось написать -- чтобы точно знать, что как делается. Причём написать в двух вариантах. Перекроить же существующие, мягко говоря, проблематично. Ничто не мешает реализовать дисковый кэш и во внешней по отношению к ядру программе -- это уж от криворукости разработчиков зависит. Естесно, ось должна иметь нормальные механизмы управления памятью. Хотя в общем-то дисковый кэш -- палка о двух концах, как и виртуальная память. В частности, может полностью убить производительность, если срабатывает неудачно для конкретной ситуации. Вы, пожалуй, даже не представляете, как влиял объём оперативки на скорость генерации, например, OS/360 -- и это при том, что никаких дисковых кэшей там и в помине не было. Просто если ассемблеру и компоновщику давали мало памяти, он начинал гонять туда-сюда диски, а то и того хуже -- магнитные ленты (в зависимости от того, какое устройство предоставлялось ему для хранения временных файлов). Ну а если памяти хватало, всё в ней лежало. В общем, затрачиваемое время могло различаться в десятки раз...
SII Ну всё не настолько сложно. Можно ведь взять, скажем, libe2fs, и написать для линя fuse-драйвер. А потом сравнить производительность линя на родном драйвере и линя на fuse. Нельзя утверждать, что цифры будут совсем точные, но они дадут возможность разговаривать более аргументированно. Другое дело, что у меня нет никакого желания этим заниматься, даже с таким упрощением. Мой опыт программирования под линух, и администрирования линухов подсказывает, что если что-то, из тех вещей на которые полагаются sys_read и sys_write будет жить не в ring 0 (например драйвер fs), то дисковая подсистема линуха будет иметь производительность не выше чем у windows. И мне этого достаточно. Я был бы весьма рад, если бы кто-то экспериментально подтвердил или опроверг моё мнение, но сам я этим заниматься не планирую. По-крайней мере в ближайшие полгода. Угу. Я читал какую-то субмурную статейку про проблемы дисковой подсистемы vista, в которой кэш был главным стрелочником. Но в лине я не замечал подобного. Может просто у меня ситуаций таких не случалось? Почему же не представляю? Меня немного смущает термин "генерация", я не понимаю о чём речь идёт. Но наверное это просто какой-то тип задачи для OS/360 (которая для меня, к сожалению, не более чем герой древних легенд), приведённый для примера, точно так же как я привёл пересборку системы. И если я прав, то я понимаю. Я пару раз доводил систему имеющую 64Mb оперативки и 512Mb свопа, до забивания на 90% и того, и другого. С магнитными лентами я дела не имел, но мне кажется, я в состоянии прикинуть что бы было, если бы вместо IDE-шного диска, носителем свопа была бы магнитная лента. =) Собственно после тех экспериментов, если я вижу что моя система использует своп, то я удваиваю системе количество оперативки. Ибо своп -- это извращение, никакой raid не спасёт от падения производительности. Ради возможности дальнейших удвоений даже перелез на x86_64 (а так не хотелось переустанавливать систему, которую я >3 лет под себя допиливал =) ), ибо чувствую что в ближайшем будущем 32-битная адресация не справится.
Вроде-бы я намекал на это. Кроме того такое возможно и на композитах, хоть и не в таких масштабах - возьмите те-же линух с вынью. Однако, встраиваемые системы, а не просто микроядерные, проточены лод это дело и предоставляют удобные инструменты для создания масштабированых установок. Насколько я помню через 60 дней отключаются только некоторые инструменты, в первую очередь утиль создающая установки, или вы просто теряете лицензию... На qnx.org.ru на форуме в свое время предлагалось несколько способов обхода этой бяки. Кроме того, в инет опен ос магазинах до сих пор можно найти версии в которых этого не было (6.21nc). В 6.20, что-ли, были все инструменты и никаких ограничений, кроме лицензионных и ошибок. На базаре еще можно отыскать 4.хх пиратские. монолит разобраный на модули - уже не монолит по определению (моно - один). Хотя может вам просто это слово нравится. А какие вы перекроить пытались уже? Есть ведь и небольшие (по исходникам) системы. Проточеные на перекройку. Не линукс и не вынь.
Насколька я знаю, монолит означает что драйвера и ядро запущено в одном адресном пространстве и поетому монолит, а не то что всё идет одним файлом, може я и ошибаюсь
Ну, теоретически ситуацию могу подсказать. Упомянутые мной в предыдущем посте, а также в этом ниже ассемблер и компоновщик OS/360 при нехватке доступной им оперативной памяти создают временные файлы, куда и скидывают свои таблицы. Понятное дело, что авторы сих умных программ, точно зная, как эти самые программы работают, могут скинуть именно наиболее ненужные в данный момент данные, а самые важные оставить в оперативке. Если же вместо такого подхода полагаться на виртуальную память (OS/360 могла иметь такую, а могла и не иметь), то, понятное дело, менеджер памяти при нехватке физической памяти будет выкидывать на диск страницы по своему усмотрению, что может оказаться неэффективным: он же не знает, какие данные кому потребуются в ближайшее время, и максимум, что ему известно -- как давно к этим страницам было последнее обращение. Кстати, упомянутый ассемблер на машине с одинаковым объёмом ОЗУ точно работал быстрее без виртуальной памяти. Похоже, именно что-то подобное при этом и происходило, но копаться не пробовал. Примерно то же самое, что сборка ядра Линух из исходников. Правда, OS/360 в основном шла в виде объектных модулей, а в исходниках была лишь небольшая часть, но общий смысл от этого не меняется. А вот RSX-11M шла полностью в исходниках, из которых и выполнялась генерация. Ну, на лентах был, конечно, не файл подкачки, используемый для реализации виртуальной памяти (таковой мог быть только на диске), а лишь временный файл самого транслятора, но скорость в любом случае понятно какая была Даже банальная скорость чтения в несколько раз меньше (у ленты с плотностью записи 32 бит/мм -- 64 Кб/с, а с большей плотностью в СССР встречались редко и работали крайне хреново -- если это, конечно, были не оригинальные IBMовские агрегаты; ну а у дисков -- 156, 312, 800 и более Кб/с в зависимости от типа накопителя), а если ещё добавить позиционирование, то вообще... Правда, ЕСовские ленты могли читаться при движении как вперёд, так и назад, но всё равно медленно. Особенно по сравнению с тем, к чему мы привыкли сегодня )) _basmp_ Вообще-то "моно" в термине "монолитная ОС" относится не к числу модулей, а к числу адресных пространств, используемых собственно осью. В монолитной оси всё работает в едином адресном пространстве, в микроядерном -- каждая "большая фича" в своём собственном. Только одну и очень давно -- RSX-11. Путём реализации поддержки файловой системы в виде драйвера ядра, а не в виде внешней по отношению к ядру задачи. Всё работало, но прироста скорости обнаружить не удалось (по крайней мере, в пределах точности измерений). Диски медленные уж очень были
Каждый пользуется своей классификацией и обычно в начале дискуссии подобной данному топику желательно проводить согласование терминов. Если-же ось допускает подгрузку модулей в адресное пространство ядра и интерфейс ее описан, то да - защищённость ее == 0 и повалить ее может даже не ошибка, а просто неаккуратность или не очень хорошее понимание принципов работы ядра, про вирусы, шрионы и программный вандализм я вообще молчу - все возможности. Тк топик по оценке разных систем. Мое мнение - развивать такие системы, кроме как неизменяемо прописаных в камне не стоит ни в коем случае. в микроядерном - любая законченая функция - отдельный процесс и в нем отдельно все. Правда межпроцессное взаимодействие очень оптимизировано, так-что это не очень мешает. И, скажем, когда разрабатываем/тестируем драйвер система не падает каждые пять минут. С тех пор многое изменилось. Взгляните например на BlueBottle от Вирта. Если не понравится обратите внимание на Plan9 от создателей unix. Есть и другие. Кроме того микроядерную вы при желании можете изменить до неузнаваемости, просто переписав соответствующие модули и не трогая ядро, которое то сути просто быстрый переключатель процессов.
Вот тут http://qnx.org.ru/viewthread4n5264.html пишут, что исходники QNX, в том числе и ядра открыты. Обьясняют где и как взять. Рекомендую юзать.
_basmp_ Извините, это полная чушь. То, что ядро допускает подгрузку собственных модулей, ещё не значит, что это позволительно всем и каждому. Да, если задаться целью, администратор сможет повалить систему. Но администратор сможет повалить любую систему -- на то он и администратор (неубиваемой в этом смысле может быть только система, начисто лишённая возможности её администрировать на низком уровне). Ну а рядовой пользователь никак не сможет навредить системе или другим пользователям. Если, конечно, система нормально спроектирована и реализована.
