Команда разработчиков Rust рада сообщить о выпуске новой версии Rust, 1.33.0. Rust — это язык программирования, который дает возможность каждому создавать надежное и эффективное программное обеспечение.

Если у вас установлена предыдущая версия Rust с помощью rustup, то для обновления Rust до версии 1.33.0 вам достаточно выполнить:

$ rustup update stable

Если у вас еще не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта. С подробными примечаниями к выпуску Rust 1.33.0 можно ознакомиться на GitHub.

Что вошло в стабильную версию 1.33.0

Основные улучшения этого выпуска: значительное расширение возможностей const fn и стабилизация нового Pin API.

Расширение возможностей const fn

const fn теперь умеет гораздо больше, а именно:

• безусловное (irrefutable) сопоставление с образцом (например, const fn foo((x, y): (u8, u8)) { ... })
• let привязки (например, let x = 1;)
• изменяемые let привязки (например, let mut x = 1;)
• выражения присваивания (например x = y) и операторов присваивания (например, x += y), включая присваивание проекциям (например, полю структуры или результату оператора индексирования — x[3] = 42)
• инструкции выражений (expression statements) (например, 3;)

На написание данной статьи меня побудила длинная ветка комментариев (дискуссией это я назвать, к сожалению, не могу) к моей недавней статье “Многообразный мир embedded systems и место Embox в нем”. Меня в нескольких местах упрекнули в том, что я путаю RTOS и Embedded OS, что я назвал LynxOS, QNX и VxWorks не RTOS, хотя на мой взгляд, я такого, конечно, не делал. Автору данных комментариев я несколько раз предложил написать статью, в которой бы он изложил свое видение понятия “операционная система реального времени”, но он по каким-то причинам отказался. Ну что же, я изложу свое видение данного термина, и давайте обсудим, что же может называться RTOS, а что не может. В конце концов, этот вопрос часто задают применительно к Embox.

«В режиме трассировки программист видит последовательность выполнения команд и значения переменных на данном шаге выполнения программы, что позволяет легче обнаруживать ошибки» — сообщает нам Википедия. Сами будучи поклонниками Linux, мы регулярно сталкиваемся с вопросом, какими именно инструментами её лучше осуществлять. И хотим поделиться переводом статьи программиста Хонгли Лая, который рекомендует bpftrace. Забегая вперёд, скажу, что заканчивается статья лаконично: «bpftrace — это будущее». Так чем же он так впечатлил коллегу Лая? Развёрнутый ответ под катом.

На Хабре уже писали про перехват системных вызовов с помощью ptrace; Алекса написал про это намного более развёрнутый пост, который я решил перевести.

---

С чего начать

Общение между отлаживаемой программой и отладчиком происходит при помощи сигналов. Это существенно усложняет и без того непростые вещи; ради развлечения можете прочесть раздел BUGS в man ptrace.

Есть как минимум два разных способа начать отладку:

1. ptrace(PTRACE_TRACEME, 0, NULL, NULL) сделает родителя текущего процесса отладчиком для него. Никакого содействия от родителя при этом не требуется; man ненавязчиво советует: «A process probably shouldn't make this request if its parent isn't expecting to trace it.» (Где-нибудь ещё в манах вы видели фразу «probably shouldn't»?) Если у текущего процесса уже был отладчик, то вызов не удастся.
2. ptrace(PTRACE_ATTACH, pid, NULL, NULL) сделает текущий процесс отладчиком для pid. Если у pid уже был отладчик, то вызов не удастся. Отлаживаемому процессу шлётся SIGSTOP, и он не продолжит работу, пока отладчик его не «разморозит».

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

Проекту Embox уже исполнилось 9 лет, но многие не понимают, что это такое и с чем его едят зачем он нужен. Некоторые из тех, кто слышал о проекте и знают, что это операционная система, считают, что Embox — это “отечественная ОС”. Действительно, задумывался Embox как попытка сделать “свою” ОС с “блекджеком и шлюпками”, но главное — это “блэкджек и шлюпки”. То есть, во главу угла ставились некие характеристики или их сочетание, которых не хватало в других проектах.

Конечно, писать универсальную ОС даже с какими-то фишками никто не собирался. Слоган Embox — “Essential toolbox for embedded development” — подразумевает, что проект нацелен на embedded systems. Однако данное понятие очень широко, к нему относят: интернет вещей (IoT) и роботов, различные малинки (RaPi) и бортовые системы, ардуинки и АСУ-ТП, …. Список, как вы понимаете, можно продолжать очень долго, в нем есть места, где прекрасно живет Linux, а есть места, где Linux избыточен и используются различные маленькие RTOS. В данной статье я хотел бы поговорить об embedded-мире во всем его многообразии, ну и о месте Embox в нем.

Продолжаем рассматривать настройку прерываний от внешних устройств в системе x86.
В части 1 (Эволюция контроллеров прерываний) мы рассмотрели теоретические основы контроллеров прерываний и общие термины, в части 2 (Опции загрузки ядра Linux) посмотрели как на практике ОС осуществляет выбор между контроллерами. В этой части мы рассмотрим как BIOS настраивает роутинг IRQ на контроллеры прерываний в чипсете.

Никакие современные компании по разработке BIOS (AwardBIOS/AMIBIOS/Insyde) не раскрывают исходники своих программ. Но к счастью есть Coreboot — проект по замене проприетарного BIOS на свободное программное обеспечение. В его коде мы и посмотрим, как настраивается роутинг прерываний в чипсете.

Недавно внимание автора привлекла статья на LWN о новом интерфейсе ядра для опроса (polling). В ней обсуждается новый механизм опроса в Linux AIO API (интерфейс для асинхронной работы с файлами), который добавили в ядро версии 4.18. Идея довольно интересная: автор патча предлагает использовать Linux AIO API для работы с сетью.

Но постойте! Ведь Linux AIO был создан для работы с асинхронным вводом-выводом с диска / на диск! Файлы на диске — это не то же самое, что сетевые соединения. Возможно ли вообще использовать Linux AIO API для работы с сетью?

Оказывается, да, возможно! В этой статье объясняется, как использовать сильные стороны Linux AIO API для создания более быстрых и лучших сетевых серверов.

Но давайте начнём с разъяснения, что представляет собой Linux AIO.

Предлагаю вашему вниманию субъективную подборку ржавых новостей за январь. В этой подборке: Rust 1.32, уход Стива Клабника и Ника Камерона, киш от Cloudflare, устройство rust-analyzer и страничной памяти, поиски GUI и async, Oxydyze конференция для встроенщиков.

Rust 1.32

Вышел Rust 1.32. По сравнению с масштабным прошлым выпуском, на котором было сконцентрировано множество сил всего сообщества, тут серьезных нововведений не очень много:

• Новый вспомогательный макрос для отладки dbg!;
• По умолчанию убран jemalloc.
• Стабилизированы "единообразные пути" ("uniform paths")

Подробности в переводе новости.

Стив Клабник и Ник Камерон уходят из Mozilla

Печальные новости: Стив Клабник и Ник "nrc" Камерон покидают Мозиллу.

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

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

Введение

Из прошлой статьи мы узнали о принципах страничной организации памяти и о том, как работают четырёхуровневые страничные таблицы на x86_64. Мы также обнаружили, что загрузчик уже настроил иерархию таблиц страниц для нашего ядра, поэтому ядро работает на виртуальных адресах. Это повышает безопасность, но возникает проблема: как получить доступ к настоящим физическим адресам, которые хранятся в записях таблицы страниц или регистре CR3?

Эквивалентен ли по производительности код, представленный ниже?

// (A). Вызов HasPrefix будет встроен.
return strings.HasPrefix(s, "#")
// (B). Ручное встраивание тела HasPrefix.
return len(s) >= len("#") && s[:len("#")] == "#"

Ответ: нет.

За подробностями и объяснениями прошу под кат.

Согласно Википедии, трагедия — это «форма драмы, основанная на человеческих страданиях, которая вызывает в аудитории сопутствующий катарсис или удовольствие». Из этого определения почерпнул вдохновение Бенно Райс в своём выступлении на конференции 2019 linux.conf.au. Его доклад посвящён истории systemd, в которой немало страданий. А аудитория точно получила удовольствие, так что всё сходится. В целом, это сочувственный и тонкий взгляд на одну бурную главу в истории системы Linux.

Райса также вдохновила статья Ауринна Шоу о так называемой «культуре презрения». По словам Шоу, люди проявляют презрение (например, к разработчикам, которые используют другой язык программирования) в качестве социального знака, способа показать, что они принадлежат к правильной группе.

Безусловно, в этой истории есть такая культура: большие группы сообща проявляют общее презрения к systemd и к тем, кто использует эту систему. Отсюда вытекает концепция изменения или сопротивления. Да, знакомые вещи удобны. Но они не обязательно хороши, особенно если ничего не меняется уже много лет.

Введение

В прошлой статье («Часть 2: Использование блоков UDB контроллеров PSoC фирмы Cypress для уменьшения числа прерываний в 3D-принтере») я отметил один очень интересный факт: если автомат в UDB изымал данные из FIFO слишком быстро, он успевал заметить состояние, что новых данных в FIFO нет, после чего переходил в ложное состояние Idle. Разумеется, меня заинтересовал этот факт. Вскрывшиеся результаты я показал группе знакомых. Один человек ответил, что это всё вполне очевидно, и даже назвал причины. Остальные были удивлены не менее, чем я в начале исследований. Так что некоторые специалисты не найдут здесь ничего нового, но неплохо бы донести эту информацию до широкой общественности, чтобы её имели в виду все программисты для микроконтроллеров.

Как-то я прочитал на Хабре статью про настройку BGP на роутере. Инструкции оттуда можно использовать для настройки домашнего роутера так, чтобы трафик на определённые IP-адреса шёл через другой канал. Однако здесь есть проблема: список IP-адресов может быть очень большим.

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

В этой публикации речь пойдет о синтетических модулях и символах отладочного движка Windows (debugger engine). То есть о сущностях, которые можно искусственно добавить в отладчик для раскраски адресов памяти.

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

Задача: проследить, как изменялось переключение контекста в ядре Linux от первой (0.01) до последней версии LTS (4.14.67), с особым акцентом на первую и последнюю версии.

В очередной раз провозившись два дня на написание и отладку всего четырехсот строк кода системной библиотеки, возникла мысль — “как бы хорошо, если бы программы писались менее болезненным способом”.

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

Конечно же, надо изобрести новый, самый лучший ЯП!
Нет, сначала попробуем выразить свои пожелания и посмотреть на то, что уже наизобретали.

И снова я несколько переоценил объем статьи! Планировал, что это будет заключительная статья, где сделаем компилятор и выполним тестирование. Но объем оказался велик, и я решил разбить статью на две.

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

Я впервые пишу на Хабре, возможно, получается не всегда все хорошо. На мой взгляд, статьи 2, 3 получились довольно сухими, много кода, мало описания. В этот раз я постараюсь сделать по другому, сосредоточиться на описании самих идей. Ну а код… код, конечно будет! Кто захочет разобраться досконально, такая возможность будет. В многих случаях я помещу код под спойлер. И, конечно, всегда можно заглянуть в полный исходник на гитхабе.

Компилятор продолжим писать некоторое время на ассемблере, но потом перейдем на форт и продолжим писать компилятор на самом себе. Это будет напоминать барона Мюнхаузена, который вытаскивал сам себя за волосы из болота. Но, для начала, я расскажу в общих чертах, как устроен компилятор на форте. Добро пожаловать под кат!

Научная статья опубликована в журнале Communications of the ACM, октябрь 2018, том 61, номер 10, стр. 68−77, doi: 10.1145/3230627

В феврале 2017 года со взлётной площадки «Боинга» в Аризоне поднялся вертолёт с обычным заданием: облёт ближайших холмов. Он летел полностью автономно. Согласно требованиям по технике безопасности Федерального управления авиации США, пилот не прикасался к органам управления. Это был не первый автономный полёт AH-6, которого в компании называют Беспилотной Птичкой (Unmanned Little Bird, ULB). Он так летает уже много лет. Однако на этот раз посреди полёта вертолёт подвергся кибератаке. Бортовой компьютер атаковало вредоносное программное обеспечение видеокамеры, а также вирус, доставленный через заражённую флэшку, которую вставили во время техобслуживания. Атака поставила под угрозу некоторые подсистемы, но не смогла повлиять на безопасную эксплуатацию воздушного судна.

Привет, Хаброжители! Мы уже писали о книге Майкла Керриска «Linux API. Исчерпывающее руководство». Сейчас решили опубликовать отрывок из книги «Управление буферизацией файлового ввода-вывода, осуществляемой в ядре»

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

Перед тем как рассматривать системные вызовы, используемые для управления буферизацией в ядре, будет нелишним рассмотреть несколько относящихся к этому вопросу определений из SUSv3.

Операционные системы (ОС) — обширная тема. На протяжении десятилетий здесь доминировал один подход: Unix. Действительно, большинство современных систем, включая большинство дистрибутивов GNU/Linux, *BSD и macOS, придерживаются архитектуры Unix. (Windows нет, но там почти ничего интересного по этой теме).

В 2000 году Роб Пайк выступил с докладом о том, почему исследования системного ПО не релеванты. Из-за пессимизма или пренебрежения к сообществу он, кажется, полностью проигнорировал жалобы, собранные многими Unix-пользователями в книге The Unix-Haters Handbook (1994). Книга умышленно саркастична, однако указывает на некоторые критические проблемы систем Unix — и они не решены до сих пор.

В 2006 году Элко Доситра опубликовал диссертацию «Полностью функциональная модель развёртывания программного обеспечения», где описан функциональный менеджер пакетов Nix. В 2008 году автор опубликовал NixOS: полностью функциональный дистрибутив Linux. В то время как NixOS повторно использует много свободного ПО для Unix-систем, она настолько отходит от дизайна и философии Unix, что вряд ли её можно назвать «системой Unix».