Комментарии 5
Подготовка дистрибуции может занять около часа или двух
Там все очень сильно зависит от конкретной конфигурации сборки. Если вы воткнете в сборку Chromium, то на сборку может уйти и часов 6-8.
Отдельно следует напомнить, что Yocto Project собирает образ операционной системы, а если для этой ОС нужно написать приложение на нативных языках (С/С++) — то нужно отдельно еще и собирать SDK (bitbake <image_name> -c populate_sdk), что по времени чуть меньше, но сопоставимо с самим временем сборки образа ОС.
можем переносить дистрибуцию на встраиваемые системы
Это ровно до тех пор, пока встраиваемая система не несет за собой собственного ядра и набора костылей (в них вся суть Yocto Project) для поддержки мобильного оборудования.
Потом окажется, что наборы "слоев" оказываются разные и они могут банально конфликтовать
Это ровно до тех пор, пока встраиваемая система не несет за собой собственного ядра и набора костылей (в них вся суть Yocto Project) для поддержки мобильного оборудования.
Потом окажется, что наборы «слоев» оказываются разные и они могут банально конфликтовать
Да это так. Скорей всего зависит от приготовленного BSP и количества и качества используемых пакетов. В реальных условиях при такой конфигурации как в даном примере были небольшие проблемы. Встраиваемая система на базе SAMA5D3 Xplained. Были проблемы с netsnmp и opennhrp. А вот с ядром проблем не было, но надо было отдельно делать установки ядра.
Для настройки yocto вы редактируете файлы из директории poky. Сами йоктовцы не рекомендуют такой способ, так сложнее распространять исходники своих сборкок. Вместо этого рекомендуется создавать свою директорию meta-<somename> (слой в терминах йокто) и подключать ее в /conf/bblayers.conf. Там же, в своем слое, удобно задавать рецепты образов, которые будут включать все необходимые группы пакетов и пакеты. Там же можно модифицировать рецепты из других слоев посредством .bbappend рецептов. Получается, что даже внутри небольшой команды, гораздо проще синхронизировать сборки, если вынести все изменения в отдельный слой и создать скрипт по начальному созданию директории conf.
А вы пробовали Mininet? Честно говоря, не знаю, насколько он завязан на OpenFlow, но он разрабатывался для похожих целей: упростить отладку и тестирование SDN-коммутаторов. Их подход отличается от вашего всего двумя вещами:
- вместо виртуализации каждого виртуального хоста посредством отдельной ВМ используется network namespaces в ядре. Если вы пишете протоколы в юзерспейсе, а не в ядре, то это самый удобный вариант
- у них есть очень элегантная консоль, которая позволяет сразу при вводе комманды сообщать, какой хост будет выполнять команду:
mininet> h2 python -m SimpleHTTPServer 80 >& /tmp/http.log & mininet> h3 wget -O - h2
Правда у меня так и не получилось запустить mininet на чем-то кроме убунты
Для настройки yocto вы редактируете файлы из директории poky. Сами йоктовцы не рекомендуют такой способ, так сложнее распространять исходники своих сборкок. Вместо этого рекомендуется создавать свою директорию meta-somename (слой в терминах йокто) и подключать ее в /conf/bblayers.conf. Там же, в своем слое, удобно задавать рецепты образов, которые будут включать все необходимые группы пакетов и пакеты. Там же можно модифицировать рецепты из других слоев посредством .bbappend рецептов. Получается, что даже внутри небольшой команды, гораздо проще синхронизировать сборки, если вынести все изменения в отдельный слой и создать скрипт по начальному созданию директории conf
Да, согласно с искусством так надо делать. Просто хотел показать место где необходимо поправить. Для самого yocto пригодилась бы статья в стиле «best practice».
А вы пробовали Mininet? Честно говоря, не знаю, насколько он завязан на OpenFlow, но он разрабатывался для похожих целей: упростить отладку и тестирование SDN-коммутаторов.
Спасибо. Посмотрю.
Я аж Боярского вспомнил, «Инстанция, Инстанция Инстааааанция»
А за статью спасибо, тема очень интересная.
Виртуальная сетевая среда для тестирования сетевых протоколов. Используем QEMU+YOCTO+TAP