Linux *

Linux 6.16 принесет более быстрые файловые системы, улучшенную поддержку памяти и больше Rust

Linux продолжает развиваться, становясь больше и лучше. Вот что нового и примечательного в релизе 6.16, а также что нужно знать о 6.17. Изменения в последнем ядре Linux, версии 6.16, могут быть небольшими, но среди них есть весьма значимые. Сам Линус Торвальдс охарактеризовал этот релиз как "выглядит хорошо, небольшой и спокойный", но "не слишком интересный (в лучшем смысле этого слова!)".

Появились биндинги Rust к ядру для инфраструктуры драйверов и подсистемы PCI-устройств. Это упростит добавление новых драйверов оборудования, написанных на Rust. Интегрированы новые абстракции Rust в подсистему Direct Rendering Manager (DRM).

Файловые системы

XFS: Теперь поддерживает большие атомарные записи. Это означает, что операции записи, охватывающие несколько блоков, выполняются "атомарно" – либо обновляются все блоки, либо ни один. Усиливает целостность данных и предотвращает ошибки записи. Важно для компаний, использующих XFS в базах данных и системах хранения масштаба предприятия.

Самая популярная файловая система Linux, Ext4, также получает множество улучшений. Эти усовершенствования включают ускоренные пути фиксации (commit paths), поддержку больших фолио (large folio) и атомарные записи, охватывающие несколько блоков файловой системы (fsblocks) для файловых систем с bigalloc.

Прочее

Если вы через ноутбук на Linux проигрываете музыку, еще одна приятная новая функция — теперь вы можете транслировать аудио по USB, даже когда остальная часть системы находится в спящем режиме. Эта возможность была доступна в Android какое-то время, но теперь она стала частью основного (mainline) Linux.

Если безопасность является для вас приоритетом, ядро 6.16 теперь поддерживает Intel Trusted Execution Technology (TXT) и Intel Trusted Domain Extensions (TDX). Это дополнение, наряду с улучшенной поддержкой AMD Secure Encrypted Virtualization и Secure Memory Encryption (SEV-SNP) в Linux, позволяет шифровать память вашего программного обеспечения в рамках так называемых конфиденциальных вычислений (confidential computing). Эта функция повышает безопасность облаков, шифруя память виртуальной машины пользователя, что означает, что злоумышленник, взломавший облако, не сможет получить доступ к вашим данным.

В этом релизе есть и другие улучшения поддержки чипов в Linux. Для начала, Linux теперь поддерживает Intel Advanced Performance Extensions (APX). С APX Linux теперь может использовать 32 общецелевых регистра x86. Это вдвое больше, чем 16 регистров у старых чипов. Это улучшение означает, что вы увидите повышенную производительность от процессоров Intel следующего поколения, таких как Lunar Lake и серверные Granite Rapids Xeon.

Linux 6.16 приносит улучшенную поддержку GPU Nvidia Blackwell. Чипы Blackwell, используемые в основном для ИИ, уже развертываются в высокопроизводительных Linux-рабочих станциях.

На сетевом фронте изменения в работе TCP/IP с DMABUF позволят устройствам, включая GPU и ИИ-ускорители, ускорять свои сетевые операции, не нагружая при этом CPU. Хотя обычный пользователь может не заметить это изменение, пользователи высокопроизводительных сетей увидят ускорение.

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

Источник (https://www.zdnet.com/article/linux-6-16-brings-faster-file-systems-improved-confidential-memory-support-and-more-rust-support/)

Как устроен livepatch-модуль для ядра Linux

С точки зрения пользователя (в данном случае человека, отвечающего за обновления данной Linux-системы) лайвпатч — это просто модуль ядра Linux, в котором содержится как минимум следующее: 

• исправленный код одной или более функций из vmlinux и/или из модулей ядра,

• метаданные, указывающие, как применить эти исправления к соответствующим компонентам ядра Linux. 

Чтобы применить лайвпатч-обновление, нужно загрузить этот модуль ядра, например, с помощью insmod или modprobe, а затем активировать его, как правило, через sysfs. 

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

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

Примечания:

• У TuxCare / KernelCare лайвпатчи поставляются в другом, проприетарном, формате, но мы его рассматривать не будем.

• Для некоторых архитектур, например RISC-V, при активации и деактивации патча вызывается stop_machine(), то есть работающие процессы при этом все-таки останавливаются на некоторое время. Начиная с версии 6.16 ядра Linux, для RISC-V stop_machine() уже, вероятно, не будет использоваться в таких ситуациях.

Все, что нужно знать о лайвпатингче для ядра Linux, вы найдете в цикле статей: от подготовки лайвпатча до работы на x86, ARM и RISC-V.

Читать первую часть →

Читать вторую часть →

Как создать простейшую модель GPIO для QEMU

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

Апертура и адресное пространство

Как я упоминал в одной из своих статей, любое MMIO-устройство — это MemoryRegion с заданными шириной доступа и размером. Для того, чтобы он был виден CPU или другому устройству, такому как DMA, его нужно разместить в соответствующем адресном пространстве — например, пространстве, назначенном для cpu0:

      0x0                                    0xffffffffffffffff
      |------|------|------|------|------|------|------|------|
0:    [                    address-space: cpu-memory-0        ]
0:    [                    address-space: memory              ]
                    0x102000           0x1023ff
0:                  [             gpio        ]

В любое время можно посмотреть существующие адресные пространства и регионы памяти в мониторе QEMU:

(qemu) info mtree
[...]
address-space: cpu-memory-0
address-space: memory
  0000000000000000-ffffffffffffffff (prio 0, i/o): system
    0000000000102000-00000000001023ff (prio 0, i/o): gpio
[...]

Тогда в модели устройства нам нужно всего лишь создать такой регион и назначить ему соответствующие функции записи и чтения:

static const MemoryRegionOps mmio_mmio_ops = {
    .read = mmio_gpio_register_read_memory,
    .write = mmio_gpio_register_write_memory,
    .endianness = DEVICE_NATIVE_ENDIAN,
    .valid = {
        .min_access_size = 4,
        .max_access_size = 4,
    },
};
 
[...]
memory_region_init_io(iomem, obj, &mmio_mmio_ops, s,
                      "gpio", APERTURE_SIZE);
[...]

Фактически это означает, что все семейство инструкций Load/Store будет вызывать mmio_gpio_register_read_memory()/mmio_gpio_register_write_memory() при совпадении адреса чтения/записи с адресом региона в адресном пространстве.

static uint64_t mmio_gpio_register_read_memory(void *opaque, hwaddr addr, unsigned size);
static void mmio_gpio_register_write_memory(void *opaque, hwaddr addr, uint64_t value, unsigned size);

Передаваемые аргументы и возвращаемое значения интуитивно понятны. Отмечу, что hwaddr addr — это адрес относительно начала нашего региона, а не абсолютный адрес.

Нам остается лишь создать устройство и добавить его регион в файле машины:

gpio = qdev_new(TYPE_MMIO_GPIO);
sysbus_mmio_map(SYS_BUS_DEVICE(gpio), 0, ADDRESS);

Почти десять лет назад Никита Шубин, ведущий инженер по разработке СнК в YADRO, сделал возможность чтения и записи GPIO для QEMU. Читайте первую часть трилогии о долгом пути до GPIO в QEMU.

Представлена игра 2048 на Bash в терминале с 64 битами состояния.

«Поделитесь своим игровым состоянием с друзьями, просто отправив им число! Если переменная $STATE env не установлена, она генерирует новое случайное начальное число. В противном случае состояние доски и все будущие созданные ячейки будут детерминированными»,‑ пояснил автор проекта.

Американский программист и специалист по внутреннему устройству операционной системы Windows Марк Руссинович выложил на личном аккаунте LinkedIn себяшку с Биллом Гейтсом и Линусом Торвальдсом. Также в этой неформальной встрече участвовал не менее легендарный инженер-программист Дэйв Катлер. Как пишет Руссинович, Билл и Линус никогда до этого не встречались.

Это действительно так. Известно, что они могли пересекаться: 20 апреля 1999 года во время выставки COMDEX Гейтс выступал в главном зале, а через полчаса Торвальдс зачитал свою речь в аудитории поменьше. Однако они лишь были двумя спикерами. Нет никаких подтверждений, фотографий или свидетельств очевидцев, что они обмолвились хоть словом, поздоровались издалека или пожали друг другу руки.

В девяностых Торвальдса часто представляли в СМИ в качестве Билла Гейтса, но от мира контркультуры. Линус действительно избегал корпоративных ролей и даже отказался от личного предложения Стива Джобса о найме. Среди требований было отойти от разработки Linux, поэтому Линус не перешёл на работу в Apple. К тому же ядро Mac OS финну не нравилось.

Нельзя сказать, что эта встреча что-то может значить. Microsoft рассматривала операционные системы на базе ядра Linux как угрозу своему доминированию на рынке, но в последние годы даже помогает пользователям запускать Unix-приложения на своей Windows. Сам Билл Гейтс после 2008 года не занимается Microsoft, посвящая себя филантропии, бизнесу и политике.

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

Хэндлим обработку некорректного ввода в ZSH для поднятия настроения

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

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

А что, если мы хотим, чтобы на ввод любой несуществующей команды, мы получали что-то аналогичное выводу команды sl? По умолчанию в ZSH в этом случае выводится сообщение “command not found”. Давайте это исправим.

Для этого нам понадобится:

• непосредственно zsh в качестве командной оболочки;

• cowsay - утилита командной строки, которая рисует разные фигурки, которые как бы говорят, наподобие героям комиксов.

• lolcat - утилита для разукрашивания текста градиентом, добавления анимации и т.д.

В ZSH предусмотрена возможность переопределять поведение при возникновении каких-то ситуаций, в том числе, переопределение поведения при возникновении ошибок. В нашем случае нам нужно переопределить вывод, когда команда, вводимая пользователем не найдена. Для этого будем использовать метод command_not_found_handler. Добавим в .zshrc файл следующий код:

command_not_found_handler() {    
  cowsay -f tux "LOL! Command not found: $1" | lolcat -a -s 150
  return 127
}

Немного пояснений: первая строка будет рисовать там пингвина, говорящего, что введенная нами команда не найдена, пингвин будет появляться построчно (150 - скорость появления). Более подробно с доступными параметрами lolcat можно ознакомиться, набрав man lolcat. 127 - это код, который zsh отправляет по умолчанию, сохраним это поведение.

Вот так примерно это выглядит:

Ну вот, собственно говоря, и все. Мелкие моменты, которые нас окружают в повседневности, делают нас (по крайней мере меня) чуточку счастливее :)

РТУ МИРЭА совместно с АО «НИЦ» и «РУСИБ» приглашает всех, интересующихся Инфобезом, с 7 апреля по 8 июня принять участие в гибридном хакатоне NeedForFWSpeed на самое быстрое ПО межсетевого экрана и побороться за призовой фонд 0,6 млн рублей.

По просьбам интересующихся хакатоном, организаторы NeedForFWSpeed продлили регистрацию на мероприятие до 31 мая включительно. Если Вас заинтересует этот хакатон, то ещё есть возможность успеть в последний вагон. Пост с краткой информацией размещен здесь. Ниже ссылка на сам сайт хакатона.

Инженерной боли пост. С надеждой на дельные советы

Все началось с pet-проекта, который использовал polars(сорцы) и должен был крутиться в Docker на моем домашнем NAS, в следующей конфигурации:

• CPU arm/v7 32-bit, Annapurna Labs Alpine AL314 Quad-core ARM Cortex-A15

• 4Гб RAM

• ОС QNAP QTS на linux ядре 4.2.8 с увеличенным до 32k размером страницы памяти, и с официальной поддержкой Docker

Спойлер: принципиальное решение проблемы - найдено. Купил маленькую коробочку на "мейнстримной" архитектуре, на которой все цветет и пахнет.. кроме моего внутреннего(ну и внешнего, че уж там) инженера) Так что решение выкинуть железку - можно не предлагать

Так вот, пока я писал код, и готовил сборочные скрипты ничто не предвещало беды - я спокойно потестил код локально, написал Dockerfile для сборки на poetry. Настало время развернуть это все на NAS - казалось бы ARM уже давно мейнстрим, но тут понеслось

1. python как всегда лишь удобный биндинг к куче платформозависимого кода) подавляющее большинство python-зависимостей под arm/v7 приходится компилировать

2. готовых бинарников polars под arm/v7 - тоже нет

3. Никаких блокеров к тому, чтобы собрать polars под arm/v7 я не нашел. Но скомпилить его нативно на 4Гб ОЗУ - не получится, даже с минимальными оптимизациями. Нужна кросс-компиляция. Благо с rust и maturin(которым собирается polars) - это несложно, target armv7-unknown-linux-gnueabihf в хорошем tier-е поддержки

4. забегая чуть вперед указываем окружение для сборки аллокатора jemalloc(по умолчанию в polars) под 32k страницу

Итак, усложняем сборку Docker(см. repro) - используем кросс-компиляцию, энв-переменные, QEMU, охапку дров и теперь у нас есть приложка, которая успешно стартует в докере на целевой железке. Вот только за рамками самых примитивных тестов - OOM-ится, причем память точно есть, никакой OOM-киллер процесс не убивает(на всякий случай смотрим лимиты cgoup) - оно "шамо":

memory allocation of 1345920 bytes failed

(подробные логи можно посмотреть по ссылкам в конце поста)

Что же делать?

1. пробуем mimalloc - он использует для конфигурации рантайм(getconf), эффект - тот же

2. пробуем env-крутилки, в частности arena_reserve может стоит просто меньше резервировать - но нет, просто больше попыток, но по факту все равно OOM

3. помимо jemalloc и mimalloc не работают также: стандартный аллокатор rust(чем бы он ни был), libc-аллокатор и версия mimalloc, установленного как системная библиотека

И вот на этом месте я застрял. Я не большой спец по системному программированию - не понимаю куда копать

• Общение с поддержкой QNAP свелось к

  

• Пытался отлаживать приложение в gdb - никаких аномальных трейсбэков во время OOM не увидел: rust честно пытается аллоцировать большой raw_vec(трейс есть в вопросе на stackoverflow)

• Как-то глубоко копать переменные не получается, т.к. дебаг-символы для бинарника polars получаются слишком большими

  BFD: error: /app/.venv/lib/python3.12/site-packages/polars/polars.abi3.so(.debug_str) is too large (0x498a9fd1 bytes)

• Я сделал небольшое repro на голом расте - там эта проблема не воспроизводится, значит базово бинарная совместимость - в порядке

• Есть несколько гипотез, но я не знаю как их проверить

  • возможно, кривая вся адресация, но ее проверить я тоже не могу

  • возможно, стоит чего-нибудь половить в ядре bpf-ом, но что..

  • кастомное ядро 4.2.8 кастомный дистриб(QTS) не богат средствами отладки - как я понял там запускается busybox набор утилит

В итоге я завел

• вопрос на stackoverflow - там есть логи аллокатора и трейсбэк

• ишью в репозитории mimalloc

• repro-проект с минимальным примером на котором проблема воспроизводится

Но активности там не очень много(

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

Пишите в комментах ваши соображения. Если что-то удастся прояснить - буду держать читателей поста в курсе

Isar и еще 8 систем сборки для создания дистрибутива на Linux

Isar — система сборки, представляющая собой набор скриптов для создания пакетов и дистрибутивов на базе Debian с возможностью настройки. Организация проекта Isar похожа на Yocto Project, для сборки используется Bitbake.

Перед сборкой можно настроить параметры файловой системы, ядра, модификации списка пакетов (добавление и удаление пакетов, в том числе и собственных, изменение существующих пакетов). Систему сборки разрабатывает компания ilbers GmbH.

Архитектура системы

Так как Isar основан на Bitbake, архитектура решения состоит лишь в нескольких слоях для Bitbake, реализующих сборку и установку пакетов в соответствии с конфигурацией сборки. В основе всех этих слоев и рецептов лежат утилиты Debian Build Toolchain, которые ответственны за непосредственную сборку пакетов, разрешение зависимостей и т.д.

Особенности решения

• Аналогично Yocto требует усилий на начальных этапах для освоения инструмента.

• Поддерживает загрузку готовых пакетов из репозиториев Debian.

• Подходит для embedded-дистрибутивов, где необходимо сочетание Debian-экосистемы и глубокой конфигурации.

О других embedded- и desktop-решениях решениях рассказали студенты и преподаватели СПБГЭТУ «ЛЭТИ» в обзоре систем для создания Linux-дистрибутивов.  

Объявлено решении включить в состав выпуска GNOME 49 видеопроигрыватель Showtime, который станет поставляться под именем GNOME Video Player и будет задействован по умолчанию вместо видеопроигрывателя Totem (GNOME Videos).

Для желающих протестировать Showtime не дожидаясь осеннего релиза GNOME 49 подготовлен пакет в формате flatpak. Программа отличается минималистичным интерфейсом, отображаемым поверх содержимого и скрываемым во время просмотра. Поддерживаются типовые элементы управления, полноэкранный режим, изменение скорости воспроизведения, показ субтитров и создание скриншотов.

Как вы поняли, этот пост на Хабре начался со смелого заявления. Конкретно в данном случае я не хотел бы раскладывать по полкам абсолютно все навыки, которые нужны Unix-программисту для успешной работы. Их можно получить простым запросом в поисковике или к любому чат-боту типа ChatGPT, DeepSeek и т.д. (на ваш вкус и цвет)

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

Итак, навыки, правила, они же житейские мудрости, они же грабли, на которые наступал.

1. Сначала править конфиги и только потом - код. Это база

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

Сначала проверь конфигурацию и все её возможные варианты! Если все эти варианты исчерпаны, то только тогда, в последнюю очередь смотри в код!

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

2. Владеть инструментами командной строки

Логично, но не очевидно на первый взгляд. В отличие от обычного программиста (в сферическом вакууме), когда ты можешь ограничиться пошаговой отладкой или логами, Unix-программист должен уметь работать с командной строкой. Хоть и не обязательно знать все команды и их опции "на зубок", но нужно понимать, для каких случаев какие утилиты полезны.

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

Например:

- при невозможности пошаговой отладки использовать perf, чтобы проанализировать стек вызовов

- уметь пользоваться grep'ом для поиска и выделения нужной информации из конкретных файлов

- использовать sed для формирования файлов без лишней информации (например в логах убирать строки с наличием отметок времени)

3. Уметь работать с виртуальными машинами, докером, анализаторами трафика

Например, не плодить виртуалки, а делать снэпшоты (вы скажете: "Спасибо, капитан-очевидность!", но я видел на своей практике тех, кто, не зная про снэпшоты, плодил виртуалки). Держать мастер-копии виртуалок с предварительно настроенной конфигурацией для быстрого развертывания новых машин. Понимать, для каких целей проще использовать докер-контейнер и т.д.

4. Работать с огромным количеством открытых одновременно утилит

Как ни странно, я встречал разработчиков, которые задавали вопрос: "Зачем так много всего?"

Ответ прост: когда непонятно поведение программы, нужно принимать во внимание всё.

Резюме: с таким набором навыков в какой-то момент начинаешь себя чувствовать, как оператор из Матрицы.

А какие особенности в Unix-разработке (и не только) подметили вы?

РТУ МИРЭА совместно с АО НИЦ и Ассоциацией РУСИБ приглашает всех, интересующихся Инфобезом, с 7 апреля по 31 мая принять участие в гибридном хакатоне NeedForFWSpeed на самое быстрое ПО межсетевого экрана и побороться за призовой фонд 0,6 млн рублей.

Все конкурсанты будут использовать одинаковые аппаратные платформы и одинаковые датасеты. Так что старт у всех будет с одной линии.

В качестве аппаратной платформы всем предлагается RPi CM4 MilkV с процессором архитектуры RISC V – мы стойкие сторонники OpenSource.

Зато нет никаких ограничений на ПО. Можно взять абсолютно стандартную сборку *nix и пойти с ней. Можно хорошенько пооптимизировать iptables/nftables, сетевые драйверы и настройки IP-стека и получить прирост производительности. В придачу можно поотключать в ОС и всё лишнее, можно собрать свою кастомную сборку и много чего ещё.

Можно взять и операционку полегче, ОС РВ или Нейтрино, и попытаться получить выигрыш за их счёт. Можно вообще написать свой код, взяв за основу исходники IP-стека, так сказать, BareMetal в чистом виде.

По условиям соревнований не важно, сколько человек в команде, один или пять, какой у Вас возраст и образование, какой опыт работы и какой стек технологий – значение имеет только СКОРОСТЬ РАБОТЫ МЕЖСЕТЕВОГО ЭКРАНА. Никаких взвешенных коэффициентов, призов зрительских симпатий и симпатий жюри. От жюри нужно будет одно – подписать итоговый протокол.

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

Все подробности и регистрация на сайте https://securitygc.ru

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

PS ... и да, среди нас есть фанаты ленты Need For Speed, и скорость межсетевого экрана нам тоже очень нужна.

🗓 14.03.1994 - Выпущeн пepвый cтaбильный peлиз Linux 1.0.0 [вехи_истории]

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

Разработчиком ядра Linux является Линус Торвальдс, который начал работу над проектом в 1991 году. Первоначально это был экспериментальный проект, но благодаря поддержке сообщества он быстро развивался. Версия 1.0.0 включала 176 000 строк кода и поддерживала архитектуру x86, работу в многозадачном режиме и сетевые соединения. С тех пор Linux стал основой для множества дистрибутивов и широко применяется в серверах, мобильных устройствах (Android), суперкомпьютерах и встроенных системах.

💙 Интересно? Ставим лайк - и будем готовить историю про Linux)

📼 А знаете ли вы, что в основе Android лежит ядро Linux?
Удивительная история Android! Вы этого НЕ ЗНАЛИ
YouTube | VkVideo

Хабр, привет!

Приглашаем на митап о карьере в Linux🐧.

19 марта эксперты компании и приглашенный гость — блогер Константин Дипеж (DeusOps) — обсудят профессиональный путь Linux-специалиста.

— как безболезненно «вкатиться» в Linux

— с чем откликаться на вакансию

— какие вопросы задают на техническом интервью

— как расти профессионально после оффера

— как развиваться в DevOps и не только

Приглашаем Linux-специалистов, которые видят зоны роста и хотят выйти на новый уровень профессиональной экспертизы

Во время дискуссии можно будет задать вопросы спикерам. За лучшие – обещаем мерч;)

Встреча пройдет онлайн, 19 марта в 18:00 (мск). Подробности и регистрация на сайте.

Хочу поделиться своим максимально ненужным проектом на Python, под названием flexpasm.

Это билдер кода для FASM под Linux. Работает ограниченно, но вроде-бы работает.

Проект, лично для меня, интересный.

Установить эту библиотеку можно через PyPi:

from flexpasm import ASMProgram
from flexpasm.constants import LinuxInterrupts
from flexpasm.instructions.registers import get_registers
from flexpasm.instructions.segments import Label
from flexpasm.mnemonics import IntMnemonic, MovMnemonic, XorMnemonic
from flexpasm.settings import Settings


def main():
    settings = Settings(
        title="Example ASM Program",
        author="alexeev-prog",
        filename="example.asm",
        mode="64",
    )
    asmprogram = ASMProgram(settings, __name__)
    regs = get_registers(settings.mode)

    start_lbl = Label("start")

    start_lbl.add_instruction(MovMnemonic(regs.AX, 4))
    start_lbl.add_instruction(MovMnemonic(regs.CX, "message"))
    start_lbl.add_instruction(MovMnemonic(regs.DX, "message_size"))
    start_lbl.add_instruction(IntMnemonic(LinuxInterrupts.SYSCALL))
    start_lbl.add_instruction(MovMnemonic(regs.AX, 1))
    start_lbl.add_instruction(XorMnemonic(regs.BX, regs.BX))
    start_lbl.add_instruction(IntMnemonic(LinuxInterrupts.SYSCALL))

    asmprogram.add_label(start_lbl)
    asmprogram.main_rws.add_string("message", "Hello, World!")

    asmprogram.save_code()
    # asmprogram.restore_backup()


if __name__ == "__main__":
    main()

$ fasm example.asm example
$ ld example -o example
$ ./example

Hello, World!

А сам код генерируется такой:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Author: alexeev-prog                                                                                               ;;
;; Example ASM Program                                                                                                ;;
;; Program generated by FLEXPASM (github.com/alexeev-pro/flexpasm)                                                    ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

format ELF64 executable 3;                      ; ELF64 EXECUTABLE
entry start                                     ; Set Start Entry


;; Segment readable executable in FASM is a directive for defining a section of code with readable and executable attributes.
segment readable executable

start:                                          ; Label start with 7 commands
    MOV RAX, 4                                      ; Loading 4 value into RAX register.
    MOV RCX, message                                ; Loading message value into RCX register.
    MOV RDX, message_size                           ; Loading message_size value into RDX register.
    INT 128                                         ; Call software interrupt 128: SYSCALL
    MOV RAX, 1                                      ; Loading 1 value into RAX register.
    MOV RBX, RBX                                    ; Exclusive OR operation RBX and RBX using XOR
    INT 128                                         ; Call software interrupt 128: SYSCALL


;; Segment readable writeable in FASM is a definition of a segment of program data codes, where the attributes readable (the contents of the segment can be read) and writeable (program commands can both read codes and change their values) are specified for it.
segment readable writeable

message db 'Hello, World!', 0xA                 ; Var message (string)
message_size = $-message                        ; Var message (string) length

Я его написал довольно давно, вот решил поделиться. Может кому-то пригодится. Если есть баги - создавайте PR и Issue, буду рад)

github.com/alexeev-prog/flexpasm

Работаю в большом проекте состоящем из более чем сотни динамически подгружаемых библиотек. OracleLinux, QtCreator, Qt, C++. Испытывал большие неудобства при загрузке приложения в режиме отладки с большим количеством точек останова (на 10 штуках старт с 30 секунд увеличивался до 2 минут). Казалось бы очевидное, но закономерность замедления обнаружилась не сразу.

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

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

Возможно, я озвучил очевидность. Но мне, работая в данном окружении и в большой команде достаточно давно, это озарение снизошло не сразу. Я и не сильно боролся с этим до недавних пор, сильное замедление произошло не так давно при переходе с Qt4 на Qt5 (у нас вынужденное legacy).

Разработчик под ником madprops предложил способ для быстрого поиска команд в терминале

«Я очень часто обращаюсь к истории действий в shell, чтобы снова и снова запускать одни и те же команды. Пока нет эффективного способа сделать это. Я думаю, что это проблема, которую нужно решать с помощью специализированного инструмента. Я могу попробовать сделать инъекцию оболочки с помощью rofi позже. Но сейчас я придумал трюк, который помогает в работе. Добавьте значки к командам, чтобы вы могли мгновенно распознавать их по стрелкам вверх:

• : ✅;./utils/check.sh

• : ⚡;./scripts/tag.py

• : 📚;./scripts/makedocs.sh

Обратите внимание на двоеточия и точки с запятой. Значки не являются частью команды, они ничего не делают. Но теперь ваше зрение очень быстро распознает нужный элемент. Вместо иконок можно использовать текст, который можно легко отфильтровать позже», — пояснил madprops.

Учимся в сетевые интерфейсы на Linux: руководство по netlink

В интернете я нашел всего одну статью, где описывали мониторинг сетевых портов. Это был хороший старт, но для решения моей задачи информации оказалось недостаточно. Уже во время написания этой статьи я нашел еще пару материалов, которые, как я рассчитываю, хорошо дополнят мой. Помимо статей, нашел несколько man-страниц, в которых описаны пакеты, параметры, структуры и даже есть примеры кода. Оттуда я взял готовый код, способный получать информацию о появлении нового интерфейса и добавлении его в vlan. Но задача требовала отслеживать намного больше параметров системы.

Следующая остановка — пакет iproute2. Iproute распространяется под GNU GPL 2, так что я скачал исходники, собрал их и начал разбираться в коде на C. Чтобы проще понимать логику, я удалял некоторые участки кода, в которые при вызове моей функции программа не входила. Затем пересобирал программу и продолжал изучение и трассировку. Так я понял общий принцип обработки пакетов и сделал обработку пары дополнительных параметров. Но оставалось еще много других условий.

В какой-то момент я вспомнил про утилиту strace: с ней стало проще изучать код и ориентироваться в нем. Strace позволяла увидеть финальный этап работы функции и все ее параметры. Решая свои задачи, я копировал и адаптировал код из iproute. Я не особо вникал во внутреннее устройство протокола, но с каждым этапом разработки это становилось все сложнее и сложнее.

Наконец, я сделал обработку всех параметров кроме одного. В функции его обработки в iproute вызывалась обработка какого-то системного файла, и это было очень странно, так как я видел этот параметр в сообщении netlink через strace. Я зашел в тупик. Код выглядел очень страшно и совсем не нравился мне. Покопавшись в этом еще один день, я понял, что так продолжаться не может. Я решил переписать все заново без использования кода из iproute. Хотел сделать код красивым и максимально понятным для тех, кто будет читать его после меня.

О том, как с помощью netlink узнать, что именно делает система при настройке сетевых интерфейсов и как обрабатывать ее команды, читайте в статье Тимура Аммаева.

Как и зачем дублировать 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 в статье →

Праздничный unixporn: python vim ide в контейнере

В разработке на python, особенно в DS/ML проектах, мы все сталкиваемся со сложной схемой зависимостей на специфичной аппаратной платформе. Зачастую, вести разработку удобно в том окружении, в котором в последствии запускается приложение.

Если вы вдруг vim user, то можно просто доставить редактор в контейнер с окружением и разрабатывать прямо там. Такая схема достаточно лекговесна, позволяет относительно просто держать актуальными завистимости при разработке, переиспользовать существующие сборочные конвейеры с небольшим наборов слоёв для самого редактора. Так же это может быть удобно, если вам нужно работать где то на удалённом кластере по ssh.

У меня был некоторый шаблон Dockerfile с добавкой vim с плагинами который кочует из проекта в проект и я решил поделиться с вами этой наработкой.

С Новым годом!