Предлагаю эксперимент (на вашем же стенде и железе): запустите тестовые qemu с приоритетом реального времени и замерьте времена хотя бы первого (стандартного, самого неэффективного) метода. Сравнив, можно будет отделить влияние планирования и выполнения других задач в промежутке от накладных расходов самого метода.
Небольшое пояснение: передача сообщений с помощью binder эквивалентна передаче приёмнику остатка своего time slice (перепланировки не происходит, сразу начинает выполняться приёмник). Это его основное преимущество с точки зрения быстродействия перед другими методами.
PS: про Zephir OS на MCU в SoC iMX - было интересно. В rk3566 в качестве MCU используется не Cortex M4, а rusc-v процессор E902 (аналог Cortex M0). Обмен между ядрами - через группу регистров (вроде 4), после записи во все возникает (передаётся) прерывание для целевого ядра.
Ну статья как бы о самом быстром способе передачи прерывания (сигнала) между двумя qemu. При этом вопрос задержки выполнения приемника (планирования его выполнения) не освещён. Может скопилась длинная очередь других задач, ожидающих выполнения. Но если это не так (только два qemu и никаких других работ или сервисов на рабочей машине), то да, различий не будет при любом методе IMHO. Но и смысл статьи тогда теряется.
Насчёт передачи 16 файловых дескрипторов. Вроде там м слона можно передать: в вызове binder указывается область в своей памяти с данными для передачи и толи они копируются а область памяти target task потом, толи вообще там разделяемая между задачами память организуется.
Второе: вызов binder фактически сразу переключает выполнение с нашей задачи на выполнение target task. А мы ведь про страусов (скорость)?
А про то, что в qemu пока не реализовано, так в нем особо не стремятся быть струсом (супер быстрым)
Задача KVM - это исключить двойной переход из ядра в usersoace и обратно для случая обращения гостевой системы к сетевой карте или диску и тп. Вряд ли он рассчитан на максимально быструю передачу управления от источника к приёмнику
Буду рад ошибиться. Есть пруфы в этой области для KVM? Или всё же целевая система получит управление только в порядке общего планирования?
Статья понравилась. Как описанием возможностей библиотеки WiringRP, так и описанием процесса конфигурации (выбора) ядра в дистрибутиве Repka и его драйверов.
Как я понял, учитывался вариант работы и без KVM (есть такие моменты в статье). А преимущество binder перед socket наверно вытекают из того, что если бы socket имет преимущества, то его бы и не изобретали (как и kdbus). В каком месте socket ,то использовался? (или что там, уже не помню в варианте без kvm)
Интересная информация про celadon. Intel вроде и во времена Android 4 что то пытался сделать. Но видно не очень активно, раз до сих пор сыровато.
Но специфичного именно для Intel вроде в Андроид и нет. Ядро - оно и в Африке ядро. Работают же на нем все Линукс ОС Правда процессоры от Intel достали Торвальдса багами, но их и в Arm64 полно. Мне на x86 понравилась Remix OS. Минус - они как то странно реализовали файловую систему (вроде внутри раздела fat, если не забыл). Нет чтоб без изысков на ext4. А так то интерфейс приятный. Android-x86 зачем то полностью копировал схему загрузки как у смартфонов. Хотя можно было бы тут использовать схему обычных Linux OS
Для Андроид был интересный проект - несколько usersoace под одним ядром (название быстро не вспомню, исходники были доступны). Смысл - один usersoace - для обычного просмотра интернет. А другой - для более доверенных приложений (банки, работа)/ Но вроде в Xiaomi что то подобное уже есть. Только без объяснений (ну что значит shadow space, чем он хорош и как пользоваться).
Удивляет уклон на Intel. Типа только на нем. Хотя на YouTube полно видео установки на Amd Ryzen. Ну да, сейчас 2024 год, а не 2019. Однако Ryzen 5 2500u появился в 2018.
Здорово. Однако, по моему мнению, сейчас Arm64 имеет преимущество в плане открытости. Для Intel так и её освоили открытый Биос. Для Arm64 уже практически готов UEFI и после этого можно пробовать запускать Windows для Arm64.
Вот мнение GigsChat: Да, ваша точка зрения вполне обоснованна. Одна из возможных причин отсутствия использования Binder IPC в данном конкретном проекте может заключаться в недостаточной осведомлённости разработчиков об этом механизме. Действительно, несмотря на широкую распространённость Binder IPC в экосистеме Android, его применение в других контекстах остаётся ограниченным.
Вот несколько аспектов, которые могут объяснить такую ситуацию:
1. Скрытая природа Binder IPC в Android: Как вы правильно заметили, в Android использование Binder IPC скрыто от большинства разработчиков приложений. Он встроен глубоко в систему и используется для взаимодействия между службами и приложениями, но для обычного разработчика Android-приложений это не столь очевидно. Соответственно, многие разработчики могут даже не знать о существовании этого механизма.
2. Отсутствие активного обучения: В отличие от других механизмов IPC, таких как сокеты или каналы, Binder IPC редко рассматривается в учебных материалах и курсах по программированию. Это может объясняться тем, что Binder IPC тесно связан с Android и считается специализированной технологией, которая не часто обсуждается вне контекста этой платформы.
3. Ограниченная документация: Документация по Binder IPC доступна, но она зачастую ориентирована на специалистов, работающих непосредственно с ядрами Linux и Android. Это делает её менее доступной для широкой аудитории разработчиков.
4. Нехватка примеров использования вне Android: Хотя теоретически Binder IPC может быть использован в любых дистрибутивах Linux, примеров его применения вне Android относительно мало. Это затрудняет понимание возможностей и преимуществ данного механизма для разработчиков, работающих в других областях.
Таким образом, отсутствие знаний о Binder IPC среди разработчиков может быть основной причиной того, что они предпочли создать собственный драйвер вместо использования уже существующей технологии.
binder вроде как раз для моментального обмена сообщениями между задачами. В Qemu его использование ещё не встроили? Короче, преимущества конкретного решения перед binder?
Однако вопрос про API_ID и API_HASH в официальных клиентах ТГ: разве узнать их так сложно? Я про возможность работать под личиной официального клиента.
Лазер - направленная система излучения. Зеркалом можно расширить (наверное) пучок, что по идее должно уменьшить влияние локальных неоднородностей. Я правильно понял? А фронты лазер вроде и без зеркал нормально формирует (если под фронтами понимать модуляцию сигнала: переход из 0 в 1 и тп)
Предлагаю эксперимент (на вашем же стенде и железе): запустите тестовые qemu с приоритетом реального времени и замерьте времена хотя бы первого (стандартного, самого неэффективного) метода. Сравнив, можно будет отделить влияние планирования и выполнения других задач в промежутке от накладных расходов самого метода.
Небольшое пояснение: передача сообщений с помощью binder эквивалентна передаче приёмнику остатка своего time slice (перепланировки не происходит, сразу начинает выполняться приёмник). Это его основное преимущество с точки зрения быстродействия перед другими методами.
PS: про Zephir OS на MCU в SoC iMX - было интересно. В rk3566 в качестве MCU используется не Cortex M4, а rusc-v процессор E902 (аналог Cortex M0). Обмен между ядрами - через группу регистров (вроде 4), после записи во все возникает (передаётся) прерывание для целевого ядра.
Ну статья как бы о самом быстром способе передачи прерывания (сигнала) между двумя qemu. При этом вопрос задержки выполнения приемника (планирования его выполнения) не освещён. Может скопилась длинная очередь других задач, ожидающих выполнения. Но если это не так (только два qemu и никаких других работ или сервисов на рабочей машине), то да, различий не будет при любом методе IMHO. Но и смысл статьи тогда теряется.
PS: с какой целью? Наверно в порядке дискуссии.
Насчёт передачи 16 файловых дескрипторов. Вроде там м слона можно передать: в вызове binder указывается область в своей памяти с данными для передачи и толи они копируются а область памяти target task потом, толи вообще там разделяемая между задачами память организуется.
Второе: вызов binder фактически сразу переключает выполнение с нашей задачи на выполнение target task. А мы ведь про страусов (скорость)?
А про то, что в qemu пока не реализовано, так в нем особо не стремятся быть струсом (супер быстрым)
Задача KVM - это исключить двойной переход из ядра в usersoace и обратно для случая обращения гостевой системы к сетевой карте или диску и тп. Вряд ли он рассчитан на максимально быструю передачу управления от источника к приёмнику
Буду рад ошибиться. Есть пруфы в этой области для KVM? Или всё же целевая система получит управление только в порядке общего планирования?
Перечень версий ядер LTS и где какие версии используются, как ни странно, - довольно полезная информация. Спасибо.
Читается почти как детекив
Статья понравилась. Как описанием возможностей библиотеки WiringRP, так и описанием процесса конфигурации (выбора) ядра в дистрибутиве Repka и его драйверов.
Организм приспособлен, но нужно ещё научиться. А влияние инстинкта - внутреннее беспокойство, нервное возбуждение . По моему, это главное в статье.
Как я понял, учитывался вариант работы и без KVM (есть такие моменты в статье). А преимущество binder перед socket наверно вытекают из того, что если бы socket имет преимущества, то его бы и не изобретали (как и kdbus). В каком месте socket ,то использовался? (или что там, уже не помню в варианте без kvm)
Пропустил этот момент. Получается, что разработка - огонь.
Интересная информация про celadon. Intel вроде и во времена Android 4 что то пытался сделать. Но видно не очень активно, раз до сих пор сыровато.
Но специфичного именно для Intel вроде в Андроид и нет. Ядро - оно и в Африке ядро. Работают же на нем все Линукс ОС Правда процессоры от Intel достали Торвальдса багами, но их и в Arm64 полно. Мне на x86 понравилась Remix OS. Минус - они как то странно реализовали файловую систему (вроде внутри раздела fat, если не забыл). Нет чтоб без изысков на ext4. А так то интерфейс приятный. Android-x86 зачем то полностью копировал схему загрузки как у смартфонов. Хотя можно было бы тут использовать схему обычных Linux OS
Для Андроид был интересный проект - несколько usersoace под одним ядром (название быстро не вспомню, исходники были доступны). Смысл - один usersoace - для обычного просмотра интернет. А другой - для более доверенных приложений (банки, работа)/ Но вроде в Xiaomi что то подобное уже есть. Только без объяснений (ну что значит shadow space, чем он хорош и как пользоваться).
Собрать из исходников рабочее ядро можно? Чтоб MacOs потом из под него работало? (пока не дока в этой теме)
Удивляет уклон на Intel. Типа только на нем. Хотя на YouTube полно видео установки на Amd Ryzen. Ну да, сейчас 2024 год, а не 2019. Однако Ryzen 5 2500u появился в 2018.
Здорово. Однако, по моему мнению, сейчас Arm64 имеет преимущество в плане открытости. Для Intel так и её освоили открытый Биос. Для Arm64 уже практически готов UEFI и после этого можно пробовать запускать Windows для Arm64.
Вот мнение GigsChat: Да, ваша точка зрения вполне обоснованна. Одна из возможных причин отсутствия использования Binder IPC в данном конкретном проекте может заключаться в недостаточной осведомлённости разработчиков об этом механизме. Действительно, несмотря на широкую распространённость Binder IPC в экосистеме Android, его применение в других контекстах остаётся ограниченным.
Вот несколько аспектов, которые могут объяснить такую ситуацию:
1. Скрытая природа Binder IPC в Android: Как вы правильно заметили, в Android использование Binder IPC скрыто от большинства разработчиков приложений. Он встроен глубоко в систему и используется для взаимодействия между службами и приложениями, но для обычного разработчика Android-приложений это не столь очевидно. Соответственно, многие разработчики могут даже не знать о существовании этого механизма.
2. Отсутствие активного обучения: В отличие от других механизмов IPC, таких как сокеты или каналы, Binder IPC редко рассматривается в учебных материалах и курсах по программированию. Это может объясняться тем, что Binder IPC тесно связан с Android и считается специализированной технологией, которая не часто обсуждается вне контекста этой платформы.
3. Ограниченная документация: Документация по Binder IPC доступна, но она зачастую ориентирована на специалистов, работающих непосредственно с ядрами Linux и Android. Это делает её менее доступной для широкой аудитории разработчиков.
4. Нехватка примеров использования вне Android: Хотя теоретически Binder IPC может быть использован в любых дистрибутивах Linux, примеров его применения вне Android относительно мало. Это затрудняет понимание возможностей и преимуществ данного механизма для разработчиков, работающих в других областях.
Таким образом, отсутствие знаний о Binder IPC среди разработчиков может быть основной причиной того, что они предпочли создать собственный драйвер вместо использования уже существующей технологии.
binder вроде как раз для моментального обмена сообщениями между задачами. В Qemu его использование ещё не встроили? Короче, преимущества конкретного решения перед binder?
Однако вопрос про API_ID и API_HASH в официальных клиентах ТГ: разве узнать их так сложно? Я про возможность работать под личиной официального клиента.
Тема App ID и App hash, по моему, не раскрыта В чем их смысл? Разве есть защита от изменения официальных клиентов?
Лазер - направленная система излучения. Зеркалом можно расширить (наверное) пучок, что по идее должно уменьшить влияние локальных неоднородностей. Я правильно понял? А фронты лазер вроде и без зеркал нормально формирует (если под фронтами понимать модуляцию сигнала: переход из 0 в 1 и тп)
А как ИИ ведёт себя, если ему подать на вход неоднозначные высказывания?