проснитесь, модули ядра уже там (в ядре). То что они в одном контексте (в контексте ядра) рояли не играет.
Вот в Амиге Exec был "ядром", которое исполнялось в userspace, не в режиме супервизора. А при необходимости дергать драйвер (который был простой разделяемой библиотекой) он вручную переключался в SupervisorMode и обратно (или не переключался, если не было необходимости). И "ядро" эффективно исполнялось в user mode.
>вопрос: помогали ли вам студенты в развитии minix
>ответ: первую версию я писал сам, в дальнейшем много кода написано студентами, я также получал финансирование от студентов на написание кода
Это как? Задавал студентам курсовые а потом их сам делал за деньги???
> вокруг ни одного из этих микроядер нет полноценной обвязки системных процессов и реализованного уровня posix.
QNX сертифицированный posix. L4 запускает гипервизором L4/Linux, да и поверх библиотекой можно реализовать (тот же Altell seOS на базе L4 -- POSIX). Ту же подсистему POSIX совместимости запросто можно реализовать библиотекой, как в экзоядрах или в амижном Cygnix.
> (кроме посикс, ибо это смотря для каких целей делать, хотя безусловно посикс рулит),
не везде. С многопоточностью и семафорами у позикса имеются некоторые проколы. "Смотря для каких целей делать"
Потом, зачем и когда Столлман придумал POSIX? Когда юниксы превратились в зоопарк каждый со своим смутно схожим API.
Сейчас API более-менее стандартизировали, необходимости такой сильной как в 1985 в позиксе нет.
говно тоже можно посикс сертифицировать, если научить выполнять все его системные вызовы, тока реализация эта будет не полноценой по причине вони, намёк понят?!
> микроядро без обвязки - кусок теории и не больше
"Голому собраться -- только подпоясаться"
Что ты понимаешь под "обвязкой" микроядра? Что из этого не может быть реализовано библиотекой, отдельными средствами с готовым инструментарием, тулчейном?
Ты что сказать-то хотел? Что ты носишься так с этим позиксом?
Что тебе из всего подмножества позиксовых вызовов реально нужно, а что просто -- балласт? И почему реализацию всего этого нужно пихать непременно в ядро?
>Что ты понимаешь под "обвязкой" микроядра? Что из этого не может быть реализовано библиотекой, отдельными средствами с готовым инструментарием, тулчейном?
всё что может потребоваться для его использования, демоны, драйверы, посикс слой или мало ли что может понадобиться задачи бывают разные. Реализуй ка мне микроядро (не гибрид) с драйверами в библиотеках, я посмотрю как это у тебя заработает.
>QNX сертифицированный posix.
Это не полноценное микроядро. Самое близкое к микроядру из практически применяемых, но всё же не полноценное. Там в ядро встроен таймер и менеджер памяти.
>L4 запускает гипервизором L4/Linux,
Тоже мимо. Зачем городить микроядро, если поверх него будет работать один большой процесс? Микроядро имеет смысл, когда все функции макроядра поделены между отдельными процессами, взаимодействующими через микроядро.
Соображения про библиотеки тоже не принимаются. Библиотека POSIX - не система. Это её "лицо" для userlevel приложений. Сущность системы скрывается за интерфейсом. POSIX - это актуальный минимум, который нужно реализовать в микроядерной системе; но сам по себе принципиальной ценности не имеет (прошу понять эту фразу правильно), т.к. этот интерфейс уже отлажен и работоспособен на множестве других, не микроядерных систем.
> Посикс нужен, что в свою очереть не значит что его совершенствовать не требуется!
вот-вот. Его давно пора отрефакторить, по крайней мере набор расширений для задач придумать, как с Xorg или c OpenGL.
При этом нужно просто расширение "ускорения 3D графики" для того же xorg. Как оно будет называться и как оно будет реализовано, EXA/XAA/UXA по сути не важно.
Главное policy, не механизм.
Native kernel API-то менялся от версии к версии. То что его пользовали не напрямую, а через более-менее стабильный ABI ^W трамплин ntdll.dll роли особо не меняет.
> Вот в Амиге Exec был "ядром", которое исполнялось в userspace, не в режиме супервизора. А при необходимости дергать драйвер (который был простой разделяемой библиотекой) он вручную переключался в SupervisorMode и обратно
>всё что может потребоваться для его использования
эдак батенька вы до Столлмана докатитесь, который не различал, ядро, емакс и почту, "это всё одна сплошная операционная система". Столлману можно, он оболочку дешевую ^W^W емакс написал, а тебе-то такая каша в голове -- зачем?
> Реализуй ка мне микроядро (не гибрид) с драйверами в библиотеках, я посмотрю как это у тебя заработает.
быстро заработает. См. про экзоядра. Там как раз libOS.
там и своппинга с нормальной виртуальной памятью тоже нет, отдельным менеджером/диспетчером.
>Микроядро имеет смысл, когда все функции макроядра поделены между отдельными процессами, взаимодействующими через микроядро.
и какой смысл в этом контексте имеет POSIX? где он тут сидит, точнее зачем между отдельными процессами с нативным микроядрёным API чужеродный API позикс?
кроме стандартизации зоопарков и декларации поддержки фич я других применений ему не вижу. Зоопарки сейчас немного другие, а фичи можно поддерживать и уровнем выше.
>Библиотека POSIX - не система. Это её "лицо" для userlevel приложений
подсистема, ага. И лиц для приложений может быть несколько, для разных приложений -- разные. Опять таки не пойму, зачем это реализовать не отдельным модулем, снаружи, а именно в ядре.
> стандар посикс очень удобен для конечного пользователя(не юзера а програмера например)
покажите мне такого программера! Некоторые моменты в POSIX прямо таки очень *неудобны*.
Но стандарт, на то он и стандарт, чтобы вообще быть. А не быть самым идеальным для всех задач. Хоть такой стандарт лучше чем вообще никакого.
>где я это сказал?!
ну ты кагбе намекаешь, что микроядро обязательно должно реализовывать все системные вызовы позикс-стандарта. А модульность-то для кого придумали?
Какая разница что там внутри в Native API, если наружу предоставлен понятный стандартный интерфейс (да хоть тот же позикс) ? Какая разница как именно и где именно он реализован?
MMU был. В процессоре. В OS -- не использовался.
Процессоры, на которых работала AmigaOS были и с MMU и без.
Сейчас на http://www.natami.net/concept.htm делаются попытки реализовать свои чипы в качестве FPGA, и основной FPGA-процессор -- как вариант "улучшенного 68060", N68070. http://www.natami.net/knowledge.php?b=3¬e=969http://www.natami.net/knowledge.php?b=4¬e=642
На форуме обсуждается производительность такой "системы в целом". Быстрый блиттер, вычисления на видеокартах ^W^W блиттером, копирование между узлами Cell ^W^W DMA-устройствами с "полной скоростью".
Интересна оценка производительности в тактах, старого/нового, относительная. Шина не становится узким местом потому что быстрый блиттер фактически делает быстрое DMA к SRAM-кешу в 16 Мб http://www.natami.net/knowledge.php?b=2¬e=1775. Получаются почти "clockless асинхронные вычисления" ( Хотя так и решили не делать, для начала не заморачиваться и сделать на FPGA нормальный синхронный процессор )
И "общая мудрость" (или как там, conventional wisdom?) сходится к тому, что MMU не нужен. По крайней мере для этой задачи, "воссоздания архитектуры старой Амиги с custom chip'ами через FPGA и повсеместным использованием DMA".
И что без MMU будет быстрее, потому что даже если он не используется, происходит лишняя косвенная адресация (которую прячут в длинном конвейере, но оверхед всё-таки есть, а можно и без него).
>Вот поэтому микроядерная архитектура там и работала эффективно.
там был системный эффект в целом, архитектура ОС/железа/периферии.
Но если ещё на таком железе уже было заметно этот системный эффект, почему бы не воссоздать его на более лучшем железе, специально сделать железо, чтобы усилить этот эффект?
Или хотя бы устранить узкое место в виде общей шины и лишних контекстных переключений?
Вон, некоторые вообще говорят, машина фон Неймана -- фуфло, антимашины рулят. Или клеточные автоматы. Или реконфигурируемые вычисления. Как программировать их толком не очень понятно, но FPGA+CPU в железе и микроядра в софте, ИМХО, направление мысли задают правильное.
> на реально сложном оборудовании проявится не эфективность.
"на реально сложном С++ коде проявится неэффективность"
неэффективность чего, кода? или выбранного в качестве инструмента С++ ?
не надо путать сложное и усложнённо-запутанное, complicated и sophisticated.
>>Там в ядро встроен таймер и менеджер памяти.
>там и своппинга с нормальной виртуальной памятью тоже нет, отдельным менеджером/диспетчером.
Для микроядра идея выноса диспетчеров/менеджеров из ядра как раз и является основополагающей. Микроядро должно только обеспечивать взаимодействие между этими процессами. А вот встроенный таймер и менеджер памяти - как раз не вписываются в эту концепцию.
>и какой смысл в этом контексте имеет POSIX?
Смысл этого в том, чтобы не иметь сферического коня в вакууме - систему, для которой нет программ.
>Опять таки не пойму, зачем это реализовать не отдельным модулем, снаружи, а именно в ядре.
Очнитесь, где я это сказал?
Реализовывать POSIX нужно именно отдельным модулем. А реализовывать нужно обязательно, чтобы не получился сферический конь.
Я лишь продекларировал, что настоящие микроядра есть, их много, но для этих микроядер нет остальных необходимых подсистем в виде отдельных модулей, включая POSIX, которые бы сделали из идеи микроядра систему, пригодную для промышленного применения.
согласен, микроядро в QNX не совсем "чистое". Однако, микро, и позикс есть.
>А реализовывать нужно обязательно, чтобы не получился сферический конь.
тоже согласен. Те же Haiku/Syllable/AROS какие бы замечательные в своей уникальности компактные, эффективные API потенциально не родили бы, (почти) никому без позикса были бы не нужны. Поэтому он там есть.
> но для этих микроядер нет остальных необходимых подсистем в виде отдельных модулей, включая POSIX, которые бы сделали из идеи микроядра систему, пригодную для промышленного применения.
тут не согласен. Для промышленного применения в тех же RTOS POSIX-то и не нужен. И так везде есть свои механизмы.
Для десктопов нужен позикс. Хотя тоже не очень удобен.
Он нужен для стандартизации велосипедов и декларации сопоставимого "минимально поддерживаемого функционала". А так и стимпанковский самокат с квадратными колёсами (или из треугольников Рело) -- тоже может работать. Как правило, и работает.
>>пригодную для промышленного применения.
>тут не согласен. Для промышленного применения в тех же RTOS POSIX-то и не нужен. И так везде есть свои механизмы.
Ну, моё понимание "промышленного применения" не ограничивается управлением промышленными механизмами и объектами вроде атомных реакторов в реальном времени. В моём понимании сюда входит возможность, например, запустить Oracle.
>>Он нужен для стандартизации велосипедов и декларации сопоставимого "минимально поддерживаемого функционала".
Он нужен в первую очередь именно для того, чтобы показать, что система не специализированная и пригодна для самых разных применений.
> чтобы показать, что система не специализированная и пригодна для самых разных применений.
ага, согласен. Но границы применимости и назначение всё-таки разные. И разные подходы интересны хотя бы тем, что эти границы чётче очерчивают.
Если бы был "универсальный самокат", то до первого велосипеда с педальным приводом и не додумались.
Итак есть "самобеглая повозка для самых разных применений". А некоторым и паланкина хватит.
Че то глуповато у Таненбаума реально стало в последнее время
получаться.
Идеал для меня тлевизор, (почему телвизор, зачем телевизор,
кого это когда нибудь расстраивало из пользователей включить/выключить
компьютер раз в год, скажем итд.), но мы вот сейчас работаем над USB ситемой.
> вопрос: считаете ли вы недостаткам запуск драйвера отдельным процессом в userspace
> ответ: это небольшая потеря производительности, но мы и не ориентируемся на производительность, накладные расходы получаются порядка 5-10% , мелочи какие :)
Т.е. любой проприетарный гандон может напейсать закрытый пошифрованный драйвер уровня пользователя и требовать использования только его? Этот миникс должен быть уничтожем вместе со всеми микропсевдоядерными поделками, ей-ей.