Системное программирование *

Как и зачем дублировать Intel NTB Gen3 в QEMU

Системным программистам в YADRO нужно было «обмануть» драйвер в Linux: он не должен «знать», что работает в эмуляции. 

Для этого ведущий инженер Никита приступил к созданию виртуального двойника Intel NTB Gen3 в QEMU, документации к которому в открытом доступе нет. Реализованная модель позволяет производить разработку и тестирование протоколов более высокого уровня, а также выполнять их качественное сравнение.

PCIe NTB не позволяет увидеть адресное пространство, которое принадлежит к подключенному по NTB соседнему устройству. Вкратце он работает так:

• перенаправляет трафик PCIe между шинами как мост,

• CPU рассматривает мост как конечное устройство,

• CPU не «видит» все устройства на «другой» стороне, как правило, другая сторона — это другой компьютер.

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

В работе с PCI BAR необходимо обеспечить прозрачное использование Linux-драйвера Intel NTB для оптимального взаимодействия с оборудованием, которое мы эмулируем. Еще одна задача — разработать новые транспорты, которые работают поверх эмуляции: RPMSG, Virtio/Vhost, NTRDMA и другие. Также одна модель помогла найти ошибки в инициализации драйвера.

Никита подробно описывает тернистый путь создания виртуального двойника Intel NTB Gen3 в статье →

«Пушим байты» в сугробы: новогодняя демосцена 2025

Признанная классика демосцены — PICO-8, в арсенале которой сотни игр разной сложности. Мы же пойдем более оригинальным путем и напишем новогоднюю демку для BytePusher. Эта приставка включает 8-битный процессор, предлагает разрешение 256x256 и 8-битный цвет. Но самое интересное в ней — это OISC-архитектура ByteByeJump (BBJ).

OISC, One-Instruction Set Computer, известна гораздо меньше, чем RISC или CISC. Ее простота, очевидная из названия, привлекает немного энтузиастов, судя по странице BytePusher. Тем интересней будет сделать что-нибудь для нее с нуля.

Этим и занялся в своей статье Пётр Советов, специалист в области разработки DSL-компиляторов и старший научный сотрудник лаборатории специализированных вычислительных систем РТУ МИРЭА. Написал ассемблер на Python, разобрался с вычислениями без АЛУ и «отрисовал» классическое демо с падающим снегом. Еще и со «звездочкой» в виде сугробов и статичных цифр.

Читать полное руководство →

Три проверенных метода организовать обмен прерываниями между машинами QEMU c KVM и без

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

Быстрая работа такой связки приятна при разработке/отладке и очень важна при массовом прогоне автотестов в CI. Как оптимизировать обмен прерываниями и какой подход к организации IQI вам подойдет — узнаете из статьи. А еще разберемся c:

• устройством QEMU под капотом,

• реализацией модели и драйвера,

• добавлением прерываний MSI-X,

• результатами замеров.

На бонус: десяток полезных материалов для изучения.

Битовые маски #17: О гипервизорах, реализации разных языков и будущем системного программирования

Смотреть или слушать →

В гостях у подкаста «Битовые маски» — Николай Иготти, разработчик, участвовавший в создании многих известных проектов международных корпораций. Николай успел поработать над HotSpot в Sun Microsystems, над гипервизором VirtualBox, а также в разных проектах Google и EMC. Руководил разработкой Kotlin/Native компилятора и Compose Multiplatform в JetBrains, а сейчас трудится в Huawei. В выпуске затронули много разных тем — от гипервизоров до дизайна современных языков программирования:

• Чем виртуальные машины отличаются друг от друга и от процессоров.

• В чем сложности создания гипервизоров.

• С какими проблемами придется столкнуться при создании нового языка программирования.

• В чем особенности и отличия разработки системного ПО от прикладного.

• Как связана разработка современных UI-фреймворков с системным программированием.

• Какие задачи в системном программирование самые интересные.

• Как учить будущих специалистов в этой сфере.

Бонус: разбор того, что не давало запустить VirtualBox c MacOS на архитектуре x86.

Книга по C и не только

Добрый день. Пару месяцев назад я закончил написание книги и выставляю её в открытый доступ: GitHub

В чём идея? Контент этой книги представляет собой не только обучение языку C, но и обучение большому количеству прикладных вещей с серьёзной глубиной погружения. Я постарался дать ответ на как можно большее количество вопросов, которые возникают в процессе изучения, оставив минимальное количество дыр в понимании, как всё работает.

Посмотреть .html файл книги можно на GitHub-е. Но он не рендерит MathJax, поэтому лучше скачать файл c-book.html локально. Можно как угодно (в том числе в issues) сообщать мне о нерабочем коде в примерах, опечатках, неправильных утверждениях с моей стороны. Буду также рад увидеть конструктивную критику. Возможно, в ответ на неё, я буду добавлять новые главы в книгу.

(Эта книга абсолютно точно не является рекламой Zig-а.)

Почему умирает OpenHarmony

Если вы откроете проект на gitee.com вы увидите что проект включает в себя больше 700 (семисот!) репозиториев. Секрет в том что ни один из этих проектов в отдельном репозитории не компилируется независимо! Один знакомый разработчик, который работает с этим богатством, рассказал мне, что чтобы скомпилировать какой либо из проектов составляющих OpenHarmony вы должны скачать и скомпилировать минимум 450 репозиториев! Дело в том что даже отдельные приложения такие как mailBox, storage с СМС-ками, с контактами, видео плеер, ... которые, казалось бы, должны быть отдельными приложениями таковыми не являются. Они все компилируются как части одной монолитной прошивки смартфона (как части операционной системы) и вы не можете скомпилировать их без компиляции всей системы, такая опция просто не предусмотрена.

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

Каждый новый добавленный в OpenHarmony репозиторий приближает видимый крах проекта.

Интересно как обстоят дела у Андроида в этом смысле.

Первая вакансия на Zig в России

Собственно вот: https://career.habr.com/vacancies/1000147586

Вот мы (те кто следит за языком Zig) и дожили до этого момента. Большой вопрос зачем Zig в проде сейчас. Но сам факт такого похвальный. Начали появляться смельчаки, готовые взять ещё очень молодой язык в работу. Я туда не откликнусь, не мой стек. Но может найдутся желающие

Всем привет. Возможно, вы помните меня по статьям об изменениях в C++ и о фреймворке 🐙 userver, поэтому сразу к делу. 27 июля я выступаю на конференции C++ Zero Cost Conf, которая пройдёт в Москве и Ереване. Там я поделюсь новостями со встречи Международного комитета по стандартизации языка в Сент-Луисе и расскажу о наших планах на C++26 и C++29. А ещё отвечу на ваши вопросы. Приходите в гости!

Помимо меня, вас также будут ждать: 

• Константин Владимиров, руководитель отдела компиляторов и средств разработки Syntacore. Покажет развитие архитектуры сложного LLVM-based-C++-проекта и конкретные задачи, возникающие при его развитии.

• Андрей Аксёнов, руководитель разработки инфраструктуры поиска Авито/Sphinx. Расскажет историю из продакшена с One Billion Row Challenge, парсингом гигабайтов TSV’шек, десятью странными оптимизациями и боттлнеками вообще везде.

• Сергей Слотин, разработчик. Поговорит об устройстве памяти и кешей, их странностях и неожиданных последствиях для производительности.

• Константин Облаков, старший разработчик браузера Яндекс Поиска и Рекламных технологий. Покажет на практике, как GDB позволяет добиться результатов, недоступных другими методами.

Полный список спикеров и темы докладов смотрите на сайте. 

Если не получится прийти лично, подключайтесь дистанционно.

Готов HTML и EPUB книги об учебной операционной системе xv6.

Яндекс.Диск:

• Книга об xv6 на русском языке в формате PDF

• Книга об xv6 на русском языке в формате EPUB

• Книга об xv6 на русском языке в формате HTML

Google.Drive: https://drive.google.com/drive/folders/1Rt7hcHysWAilDn64uf-RpLACuJ39YKaR

25.03.2024 года «Лаборатория программно‑аппаратных комплексов с искусственным интеллектом» при финансовой поддержке ООО «НИЦ ЦТ» организовала первый семинар, посвящённый системному программированию.

Докладчики: сотрудники МЦСТ Александр Ермолицкий, Мурад Нейман‑заде. Предварительная тема: «Обзор оптимизаций компилятора LCC».

Запись мероприятия доступна по этой ссылке.

Откуда берётся мусор?

Рассмотрим следующую программу:

#include <stdio.h>
int main () {
  int a [100];
  int i;
  for (i=0; i<100; i++)
    printf ("%d ", a[i]);
  return 0;
}

При компиляции без оптимизации и вызове в Linux она выдаст некоторые числа, являющиеся мусорным содержимым памяти. Кто-нибудь в состоянии объяснить, откуда конкретно они берутся, и почему каждый раз разные при последовательных запусках программы?

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

Объяснение в стиле “потому что виртуальные адреса мапируются на реальные рандомно” я и сам могу дать, хочется более глубокого понимания. Компьютер – вещь детерминированная, в нём случайность – это не познанная закономерность.

Upd: ответ дан уважаемым @alexvangog в закреплённом комментарии.

Утечки памяти преследовали программы на языке С с тех пор, как существует этот язык. Было предложено множество решений, вплоть до идеи переписать программы на языке C на других языках. Но есть лучший способ.

Здесь представлено простое решение, которое устранит утечки памяти в каждой программе на языке C. Используйте этот модуль с вашей программой, и утечки памяти останутся в прошлом.

#include <dlfcn.h>
#include <stdio.h>

struct leaksaver {
        struct leaksaver *next;
        void *pointer;
} *bigbucket;

void *
malloc(size_t len)
{
        static void *(*nextmalloc)(size_t);
        nextmalloc = dlsym(RTLD_NEXT, "malloc");
        void *ptr = nextmalloc(len);
        if (ptr) {
                struct leaksaver *saver = nextmalloc(sizeof(*saver));
                saver->pointer = ptr;
                saver->next = bigbucket;
                bigbucket = saver;
        }
        return ptr;

Пояснение автора кода в оригинале:

Every allocated pointer is saved in the big bucket, where it remains accessible. Even if no other references to the pointer exist in the program, the pointer has not leaked.

It is now entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional.

Problem sovled!