должен поинтересоваться, насколько легко в ней снести или игнорировать подобные драйвера
Не до конца понимаю о чем у Вас, коллеги, спор, но сдается мне, что он уже далек от основного содержания статьи. Наша ОС не предназначена для работы на микроконтроллерах, а уровнями выше герои, страждущие выкинуть системный драйверный код и сделать всё под себя, исчезают как класс.
Постановка вопроса не верна. Если контроллеру, например, Ethernet, требуется управлять физикой через GPIO, то, как ни крути, драйверу этого Ethernet придется дергать пины. От этого вся сетевая подсистема не начинает жестко зависеть от подсистемы работы с GPIO, лишь конкретный драйвер и совершенно безальтернативно (т.е. буквально: нет доступа к GPIO - нет сети).
Колхозить что-то прямо в сетевом драйвере или поюзать штатный драйвер GPIO с задокументированным интерфейсом (aka подсистему) - это решение исключительно разработчика конкретного сетевого драйвера. Жить такой драйвер, вероятно, будет в одном определенном BSP и с этим всё.
Сопоставимо с переходом от прямой работы с памятью к передаче сообщений. Но, поскольку, о необходимости прокачки больших объемов данных тут речь не идет, то эти накладные расходы в расчет не берутся.
В противном случае рекомендации по кастомизации под конечное устройство соответствуют тому, что сказано выше. Но у нас самих таких задач не просматривается вне участия в каких-то совместных работах на конкретных конфигурациях.
А в чем собственно проблема? Если штатный драйвер не оптимально решает некоторую задачу, всегда можно взять его исходник и включить в код своего проекта с той или иной модификацией, благо обычно такие драйвера у нас идут в сорцах в составе BSP. Микроядерность ОС этому всячески способствует.
Мы же решали задачу наведения порядка и предоставления универсального дизайна типовых драйверов данного класса, который можно и нужно развивать по фидбэкам реальных потребителей. То, что оно не обязано быть оптимальным в каждом частном случае - это действительно так. Т.к. конечных систем мы не производим, то вопрос кастомизации время от времени встает и перед нами и перед потребителями.
Поле перекомпиляции с высоким шансом будет работать даже стандартизованный код под cygwin, Linux и BSD. Все-таки стандартные UNIX / POSIX вещи никто не ломал, а их развитие происходит путем дополнения и багфикса.
Если же речь о чем-то более специфичном для QNX, то тут шанс уже далек от 100%. Чтобы ответить на этот вопрос нужно проанализировать что это за код и свериться с changelog-ом на ОС. Эти интерфейсы, при наличии оснований, бывают исключены, переработаны и расширены. И тут речь как о ядерных и libc-шных интерфейсах, так и более прикладных. Чем более поздняя версия нашей ОС используется, тем меньше этот шанс.
Стандартная реализация может использовать для блокировки мьютекс или семафор, и их захват всегда приводит к вызову функции из ядра ОС
Выделенное не является верным. Очень странно видеть столь общие и категоричные утверждения. Во многих UNIX-ах эти детские болезни давно пролечены. Как минимум, в первую очередь производится попытка захвата через атомик cmp&swap (CAS):
Боюсь, что среди авторов блога представлен в основном инженерный состав компании. Вопрос Ваш коллегам, занимающимся поставками, мы конечно передадим, но не припомню, чтобы эти вопросы регулярно обсуждались публично. Насколько я могу судить, имеется как некоторый прайс-лист, так и кучерявая система скидок и предложений по поддержке отечественных производителей и образовательных учреждений. Увы, не компетентен в этих вопросах.
DRM позволяет рендерить прямо в память. Тот же user-space OpenGL на это полагается. Иксы работают как враппер оконного окружения для этих целей и высокодинамичный контент также будут копировать "в хвост и в гриву". Всевозможные on-memory видео-захват, overlay-контент и offscreen-рендеринг оконными примитивами иксов никак не покрываются.
Так что не оконным окружением единым, как говорится. В нем нет волшебных фич для решения этих задач. @Cfyz абсолютно прав: одно дело передавать оконные примитивы, другое - контент внутри окон.
Видимо, проблему апдейта устройства вы решаете перефлэшиванием образа целиком
Почти. Учитывая, что на борту у команды тестирования в единицу времени сразу несколько стабильных релизов разных годов выпуска и пачка актуальных nightly билдов, для контроля регрессий приходится начисто накатывать конкретный дистрибутив на весь тестовый парк. Основное отличие в том, что за счет микроядерности у нас загрузочный образ очень маленький (сетевой стек, sshd, файловая система и пара файловых утилит [fdisk, mkdir, cp, etc]) и грузится на всём парке по сети. Всё остальное просто заливается в переразмеченную с нуля корневую FS в виде тарболов. В соседней статье ребята небольшую вводную на этот счет делали.
Кроме пары почтенных девайсов, вроде старенького Ateml, апгрейд проходит не более 20 мин. в худшем случае. В среднем около 7 мин.
Позже один из инженеров ...
С трудом могу представить безболезненную реализацию кейса, когда, например, какой-то проект, вроде zlib, через свой генерируемый config.h внезапно декларирует/отключает какие-то фичи, а зависимый переконфигурируется динамически на основе детектирования именно этой фичи. И далее по цепочке.
Учитывая, что многие проекты живут на разных рельсах -- нативная система сборки, ванильный autotools, cmake, meson, qmake, pkg-config ... -- простым такой анализ не будет. И априорно без пересборки словить такие build-time отличия, имхо, сочинить интерпретатор для всех этих тулов.
А если и так и так пересобирать, то профит не совсем ясен. Коллизия всплывёт либо на этапе компиляции/линковки, либо уже на этапе стат. анализа/тестирования/фаззирования и прочего динамического анализа.
Вопрос определения иерархий изменённых явно или косвенно компонентов мы решаем иначе. Поскольку вся иерархия обходится всегда в одном порядке (от пред-зависимостей к пост-зависимостям), обнаружение в таргет-ветке коммита, отличного от предыдущего билда, есть основание для отметки всего нижележащего поддерева как требующего пересборки.
Важно помечать именно все поддерево пост-зависимостей, т.к. произвольный компонент без коммитов не обязательно является неизменным. Он мог ранее компилироваться с другими сторонними хэдерами или внешними дефайнами. Т.к. фиксы вносим по мере появления необходимости во все компоненты, то и полагаться на гипотетическое отсутствие сайд эффектов крайне вредно для качества продукта.
Про апгрейд тулчейна Вы уже упоминали, но конкретно этот процесс у нас полностью детерминирован и случается планово.
Вопрос не совсем архитектурный в данном случае. Архитектурные проблемы в интерфейсе библиотеки мы устранили, как и было рассказано. И проявление проблемы как бы ушло, но не сама проблема.
Десятки секунд на банальное порождение ничего, по сути, не делающих процессов - это перебор. В том же Shell такой код будет работать существенно быстрее. Плагин sh, который используется в Jenkins откровенно долго работает сам по себе - вот этот момент мы не курили, обойдя его рефакторингом своего кода.
Про QNX не знаем, мы уже много лет с ним не работаем. И даже официальную поддержку не оказываем.
OpenCV - да, мы его тоже к себе в ОС спортировали. Как standalone решение, так и в интересах данной платформы, а также TensorFlow Lite, MLPack и ряд других проектов. Сами библиотеки, вроде CV, закрывают около 5-10% функциональных потребностей платформы и не решают даже обсуждаемую частную задачу во всём её объеме.
Судя по сайту вы готовы работать только с университетами
Да нет, у нас основные внедрения промышленные. Даже по публичным перепискам на том же форуме можно в этом убедиться. Академическая программа - это вопрос где-то последнего полугодия.
Просто даже если и появляются проекты в которых она кажется уместной, объяснить руководству что стоило бы посмотреть в эту сторону очень сложно.
А у вас нет в планах показать свою операционку миру.
Попрошу коллег прокомментировать Ваши вопросы. Тут больше политики и позиционирования, а я все-таки про технику))
Ну там выпустить ознакомительный вариант для какого нибудь из одноплатников
Касательно одноплатников. Не столь популярный у наших потребителей формат. Работали когда-то давно с BeagleBone Black. Фоном по просьбе одного из институтов инициативно делаем BSP для OrangePi PC. Когда последний будет готов, вероятно, выкатим его в свой публичный GIT-репозиторий как пример. Но это вопрос несколько отдалённый.
Добрый день! Ваше наблюдение относительно исторической связи с QNX верно. Если кратко, то обсуждаемая ОС - это полноценный форк с 18+ летней историей. Чуть подробнее коллеги отвечали вот в этой теме.
Немного приоткрывающую завесу статью мы уже подготовили, но она лишь третья в очерёдности на публикацию (считая эту). Через пару недель появится в блоге. На примере одной из подсистем будет рассказываться как становилась разработка: от изучения и воспроизведения и до самостоятельного определения векторов развития.
Всё предельно просто. Всё, где нет MMU для нас - микроконтроллер. У кого есть MMU - микропроцессор.
На at91sam9260 запускались вот приблизительно в этих годах (юбилей, однако выходит =)):
С MMU у него всё отлично. Конкретно про SAM7 уже не вспомню как дела обстоят (полагаю, что не хуже SAM9) и кто/зачем его в этот список засунул.
Не до конца понимаю о чем у Вас, коллеги, спор, но сдается мне, что он уже далек от основного содержания статьи. Наша ОС не предназначена для работы на микроконтроллерах, а уровнями выше герои, страждущие выкинуть системный драйверный код и сделать всё под себя, исчезают как класс.
Постановка вопроса не верна. Если контроллеру, например, Ethernet, требуется управлять физикой через GPIO, то, как ни крути, драйверу этого Ethernet придется дергать пины. От этого вся сетевая подсистема не начинает жестко зависеть от подсистемы работы с GPIO, лишь конкретный драйвер и совершенно безальтернативно (т.е. буквально: нет доступа к GPIO - нет сети).
Колхозить что-то прямо в сетевом драйвере или поюзать штатный драйвер GPIO с задокументированным интерфейсом (aka подсистему) - это решение исключительно разработчика конкретного сетевого драйвера. Жить такой драйвер, вероятно, будет в одном определенном BSP и с этим всё.
Сопоставимо с переходом от прямой работы с памятью к передаче сообщений. Но, поскольку, о необходимости прокачки больших объемов данных тут речь не идет, то эти накладные расходы в расчет не берутся.
В противном случае рекомендации по кастомизации под конечное устройство соответствуют тому, что сказано выше. Но у нас самих таких задач не просматривается вне участия в каких-то совместных работах на конкретных конфигурациях.
А в чем собственно проблема? Если штатный драйвер не оптимально решает некоторую задачу, всегда можно взять его исходник и включить в код своего проекта с той или иной модификацией, благо обычно такие драйвера у нас идут в сорцах в составе BSP. Микроядерность ОС этому всячески способствует.
Мы же решали задачу наведения порядка и предоставления универсального дизайна типовых драйверов данного класса, который можно и нужно развивать по фидбэкам реальных потребителей. То, что оно не обязано быть оптимальным в каждом частном случае - это действительно так. Т.к. конечных систем мы не производим, то вопрос кастомизации время от времени встает и перед нами и перед потребителями.
Поле перекомпиляции с высоким шансом будет работать даже стандартизованный код под cygwin, Linux и BSD. Все-таки стандартные UNIX / POSIX вещи никто не ломал, а их развитие происходит путем дополнения и багфикса.
Если же речь о чем-то более специфичном для QNX, то тут шанс уже далек от 100%. Чтобы ответить на этот вопрос нужно проанализировать что это за код и свериться с changelog-ом на ОС. Эти интерфейсы, при наличии оснований, бывают исключены, переработаны и расширены. И тут речь как о ядерных и libc-шных интерфейсах, так и более прикладных. Чем более поздняя версия нашей ОС используется, тем меньше этот шанс.
Выделенное не является верным. Очень странно видеть столь общие и категоричные утверждения. Во многих UNIX-ах эти детские болезни давно пролечены. Как минимум, в первую очередь производится попытка захвата через атомик cmp&swap (CAS):
Пример из glibc: https://github.com/lattera/glibc/blob/master/nptl/pthread_mutex_lock.c#L201
Да и само название базового примитива futex (Fast Userspace muTEX) тоже намекает на обратную картину. Есть примеры и из других ОС.
Боюсь, что среди авторов блога представлен в основном инженерный состав компании. Вопрос Ваш коллегам, занимающимся поставками, мы конечно передадим, но не припомню, чтобы эти вопросы регулярно обсуждались публично. Насколько я могу судить, имеется как некоторый прайс-лист, так и кучерявая система скидок и предложений по поддержке отечественных производителей и образовательных учреждений. Увы, не компетентен в этих вопросах.
Так в самом первом же предложении, под картинкой. Да и в тегах.
DRM позволяет рендерить прямо в память. Тот же user-space OpenGL на это полагается. Иксы работают как враппер оконного окружения для этих целей и высокодинамичный контент также будут копировать "в хвост и в гриву". Всевозможные on-memory видео-захват, overlay-контент и offscreen-рендеринг оконными примитивами иксов никак не покрываются.
Так что не оконным окружением единым, как говорится. В нем нет волшебных фич для решения этих задач. @Cfyz абсолютно прав: одно дело передавать оконные примитивы, другое - контент внутри окон.
Почти. Учитывая, что на борту у команды тестирования в единицу времени сразу несколько стабильных релизов разных годов выпуска и пачка актуальных nightly билдов, для контроля регрессий приходится начисто накатывать конкретный дистрибутив на весь тестовый парк. Основное отличие в том, что за счет микроядерности у нас загрузочный образ очень маленький (сетевой стек, sshd, файловая система и пара файловых утилит [fdisk, mkdir, cp, etc]) и грузится на всём парке по сети. Всё остальное просто заливается в переразмеченную с нуля корневую FS в виде тарболов. В соседней статье ребята небольшую вводную на этот счет делали.
Кроме пары почтенных девайсов, вроде старенького Ateml, апгрейд проходит не более 20 мин. в худшем случае. В среднем около 7 мин.
С трудом могу представить безболезненную реализацию кейса, когда, например, какой-то проект, вроде zlib, через свой генерируемый config.h внезапно декларирует/отключает какие-то фичи, а зависимый переконфигурируется динамически на основе детектирования именно этой фичи. И далее по цепочке.
Учитывая, что многие проекты живут на разных рельсах -- нативная система сборки, ванильный autotools, cmake, meson, qmake, pkg-config ... -- простым такой анализ не будет. И априорно без пересборки словить такие build-time отличия, имхо, сочинить интерпретатор для всех этих тулов.
А если и так и так пересобирать, то профит не совсем ясен. Коллизия всплывёт либо на этапе компиляции/линковки, либо уже на этапе стат. анализа/тестирования/фаззирования и прочего динамического анализа.
Вопрос определения иерархий изменённых явно или косвенно компонентов мы решаем иначе. Поскольку вся иерархия обходится всегда в одном порядке (от пред-зависимостей к пост-зависимостям), обнаружение в таргет-ветке коммита, отличного от предыдущего билда, есть основание для отметки всего нижележащего поддерева как требующего пересборки.
Важно помечать именно все поддерево пост-зависимостей, т.к. произвольный компонент без коммитов не обязательно является неизменным. Он мог ранее компилироваться с другими сторонними хэдерами или внешними дефайнами. Т.к. фиксы вносим по мере появления необходимости во все компоненты, то и полагаться на гипотетическое отсутствие сайд эффектов крайне вредно для качества продукта.
Про апгрейд тулчейна Вы уже упоминали, но конкретно этот процесс у нас полностью детерминирован и случается планово.
На том тестовом наборе, на котором всё это исследовалось, логи были не сильно большие. Но за наводку спасибо, может и тут есть что ускорить
Не наш вариант, поскольку и libc тоже обновляется. А от этого компонента зависят все остальные => полный ребилд.
Вопрос не совсем архитектурный в данном случае. Архитектурные проблемы в интерфейсе библиотеки мы устранили, как и было рассказано. И проявление проблемы как бы ушло, но не сама проблема.
Десятки секунд на банальное порождение ничего, по сути, не делающих процессов - это перебор. В том же Shell такой код будет работать существенно быстрее. Плагин
sh, который используется в Jenkins откровенно долго работает сам по себе - вот этот момент мы не курили, обойдя его рефакторингом своего кода.Про QNX не знаем, мы уже много лет с ним не работаем. И даже официальную поддержку не оказываем.
OpenCV - да, мы его тоже к себе в ОС спортировали. Как standalone решение, так и в интересах данной платформы, а также TensorFlow Lite, MLPack и ряд других проектов. Сами библиотеки, вроде CV, закрывают около 5-10% функциональных потребностей платформы и не решают даже обсуждаемую частную задачу во всём её объеме.
Это лишь пример кода, поясняющий о чем идет речь. Он не используется в таком виде во внедренных механизмах. Но Ваше замечание по своей сути верно.
Не обязательно (картинка в заключении статьи) =)
Да нет, у нас основные внедрения промышленные. Даже по публичным перепискам на том же форуме можно в этом убедиться. Академическая программа - это вопрос где-то последнего полугодия.
Попрошу коллег прокомментировать Ваши вопросы. Тут больше политики и позиционирования, а я все-таки про технику))
Касательно одноплатников. Не столь популярный у наших потребителей формат. Работали когда-то давно с BeagleBone Black. Фоном по просьбе одного из институтов инициативно делаем BSP для OrangePi PC. Когда последний будет готов, вероятно, выкатим его в свой публичный GIT-репозиторий как пример. Но это вопрос несколько отдалённый.
Добрый день! Ваше наблюдение относительно исторической связи с QNX верно. Если кратко, то обсуждаемая ОС - это полноценный форк с 18+ летней историей. Чуть подробнее коллеги отвечали вот в этой теме.
Немного приоткрывающую завесу статью мы уже подготовили, но она лишь третья в очерёдности на публикацию (считая эту). Через пару недель появится в блоге. На примере одной из подсистем будет рассказываться как становилась разработка: от изучения и воспроизведения и до самостоятельного определения векторов развития.