Перевод статьи из блога инженера Джорджа Хиллиарда


Кликабельно

Я инженер встроенных систем. В свободное время я часто ищу то, что можно будет использовать в проектировании будущих систем, или что-то из разряда моих интересов.

Одна из таких областей – дешёвые компьютеры, способные поддерживать Linux, и чем дешевле, тем лучше. Поэтому я зарылся в глубокую кроличью нору малоизвестных процессоров.

Я подумал: «Эти процессоры настолько дешёвые, что их практически можно раздавать даром». И через некоторое время ко мне пришла идея сделать голую карточку для Linux в форм-факторе визитной карточки.

Всем доброго здравия!

В преддверии Нового года хочу продолжить рассказывать про использование С++ на микроконтроллерах, на этот раз попытаюсь рассказать про использование шаблона Наблюдатель (но далее я буду называть его Издатель-Подписчик или просто Подписчик, такой вот каламбур), а также реализацию статической подписки на С++17 и преимущества этого подхода в некоторых приложениях.

Вторая часть: Принципы работы видеокодека

---

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

Если рассматривать итоговый цвет как комбинацию т.н. основных цветов (красного, зеленого и синего), в нашей трёхмерной матрице определяем три плоскости: первая для красного цвета, вторая для зеленого и последняя для синего.

Будем называть каждую точку в этой матрице пикселем (элементом изображения). Каждый пиксель содержит информацию об интенсивности (обычно в виде числового значение) каждого цвета. Например, красный пиксель означает, что в нём 0 зеленого цвета, 0 синего и максимум красного. Пиксель розового цвета может быть сформирован с помощью комбинации трех цветов. Используя числовой диапазон от 0 до 255, розовый пиксель определяется как Красный = 255, Зелёный = 192 и Синий = 203.

В WinAPI есть функция CreateRemoteThread, позволяющая запустить новый поток в адресном пространстве другого процесса. Её можно использовать для разнообразных DLL-инъекций как с нехорошими целями (читы в играх, кража паролей, и т. д.), так и для того, чтобы на лету исправить баг в работающей программе, или добавить плагины туда, где они не были предусмотрены.

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

Я подробно расскажу о том, как с помощью спецификации ELF, некоторого знания архитектуры x86_64 и системных вызовов Linux написать свой маленький кусочек отладчика, способный загрузить и исполнить произвольный код в уже запущенном и работающем процессе.

Для понимания текста потребуются базовые знания о системном программировании под Linux: язык Си, написание и отладка программ на нём, осознание роли машинного кода и памяти в работе компьютера, понятие системных вызовов, знакомство с основными библиотеками, навык чтения документации.

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

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



Осторожно: специфический юмор далее по тексту.

Доброго времени суток, уважаемый Хабр!

За последние пол года кривая дорожка моих пет-проектов завела меня в такие дебри, откуда до сих пор выбраться не представляется возможным. И начиналось-то все безобидно — сайт с картинками, но чувство перфекционизма, погоня за халявой, а также некоторые особенности моего склада ума превратили эту, как изначально планировалось, маленькую прогулку, в настоящее длинное путешествие. Ну и ладно, как говорил один довольно картавый революционер: «Учиться, учиться и еще раз учиться», а мне, волей-неволей, приходится этому напутствию следовать.

Ой, что-то мы отвлеклись от основной темы. Не буду больше вас утомлять пространными речами, а перейду к делу.

Общеизвестно, что семантика инициализации — одна из наиболее сложных частей C++. Существует множество видов инициализации, описываемых разным синтаксисом, и все они взаимодействуют сложным и вызывающим вопросы способом. C++11 принес концепцию «универсальной инициализации». К сожалению, она привнесла еще более сложные правила, и в свою очередь, их перекрыли в C++14, C++17 и снова поменяют в C++20.

Под катом — видео и перевод доклада Тимура Домлера (Timur Doumler) с конференции C++ Russia. Тимур вначале подводит исторические итоги эволюции инициализации в С++, дает системный обзор текущего варианта правила инициализации, типичных проблем и сюрпризов, объясняет, как использовать все эти правила эффективно, и, наконец, рассказывает о свежих предложениях в стандарт, которые могут сделать семантику инициализации C++20 немного более удобной. Далее повествование — от его лица.

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

Так как большинство программ для микроконтроллеров пишется на С/C++, то для этих целей обычно используют абстрактные классы, предоставляющие интерфейсы к низкоуровневым сущностям (в случае, если проект пишется только с использованием C, то зачастую используются структуры указателей на функции). Данный подход предоставляет требуемый уровень абстракции над железом, однако чреват надобностью в постоянной повторной компиляции проекта с последующим программированием энергонезависимой памяти микроконтроллера бинарным файлом прошивки большого объема.

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

В качестве скриптового языка я выбрал Lua.

Необходимое вступление

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

Но я гарантирую, что если отсутствие всякого понимания заменить моими трактовками и начать их применять, то код вами написанный будет проще сопровождать и изменять. Так же я прекрасно понимаю, что в комментариях мной написанное будут яростно дополнять, что позволит выправить совсем уж вопиющие упущения и нестыковки.

Столь малые гарантии поднимают вопросы о причинах, по которым статья пишется. Я считаю, что этим вещам должны учить везде, где учат программированию, вплоть до уроков информатики в школах с углублённым её изучением. Тем не менее, для меня стала пугающе нормальной ситуация, когда я узнаю, что собеседник мой коллега, причём работающий уже не первый год, но про инкапсуляцию «что-то там слышал». Необходимость собрать всё это в одном месте и давать ссылку при возникновении вопросов зрела давно. А тут ещё и мой «pet-project» дал мне изрядно пищи для размышлений.

Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.

This article is also available in English

Из-за массового выпуска смартфонов без аудиоразъема 3.5 мм беспроводные Bluetooth-наушники для многих стали основным способом прослушивания музыки и общения в режиме гарнитуры.
Производители беспроводных устройств не всегда пишут подробные характеристики товара, а статьи о Bluetooth-аудио в интернете противоречивы, местами некорректны, не рассказывают о всех особенностях, и часто копируют одну и ту же не соответствующую действительности информацию.
Попробуем разобраться с протоколом, возможностями Bluetooth-стеков ОС, наушников и колонок, Bluetooth-кодеков для музыки и речи, выясним, что влияет на качество передаваемого звука и задержку, научимся собирать и декодировать информацию о поддерживаемых кодеках и других возможностях устройств.

TL;DR:

• SBC — нормальный кодек
• У наушников есть свой эквалайзер и пост-процессинг на каждый кодек отдельно
• aptX не настолько хорош, как о нём говорят рекламные анонсы
• LDAC — маркетинговое фуфло
• Качество звука в режиме разговора всё ещё низкое
• В браузер можно встроить аудиоэнкодеры на C, скомпилировав в WebAssembly через emscripten, и они не будут особо тормозить.

В 2012 году на северо-востоке Москвы случился пожар. Загорелось старое здание с деревянными перекрытиями, огонь быстро перекинулся на соседние дома. Пожарные расчеты не могли подобраться к месту — все парковки вокруг были заставлены машинами. Огонь охватил полторы тысячи квадратных метров. Подобраться к гидранту тоже не удавалось, поэтому спасатели использовали пожарный поезд и даже два вертолета. Один сотрудник МЧС погиб в огне.

Как выяснилось позже, пожар начался в доме издательства «Мир».

Вряд ли это название что-то говорит большинству людей. Издательство и издательство, очередное привидение из советских времен, которое уже лет тридцать ничего не выпускало, но почему-то продолжало существовать. В конце нулевых оно было на грани банкротства, но каким-то образом возвращало долги, кому бы и что оно там ни было должно. Вся его современная история — это пара строк в Википедии о чехарде между всякими государственными МГУП ШМУП ФМУП, которые пылятся в папочках Ростеха (если верить Википедии, опять же).

Но за бюрократическими строчками нет ни слова о том, какое огромное наследие «Мир» оставил в Индии и как повлиял на жизнь нескольких поколений.

Добрый день! Несколько дней назад столкнулся с небольшой проблемой в нашем проекте — в обработчике прерывания gdb неправильно выводил stack trace для Cortex-M. Поэтому в очередной раз полез выяснять, а какими способами можно получать stack trace для ARM? Какие флаги компиляции влияют на возможность трассировки стека на ARM? Как это реализовано в ядре Linux? По результатам исследований решил написать эту статью.

Решение поставленной перед разработчиком задачи бывает найти нелегко. Но как только оно получено, автору сразу хочется поделиться им со всем миром, ведь это так здорово — «отгружать» код. Неиспользуемая программа — это не что иное, как цифровой мусор. Чтобы не тратить время на никому не нужный софт, современные разработчики поставляют функциональность небольшими порциями, разбивая процесс на короткие итерации.

Такой способ создания программного обеспечения используется в процессах Непрерывной интеграции (Continuous Integration) и Непрерывного развертывания (Continuous Deployment), или CI/CD-цепочке. В этой статье мы пройдем по всем шагам настройки такой цепочки, используя для ее построения бесплатные облачные сервисы.

Недавно мы писали о том, на какие ухищрения пошла Alibaba, чтобы сделать себе жизнь с OpenJDK более приемлемой. Там были комментарии вроде «оказывается, пока мы тут страдаем с обычной джавой, китайцы уже сделали себе свою особенную». Alibaba, конечно, впечатляет — но и в России есть свои фундаментальные проекты, где тоже делают «особенную джаву».

В Новосибирске вот уже 18 лет делают свою собственную JVM, написанную полностью самостоятельно и востребованную далеко за пределами России. Это не просто какой-то форк HotSpot, делающий всё то же самое, но чуть лучше. Excelsior JET — это комплекс решений, позволяющих делать совершенно другие вещи в плане AOT-компиляции. «Пфф, AOT есть в GraalVM», — можете сказать вы. Но GraalVM — это всё ещё очень исследовательская штука, а JET — это проверенное годами решение для использования в продакшене.

Это интервью с одними из разработчиков Excelsior JET. Надеюсь, оно окажется особенно интересно всем, кто хочет открыть для себя новые вещи, которые можно делать с Java. Либо людям, которые интересуются жизнью JVM-инженеров и сами хотят в этом поучаствовать.

Детальный взгляд на логирование переключение контекста с помощью Event Tracing API для Windows.

В ответ на пост прошлой недели, я получил следущее электронное письмо:

Может быть, я немножко опоздал с вопросом по поводу Вашего недавнего поста, но, на всякий случай, спрошу: Вы имеете какие-либо методы (стратегии) работы с внешней библиотекой, от которой Вы не можете избавиться, и которая нарушает некоторые (или все) принципы написания дизайна API (скорее всего, имеются в виду принципы, рекомендации, которые описаны в предыдущей статье автора. Прим. перев.)? Может, есть какие-то истории? Это расплывчатый вопрос, но я просто спрашиваю о любом опыте (как пользователя) использования API, который действительно запомнился.

— Michael Bartnett

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

Наверное, это была бы неплохая статья в цикле еженедельного разбора плохих API. Но, поскольку у меня нет времени на что-то подобное и есть возможность разобрать только один API, то возникает наиболее ВАЖНЫЙ вопрос — какой именно API я должен выбрать?

Event Tracing API для Windows

* Ссылка на библиотеку в конце статьи. В самой статье изложены механизмы, реализованные в библиотеке, со средней детализацией. Реализация для macOS еще не закончена, но она мало чем отличается от реализации для Linux. Здесь в основном рассматривается реализация для Linux.

Гуляя по гитхабу одним субботним днем, я наткнулся на библиотеку, реализующую обновление c++ кода налету для windows. Сам я слез с windows несколько лет назад, ни капли не пожалел, и сейчас все программирование происходит либо на Linux (дома), либо на macOS (на работе). Немного погуглив, я обнаружил, что подход из библиотеки выше достаточно популярен, и msvc использует ту же технику для функции "Edit and continue" в Visual Studio. Проблема лишь в том, что я не нашел ни одной реализации под не-windows (плохо искал?). На вопрос автору библиотеки выше, будет ли он делать порт под другие платформы, ответ был отрицательный.

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

"Как так?" — подумал я, и принялся раскуривать фимиам.

Хотя проект Vala был создан еще в 2006-м году, он до сих пор остается малоизвестным как среди простых пользователей, так и среди многих разработчиков. Мало кто понимает, что это такое и, главное, зачем это нужно. А уж среди русскоязычного IT-сообщества Vala и вовсе является чем-то загадочным и статей на эту тематику исчезающе мало. Я решил немного поправить текущую ситуацию и сделать небольшой экскурс по этой технологии.

Nuklear+ (читается как "Nuklear cross", значит "кроссплатформенный Nuklear") — это надстройка над GUI библиотекой Nuklear, которая позволяет абстрагироваться от драйвера вывода и взаимодействия с операционной системой. Нужно написать один простой код, а он потом уже сможет скомпилироваться под все поддерживаемые платформы.

Я уже писал на хабре статью "Nuklear — идеальный GUI для микро-проектов?". Тогда задача была простой — сделать маленькую кроссплатформенную утилиту с GUI, которая будет примерно одинаково выглядеть в Windows и Linux. Но с тех самых пор меня не отпускал вопрос, а можно ли на Nuklear сделать что-то более-менее сложное? Можно ли целиком на нём сделать какой-нибудь реальный проект, которым будут пользоваться?

Многие популярные библиотеки для тестирования, например Google Test, Catch2, Boost.Test тяжело завязаны на использование макросов, так что в качестве примера тестов на этих библиотеках вы обычно увидите картину вроде такой:

namespace {

// Tests the default c'tor.
TEST(MyString, DefaultConstructor) {
  const MyString s;
  EXPECT_STREQ(nullptr, s.c_string());
  EXPECT_EQ(0u, s.Length());
}

const char kHelloString[] = "Hello, world!";

// Tests the c'tor that accepts a C string.
TEST(MyString, ConstructorFromCString) {
  const MyString s(kHelloString);
  EXPECT_EQ(0, strcmp(s.c_string(), kHelloString));
  EXPECT_EQ(sizeof(kHelloString)/sizeof(kHelloString[0]) - 1,
            s.Length());
}

// Tests the copy c'tor.
TEST(MyString, CopyConstructor) {
  const MyString s1(kHelloString);
  const MyString s2 = s1;
  EXPECT_EQ(0, strcmp(s2.c_string(), kHelloString));
}
}  // namespace

К макросам в C++ отношение настороженное, почему же они так процветают в библиотеках для создания тестов?

Хотели ли Вы когда-нибудь заглянуть под капот операционной системы, посмотреть на внутреннее устройство её механизмов, покрутить винтики и посмотреть на открывшиеся возможности? Возможно, даже хотели поработать напрямую с железом, но считали, что драйвера — rocketscience?

Предлагаю вместе пройтись по мостику в ядро и посмотреть, насколько глубока кроличья нора.

Итак, представляю драйвер-фреймворк для kernel-хакинга, написанный на C++17, и призванный, по возможности, снять барьеры между ядром и юзермодом или максимально сгладить их присутствие. А также, набор юзермодных и ядерных API и обёрток для быстрой и удобной разработки в Ring0 как для новичков, так и для продвинутых программистов.

Основные возможности:

• Доступ к портам ввода-вывода, а также проброс инструкций in, out, cli и sti в юзермод через IOPL
• Обёртки над системной пищалкой
• Доступ к MSR (Model-Specific Registers)
• Набор функций для доступа к юзермодной памяти других процессов и к памяти ядра
• Работа с физической памятью, DMI/SMBIOS
• Создание юзермодных и ядерных потоков, доставка APC
• Юзермодные Ob*** и Ps***-каллбэки и фильтры файловой системы
• Загрузка неподписанных драйверов и ядерных библиотек

… и многое другое.