FatalException

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

Попробую сформулировать еще раз. 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

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

Спасибо кэп! Идею можно развить, никто не мешает сделать свою ось, и вообще сейчас это модно делать на Rust, а красивый конфигуратор нарисовать на Qt! Увы, этот диалог никак не поможет новичкам в трудной ситуации. Мысль вроде "Хотите изучать Kaspersky OS CE? - изучите сначала CMake" не тянет на поддержку.

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

Здравствуйте. На курсе по разработке рассматривали учебный пример "светофор". Решил довести его до логичного завершения на 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

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

Добрый день! Для подготовки образа 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 это уже мини-операционка, с дровами, доступом к хранилищу, скриптовой машиной и конечно CLI. Я бы сказал что в современном виде u-boot перекрывает возможности исторической MS-DOS. Да, это здорово как инструмент разработки и отладки. Как способ обеспечения большей открытости, снижения психологической приемлемости среди энтузиастов. Но в то же время с т.з. безопасности и надёжности это кажется огромной дырой. Даже при построении embedded систем на базе Linux есть практика либо максимального сокращения возможностей u-boot, либо отказа от него вообще там где это приемлемо достижимо. В конце концов задача загрузчика, условно, включить нужную периферию, запустить расширенную память и перенести образ ОС с носителя в точку старта. Будет ли в дальнейшем развитии Kaspersky OS CE пример такого минималистичного загрузчика?