[Каков лучший способ сделать условную компиляцию в зависимости от цели qemu или kos-image ?]

Добрый день!

16 часов назад, Ivan Ponomarev сказал:

Но что касается Qemu или HW - это можно решить с помощью ifdef. В больших проектах зачастую так и делается.

Не могли бы вы привести конкретный пример?

[Линковка сущности с bsp_CLIENT_LIB и/или gpio_CLIENT_LIB приводит к неработоспособности RDP с другими сущностями.]

Попробую сформулировать еще раз.
1. Есть проект который до поры до времени разрабатывался в qemu. Сделаны сущности, прописаны edl/cdl/idl файлы, прописаны правила в security.psl  Работа с GPIO сделана в виде функции заглушки, вместо работы с драйвером выводится сообщение в консоль.
И на этом этапе проблем ни с названием соединения ни с порядком старта (а он никак не регламентируется в KoS CE насколько я понимаю), ни с разрешениями - нет.

2. Сущность на которую возлагается функция работы с GPIO линкуется с библиотеками gpio_CLIENT_LIB
и bsp_CLIENT_LIB. Изменяется только CMakeLists.txt. За образец взят пример examples/gpio_output

И исходящее соединение RPC до другой сущности падает при нициализации на вызове ServiceLocatorConnect

Еще раз. С-код не меняется. Только линковка.

Логи успешного и неуспешного запуска прикладываю.
А нет, не прикладываю, оказывается приложить можно только картинки. Ну ок, вот ЯД https://disk.yandex.ru/d/Vjsguzh7q2cRSQ

 

[Каков лучший способ сделать условную компиляцию в зависимости от цели qemu или kos-image ?]

Здесь я обращаюсь к разработчикам за советом. Совет о том, где лучше/удобнее/правильнее указать требуемые опции компилятора.

Да, я правда считаю что RTFM в любой дискуссии это не совет, не ответ, и вообще не конструктивный способ ведения диалога. Какова бы ни была разница в компетенциях между участниками.

[Каков лучший способ сделать условную компиляцию в зависимости от цели qemu или kos-image ?]

Цитата

Никто не мешает исправить cross-build.sh под себя или использовать команды cmake напрямую

Спасибо кэп!
Идею можно развить, никто не мешает сделать свою ось, и вообще сейчас это модно делать на Rust, а красивый конфигуратор нарисовать на Qt!

Увы, этот диалог никак не поможет новичкам в трудной ситуации. Мысль вроде "Хотите изучать Kaspersky OS CE? - изучите сначала CMake" не тянет на поддержку.

[Запрос функционала. Бинарные образы загрузчика в составе KoS CE]

В 15.03.2024 в 19:37, Ivan Ponomarev сказал:

Касательно поставки u-boot - это совершенно сторонний продукт, включение в поставку не предполагается.

Cпасибо.

Добрый день.

Очевидные вещи говорите. Но вопрос был об удобстве использования. В конце концов "выстреливают" проекты, которые позволяют максимально эффективно реализовывать идеи, и при этом не путаться в паутине накладных расходов. В конце концов для соблюдения всех копилефтов можно оставить истинный путь с загрузкой и сборкой репозитория, а для тех кому некогда бодаться с побочкой стоит предложить готовое решение.

[Линковка сущности с bsp_CLIENT_LIB и/или gpio_CLIENT_LIB приводит к неработоспособности RDP с другими сущностями.]

Здравствуйте.
На курсе по разработке рассматривали учебный пример "светофор". Решил довести его до логичного завершения на Rpi и со светодиодами.
В качестве образца взял examples/GPIO_OUTPUT

Странная ситуация. Просто попробовал слинковать свой управлятор лампочками с либами bsp и gpio, добавив в CmakeLists.txt:

target_link_libraries (Client ${gpio_CLIENT_LIB})

     if ("${CMAKE_SYSTEM_PROCESSOR}" MATCHES "arm|aarch64")

target_link_libraries (Client ${bsp_CLIENT_LIB})

endif ()

Даже если не пытаться работать с gpio такие действия приводят к тому что вызов

ServiceLocatorConnect

возвращает INVALID_HANDLE

Состояние можно посмотреть тут

https://github.com/lost-byte/cyberimmune-systems-example-traffic-light-kos/tree/communication-mosquitto

Коммит 3689

 

 

 

 

[Каков лучший способ сделать условную компиляцию в зависимости от цели qemu или kos-image ?]

Добрый день.

Ну например в quemu нет драйвера GPIO. А в описании примера https://support.kaspersky.ru/help/KCE/1.1/ru-RU/gpio_output_example.htm  просто сказано что при сборке и запуске возникает ошибка. Ну для демо-кода это норм. А вот если разработка более сложного проекта то хотелось бы иметь некий способ запуска и эмулятора и аппаратного образа. Первое что приходит на ум - условная компиляция. Однако нужен некий флаг компилятора, ну например -DQEMU.

Может быть уже вводится такой флаг? Или может быть есть более изящный способ?

[Запрос функционала. Бинарные образы загрузчика в составе KoS CE]

Добрый день!

Для подготовки образа SD карты в составе KasperskyOS-Community-Edition-1.1.1.40 предлагается набор скриптов rpi4_prepare_fs_image_rev1.[x].sh

Однако при ряде обстоятельств работа скрипта может завершиться неудачей.

В процессе работы скрипты:

1. Пробуют установить инструменты сборки - хорошо бы просто проверять их наличие в системе, если нет то отправлять разработчика в справку с требованиями.

2. Скачивают образ Debian для Rpi  - довольно большой объем, жесткие ссылки, что если пути образов изменятся?

3. Делают клон репозитория u-boot в папке tmp -  а что если tmp смонтирован с ограничением размера?

4. Делают сборку u-boot - довольно длительная процедура, при этом результат не сохраняется.

5. Монтируют образ Debian для Rpi на loop

6. Переразмечают раздел корна на 1Gb

7. Редактируют в образе файлы конфигурации в образе

Немного критики. Хоть процедура подготовки образа и не является частой операцией, всё же на определённых этапах повторять приходится. При этом повторяется и весь этот овер-ворк с загрузкой неслабых объемов по сети и довольно долгой сборкой загрузчика. Вообще было бы хорошо чтобы промежуточный результат, ну например архивы образов и репозиторий u-boot сохранялись в некоем кэше.

А вообще в идеале, просьбы по процедуре подготовки образа следующие:

1. Предложить свой набор бинарников u-boot (можно наверное еще существенно порезать по функционалу)

2. Сделать опцию или конфиг где можно указать размер root раздела. Примеры в составе дистрибутива кажется не дают бинарников жирнее 40Мб. И получается можно использовать бросовые карточки минимальных размеров.

Вообще кажется что при таком подходе можно отказаться от необходимости выяснять ревизию конкретной RPi 4B, кажется что разница только в файлах device-tree причем с точки зрения поддержки периферии в КоС несущественная (конечно это вопрос тщательной проверки).

 

[Есть ли планы по отказу от u-boot?]

Здравствуйте!

Кажется что использование u-boot несколько противоречат, ну например принципам Зальцера-Шрёдера.

Сам по себе u-boot это уже мини-операционка, с дровами, доступом к хранилищу, скриптовой машиной и конечно CLI. Я бы сказал что в современном виде u-boot перекрывает возможности исторической MS-DOS.
Да, это здорово как инструмент разработки и отладки. Как способ обеспечения большей открытости, снижения психологической приемлемости среди энтузиастов. Но в то же время с т.з. безопасности и надёжности это кажется огромной дырой.

Даже при построении embedded систем на базе Linux есть практика либо максимального сокращения возможностей u-boot, либо отказа от него вообще там где это приемлемо достижимо.

В конце концов задача загрузчика, условно, включить нужную периферию, запустить расширенную память и перенести образ ОС с носителя в точку старта.
Будет ли в дальнейшем развитии Kaspersky OS CE пример такого минималистичного загрузчика?