Некорректно сравнивать микроядро с монолитным ядром - в микроядре практически ничего нет. Там есть надстройка l4re c основными серверами но я пока что разбираюсь с этим со всем, нужно писать драйверы. Сетевой сервер есть, в качестве стека tcp/ip там используется lwip. Вообще мне показалось что как-то неспешно у них развивается надстройка над микроядром и оно больше используется в качестве гипервизора для linux. Есть такой проект genode - http://genode.org/community/wiki он портирован на многие микроядра, но тоже не блещет функциональностью :) хотя там уже портирован qt4 и нативно работает - собственно этого для многих уже было бы достаточно.
PS кстати в качестве гипервизора для linux можно посмотреть на еще одну открытую (gpl) реализацию L4 api Codezero - http://www.l4dev.org/faq
микроядро написано на С что для меня намного приятней :) процессоры arm там основная архитектура в отличии от других, к тому же контора коммерческая с двойным лицензированием - это хороший стимул для качества и genode еще к тому же может работать поверх codezero.
Первый раз делаал стандалоне приложение для imx233 - elftosb удобнейшая штука оказалась, не надо ниочем беспокоиться - подсунул ему elf образ он сам генерирует образ с правильными адресами в памяти, грузи его потом откуда хочешь - mmc или nand...
Ээх. Если бы интерфейс системных вызовов Fiasco совпадал с Pistachio, я бы перешёл на Fiasco, ведь Вы его уже портировали на at91sam9g45. Увы, переделывать 90 тыс. строк кода рука не поднимается. Хотя системно-зависимого кода у меня не так уж и много.
А вот разработчикам, кто не хочет по каким-то причинам использовать Linux, я бы порекомендовал попробовать Fiasco. Модель, предлагаемая L4, сулит очень хорошие возможности - можно сильно сэкономить системные ресурсы за счёт минимизации переключении контекста и ухода от использования критических секций - в правильно спроектированной программе они просто не нужны. Достаточно просто представить систему как множество сервисов, которые обмениваются сообщениями и на основе этого проектировать систему любой сложности.
А Linux... его запускают поверх микроядра не от хорошей жизни, а потому что нет нативных сервисов и драйверов. А народу нравится - Linux -- круто, микроядро -- круто, получается вдвойне круто. :)
Это говорит о том что система плохо спроектирована - тот же genode работает на любом L4 подобном микроядре.
Скорость приложений на паравиртуальизованом linux отличается от нативного не больше 4 %, на arn-ах скорей всего разница еще меньше, так что нет особого смысла изобретать велосипеды. В genode например даже при том что они используют драйверы linux через прослойку DDE (на разработку драйверов они практически не тратят время) до сих пор нет полной posix совместимой среды - это огромный объем работы вы наверняка знаете об этом. linux и без гипервизора достаточно стабилен - а насколько стабильно работает ваш код 90 тыс строк который кроме вас никто не видел и не запускал ? я думаю вам даже до нативного linux оочень далеко.
Нет! Моя система спроектирована хорошо! Факт, что genode работает на любом L4 подобном микроядре, говорит о том, что разработчики использовали IDL для описания интерфейсов. В моём случае системные вызовы оптимизированы вручную. Если уж и буду использовать когда-либо IDL, то наверняка это будет похоже на COM технологию, но никак не то, что предлагается сейчас вместе с L4.
Это не имеет значения - в любом случае наблюдается падение производительности. Я утверждаю, что на многопроцессорных системах мой подход даст прирост производительности по сравнению даже с невиртуализированным Linux. Пока классическая система будет раскручивать спинлоки, Xameleon сделает много полезных вещей.
К примеру, при переносе на L4 драйвер Floppy диска (заимствован из FreeDOS) очень упростился - выкорчевана работа с прерываниями и перенесена в основной цикл обработки сообщений. В результате драйвер стал в полтора раза проще, понятнее и... стабильнее.
Единственная проблема, касающаяся микроядерного подхода - это системный вызов select (и вообще использование сокетов как файловые дескрипторы). Поскольку сервис файловой системы и сервис TCP/IP находятся в разных модулях, то возникает проблема, когда select ждёт дескрипторы сокетов (сетевая подсистема) и дескрипторы устройств (файловая система). Вот, пожалуй, единственная проблема микроядерного дизайна. Обратная сторона проблемы - возможность модульной компоновки системы - можно использовать модули в любом сочетании.
Впрочем, select нужен только для совместимости с POSIX, без него можно во многих случаях обойтись, используя многопоточность.
Это несерьёзно сравнивать. Сколько человеко-лет затрачено на разработку Linux? А как насчёт вливаний кода в Linux компаниями IBM, Novell и десятком других. Мне хотя бы десятитысячную долю от того, что затрачено на Linux, тогда можно и сравнить.
По моему это огромный минус - переносимость кода должна иметь приоритет над эффективностью.
Странное заявление - многопоточные приложения никто не мешает писать и под Linux. Для справки - начиная с версии 2.6.37 ядро linux можно собрать полностью без BKL, а RT патч для ядра например полностью заменяет все спинлоки rt-мьютексами а все обработчики прерываний исполняются в отдельных потоках.
Вот когда вы доберетесь хотя бы до работы с USB (я уже не говорю про различные аудио/видео мультимедиа ускорители и кодеры/декодеры и графические ускорители) тогда и будет смысл о чем то говорить. Дискету я последний раз видел пару лет назад случайно у жены.
Несереьезно противопостовлять вашу ОС Linux - ни по скорости ни по функционалу, откуда будут у вас "вливания" если система закрытая ?
14.02.2011 19:27
17.02.2011 11:48
