Чтение порта ввода вывода занимает наносекунды, а передача такого события указанными вами способами будет занимать десятки и сотни микросекунд и даже миллисекунды. Разница в десятки тысяч и до миллионов раз.
И что ? Более того, если это I2C GPIO Expander (а это уже не "чтение порта ввода/вывода"), то будет еще дольше - и я не вижу в этом проблемы.
Для некоторых процессов это просто не имеет значения - например выполнить скрипт по кнопке. Для других процессов важна не скорость передачи события, а сама временная метка, которая, как я уже писал, присваивается ядром.
Ваш комментарий мне непонятен, что именно полагается под "ядерным реактором" ?
Подключиться к порту с помощью netcat/socat или пробросить порт по ssh "ssh -R 1500:localhost:1500 user@remote-server.com" ? Ни то ни другое мне не кажется сложной задачей или некими сакральными знаниями.
Так как epoll_wait блокирует поток, в котором он вызывается, до получения каких-либо событий,
Честно говоря не знаю применимо ли это к libcoro и к вашей ситуации, но в Linux есть такие штуки как timerfd, signalfd, а вместо pipe можно воспользоваться eventfd.
Конечно подходит. Но я не только про GD32, а в целом применительно к условно любой модели, которую потребуется создать - очень часто в наличии только TrM (что вообще говоря уже хорошо).
Во-вторых если просто брать дельту между появлением коммита и его Fixes:, без дополнительного анализа это нам вообще НИОЧЁМ не скажет. Например https://patchwork.kernel.org/project/linux-dmaengine/list/?series=856378&state=* - фиксы Intel IO/AT DMA "probing error path", они в приципе были найдены в очень специфических условиях, не опасны и не проявлялись при обычных условиях.
Надо править если нашли ? Безусловно. Критичны ли они ? Безусловно нет.
kvm-qemu или просто qemu (уже давно qemu-kvm не используется как отдельная сущность) или просто KVM - не бывает под неродные архитектуры;
за "неродные архитектуры" отвечает QEMU TCG (user или system) который занимается трансляцией инструкций на лету (да тот же самый JIT с некоторыми трюками, чтобы работать быстрее);
"эмуляция на x86_64 платформе" не только на x86_64, а вообще говоря практически на любой, если же трансляция на архитектуру не поддерживается, есть режим интерпретатора;
QEMU давно вышел за рамки академического интереса и применяется многими сущностями - например тестирование zephyr;
$ git clone https://git.openelbrus.ru/mcst/qemu.git
$ cd qemu
$ ./configure --target-list=e2k-linux-user
$ make
$ build/qemu-e2k --help
usage: qemu-e2k [options] program [arguments...]
Linux CPU emulator (compiled for e2k emulation)
Такие новости это всегда хорошо, тем более что в QEMU добавлена новая архитектура, что редкость и всегда хорошо в качестве примера.
Спасибо МЦСТ, за этот новогодний подарок !
Тем не менее, если я не ошибаюсь, эмулятор был сделан даже до выпуска первого процессора, поэтому интересно почему именно сейчас и почему так поздно это было сделано.
qemu‑system — эмулятор уровня системы, позволяющий запустить целую операционную систему, такую как Linux;
В предоставленном репозитории есть только qemu-user, qemu‑system отсутвует, так как не добавлено ни одной машины.
выпустила в открытый доступ
Очень жаль, что сделано это в отвратительной манере ctrl+c, ctrl+v с затиранием всей оригинальной истории и нахлобучиванием одного коммита в стиле One Patch Man.
Нет, к сожалению, никаких специальных инструментов, только расширение функционала QEMU.
Если порассуждать то в первую очередь пригодилась бы конвертация таблиц из pdf файлов в условно любой текстовый формат, чтобы генерировать код с описанием регистров.
Так же, в нашем случае уже был обширный набор реальных и тестировочных программ, но в случае разработки модели для нового SoC, особенно если у него плохая документация, надо начинать с набора тестов для проверки соответствия поведения моделей с реальным поведением устройств.
О! IOMMU это замечательная вещь, которая применима в данной ситуации приблизительно... никак. Тем не менее, и как вы, в общих чертах, видите тут применение IOMMU ?
gcc 4.9 это я конечно от балды сказал, подсмотрев какие версии compiler explorer поддерживает. Речь скорее за ситуацию, когда зависимости требуют одновременно и несколько древние (но присутствовавшие и ещё не выпиленные) и свежие зависимости и все, которых могло и не существовать на момент существования прошлых зависимостей.
Это можно, это будет встроено в общую парадигму Nix и делается средствами Nix (я не буду говорить, что это будет легко), иммутабельно, воспроизводимо (тут Nix не врёт), но вы за это заплатите:
такая "старая" зависимость потянет за собой все старые версии из предыдущего среза, если конечно нет пересечений множеств старого и нового среза (скорей всего их не будет) и в итоге вы будете иметь два rootfs пересекающихся в данной точке;
двойной ценой за два экземпляра nixpkgs - хэши и зависимости будут считаться отдельно;
Собственно обратная ситуация тоже возможна - например debian по-умолчанию использует gcc 12 и clang 14, а мы например хотим собирать код С++20 компиляторами с их стабильной поддержкой - то бишь gcc не старше 14 и clang не ранее 19. trunk версии там ещё выше, естественнно.
Тоже можно те же самые преимкщества, но возможно придётся прописывать все зависимости - менять версию и проверять это тоже работа и немалая.
это какое-то наше произвольное имя, которое мы задаём, так?
Абсолютно верно.
вот этот момент кстати тоже несколько непонятен. Мне казалось, что мы где-то явно указываем, что входит в окружение develop и что помимо develop есть ещё другие варианты, но в примере вашего скрипта develop нигде явно не упоминался.
Я не автор, просто мимо пробегал, а тут так интересно (не считая первого комментария разумеется).
Вот тут интересная вещь, дело в том что в старой версии есть такая вещь как nix-shell, которой нет в "nix flakes" которую использует автор статьи. В статье явно прописан "devShells.${system}.default", который как "all" для Makefile и будет вызван для "nix develop", который ничо иное как "nix develop .#devShells.x86_64-linux.default" или "nix develop .#" собственно он его берет из flake.nix:
Далее это именно прописанный shell, он нужен, чтобы мы знали сразу о hello-json-c и hello-json-cc - за это отвечает inputsFrom. Мы могли бы просто вызвать "nix develop .#packages.x86_64-linux.hello-json-c" и получили бы окружение для hello-json-c без знания о hello-json-cс (если бы у нас не был общий cmake) но точно без зависимости nlohmann_json, если у нас именно полноценный NixOS, а не просто утилита nix.
Каждый срез nixpkgs содержит весь срез прошлых версий?
Нет не содержит - удаляются постепенно.
Тогда в большинстве случаев вы берете какую-нибудь версию nixpkgs и eсли как в вашем примере версия gcc 4.9.X которой нету pkgs/development/compilers/gcc/versions.nix:
commit 88950412bcdc0fde3811444024b46a79ffc56068
Author: Sergei Trofimovich <slyich@gmail.com>
Date: Wed Sep 11 21:57:54 2024 +0100
gcc49, gcc49Stdenv, gfortran49: remove old implementation
gcc-4.9.4 was released in Aug 3, 2016, 8 years ago. It's a branch that
went out of support years ago. Numerous bugs never get backported to
this version.
Let's remove it.
Вам придётся её добавлять хотя бы для своего пакета (я уверен, что с 4.9 gcc 25.05 мы просто не соберём), каким-то образом:
Я бы ответил на ваш вопрос "нет", тот flake.nix в статье так просто не кросскомпилируешь, его необходимо немного переписать на мой взгляд, так как там уже закреплёна система. Ему надо либо прописывать каждый кросс либо добавлять к существующим пакетам nixpkgs (это можно сделать не меняя проект). И я бы не назвал эти манипуляции "без напильника".
И что ? Более того, если это I2C GPIO Expander (а это уже не "чтение порта ввода/вывода"), то будет еще дольше - и я не вижу в этом проблемы.
Для некоторых процессов это просто не имеет значения - например выполнить скрипт по кнопке. Для других процессов важна не скорость передачи события, а сама временная метка, которая, как я уже писал, присваивается ядром.
У каждого процесса свои требования.
Ваш комментарий мне непонятен, что именно полагается под "ядерным реактором" ?
Подключиться к порту с помощью netcat/socat или пробросить порт по ssh "ssh -R 1500:localhost:1500 user@remote-server.com" ? Ни то ни другое мне не кажется сложной задачей или некими сакральными знаниями.
Всё правильно и разумно, но у меня есть вопросы к автору:
Как вы думаете, почему такие очевидные и само собой разумеющиеся вещи требуют дополнительного обоснования подобного рода?
Почему вы не развиваете идею дальше и не требуете подробного и исчерпывающего описания коммита ?
Спасибо за статью - прочитал с удовольствием.
Честно говоря не знаю применимо ли это к libcoro и к вашей ситуации, но в Linux есть такие штуки как timerfd, signalfd, а вместо pipe можно воспользоваться eventfd.
Да в таком случае можно автоматом сгенерировать таблицы регистров с использованием RegisterInfo/RegisterAccessInfo. Спасибо!
Да - выглядит неплохо. Жаль, что перестали обновлять.
Конечно подходит. Но я не только про GD32, а в целом применительно к условно любой модели, которую потребуется создать - очень часто в наличии только TrM (что вообще говоря уже хорошо).
Ну во-первых было https://habr.com/ru/news/983898/.
Во-вторых если просто брать дельту между появлением коммита и его Fixes:, без дополнительного анализа это нам вообще НИОЧЁМ не скажет. Например https://patchwork.kernel.org/project/linux-dmaengine/list/?series=856378&state=* - фиксы Intel IO/AT DMA "probing error path", они в приципе были найдены в очень специфических условиях, не опасны и не проявлялись при обычных условиях.
Надо править если нашли ? Безусловно. Критичны ли они ? Безусловно нет.
О как интересно! Я посмотрю сравню.
Видно ответ на мой комментарий.
У вас путаница в голове:
kvm-qemu или просто qemu (уже давно qemu-kvm не используется как отдельная сущность) или просто KVM - не бывает под неродные архитектуры;
за "неродные архитектуры" отвечает QEMU TCG (user или system) который занимается трансляцией инструкций на лету (да тот же самый JIT с некоторыми трюками, чтобы работать быстрее);
"эмуляция на x86_64 платформе" не только на x86_64, а вообще говоря практически на любой, если же трансляция на архитектуру не поддерживается, есть режим интерпретатора;
QEMU давно вышел за рамки академического интереса и применяется многими сущностями - например тестирование zephyr;
Какой ещё CMake в QEMU - его там никогда не было:
Такие новости это всегда хорошо, тем более что в QEMU добавлена новая архитектура, что редкость и всегда хорошо в качестве примера.
Спасибо МЦСТ, за этот новогодний подарок !
Тем не менее, если я не ошибаюсь, эмулятор был сделан даже до выпуска первого процессора, поэтому интересно почему именно сейчас и почему так поздно это было сделано.
В предоставленном репозитории есть только qemu-user, qemu‑system отсутвует, так как не добавлено ни одной машины.
Очень жаль, что сделано это в отвратительной манере ctrl+c, ctrl+v с затиранием всей оригинальной истории и нахлобучиванием одного коммита в стиле One Patch Man.
Это вас "обжиг кабелей" так возбудил или не верите, что платы занимают место в стойке и, о ужас, потребляют электричество ?
А если серьёзно, только пара человек заметила эту ошибку, она веселая и пусть будет как ОДПВ.
Нет, к сожалению, никаких специальных инструментов, только расширение функционала QEMU.
Если порассуждать то в первую очередь пригодилась бы конвертация таблиц из pdf файлов в условно любой текстовый формат, чтобы генерировать код с описанием регистров.
Так же, в нашем случае уже был обширный набор реальных и тестировочных программ, но в случае разработки модели для нового SoC, особенно если у него плохая документация, надо начинать с набора тестов для проверки соответствия поведения моделей с реальным поведением устройств.
Все верно - спасибо ! Чуть позже поправлю.
Опубликовано логическое продолжение "прозрачного" взаимодействия с устройствами внутри QEMU - QEMU: как организовать прозрачное взаимодействие с I2C-устройствами, которая является более удачным применением CUSE.
О! IOMMU это замечательная вещь, которая применима в данной ситуации приблизительно... никак. Тем не менее, и как вы, в общих чертах, видите тут применение IOMMU ?
Это можно, это будет встроено в общую парадигму Nix и делается средствами Nix (я не буду говорить, что это будет легко), иммутабельно, воспроизводимо (тут Nix не врёт), но вы за это заплатите:
такая "старая" зависимость потянет за собой все старые версии из предыдущего среза, если конечно нет пересечений множеств старого и нового среза (скорей всего их не будет) и в итоге вы будете иметь два rootfs пересекающихся в данной точке;
двойной ценой за два экземпляра nixpkgs - хэши и зависимости будут считаться отдельно;
Тоже можно те же самые преимкщества, но возможно придётся прописывать все зависимости - менять версию и проверять это тоже работа и немалая.
Абсолютно верно.
Я не автор, просто мимо пробегал, а тут так интересно (не считая первого комментария разумеется).
Вот тут интересная вещь, дело в том что в старой версии есть такая вещь как nix-shell, которой нет в "nix flakes" которую использует автор статьи. В статье явно прописан "devShells.${system}.default", который как "all" для Makefile и будет вызван для "nix develop", который ничо иное как "nix develop .#devShells.x86_64-linux.default" или "nix develop .#" собственно он его берет из flake.nix:
Далее это именно прописанный shell, он нужен, чтобы мы знали сразу о hello-json-c и hello-json-cc - за это отвечает inputsFrom. Мы могли бы просто вызвать "nix develop .#packages.x86_64-linux.hello-json-c" и получили бы окружение для hello-json-c без знания о hello-json-cс (если бы у нас не был общий cmake) но точно без зависимости nlohmann_json, если у нас именно полноценный NixOS, а не просто утилита nix.
Вот вопрос очень правильный и очень сложный
Нет не содержит - удаляются постепенно.
Тогда в большинстве случаев вы берете какую-нибудь версию nixpkgs и eсли как в вашем примере версия gcc 4.9.X которой нету pkgs/development/compilers/gcc/versions.nix:
Вам придётся её добавлять хотя бы для своего пакета (я уверен, что с 4.9 gcc 25.05 мы просто не соберём), каким-то образом:
добавить input для 24.10 (это до удаления):
И тогда можно будет использовать pkgs-legacy.gcc49Stdenv
вернуть то что удалили (тогда придётся собирать его заново из исходников);
подсунуть для конкретного вашего пакета прекомпилированный компилятор (а можно и пропиетарный);
Тогда всё это будет однозначно зафиксированно фашим flake файлом.
Я бы ответил на ваш вопрос "нет", тот flake.nix в статье так просто не кросскомпилируешь, его необходимо немного переписать на мой взгляд, так как там уже закреплёна система. Ему надо либо прописывать каждый кросс либо добавлять к существующим пакетам nixpkgs (это можно сделать не меняя проект). И я бы не назвал эти манипуляции "без напильника".
Тогда будет работать что-то вроде:
Как это работает сейчас с пакетом hello: