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

Всем привет

В начале февраля, я участвовал в курсах повышения квалификации для преподавателей от Альянса RISC-V. В рамках курса демонстрировался пакет разработчика (development tools) компании Syntacore, который содержит эмулятор QEMU с добавленными ядрами (платформами) . В день, когда мы выступали я успел добавить начальную поддержку одной из этих платформ в Embox и показал, как он запускается на эмуляторе из этого пакета.

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

Архитектура — это всегда баланс между контролем и гибкостью. Микросервисы (MSA) хороши тем, что чётко разделяют логику, дают независимое масштабирование и удобны в отладке. Каждый сервис сам за себя, отвечает за конкретную зону ответственности и общается с другими через API — обычно REST или gRPC. Вроде бы идеальная схема, но со временем возникает проблема: сервисов становится всё больше, а их связи усложняются.

Привет, Хабр! Меня зовут Константин, я работаю в команде файлового доступа в YADRO. Помимо основной работы, я пишу в open source, работаю над несколькими проектами — в том числе над дебаггером BugStalker (BS) на Rust. 

В этой статье речь пойдет о разработке дебаггеров. Расскажу, какие технологии лежат в основе любого популярного отладчика и как с их помощью реализуются точки останова или функции step. Особое внимание уделим нюансам отладки Rust-кода и поддержке Rust в дебаггерах.

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

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

Наша команда системного программирования YADRO продолжает работать с open source-эмулятором QEMU.  В этой статье я расскажу, как и зачем мы создали виртуального двойника Intel NTB Gen3.

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

На каком языке пишут программы для BIOS? Ответ на этот вопрос кажется очевидным: Си и ассемблер. Да, вот так коротко и просто. Существуют и другие инструменты и языки, но так исторически сложилось, что на такой “низкой” глубине выживают только они. В настоящее время здесь доминируют два основных языка, причем с явным перекосом в одну из сторон. В последние годы наблюдается значительный рост популярности языка Rust, который стал серьезным конкурентом одного из фаворитов. Проникнув в ядро Linux, где ранее никому не удавалось потеснить Си, Rust продолжает расширять свое влияние и на другие сферы разработки. Именно с идеи попробовать и сравнить началось мое путешествие по написанию EFI-утилиты на Rust для BIOS.

Компилятор и главный репозиторий: GitHub

Здесь я напишу о своём личном проекте — компиляторе к C-подобному языку. Я не являюсь профессиональным разработчиком, изучал эту тему почти самостоятельно и не читал никакие книги по написанию компиляторов (но читал по операционным системам).

В современном мире данных нагрузка на базы данных стремительно растёт. Когда один сервер перестаёт справляться с объёмом запросов, встаёт вопрос о масштабировании: как эффективно распределить нагрузку, сохранив высокую производительность и доступность?

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

Статья в продолжение темы безопасной разработки на С++ с примером работающего кода. Кратко предыдущие тезисы:

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

А раз текущее состояние С++ не может гарантировать безопасную разработку на уровне стандартов, то выходит, что:

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

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

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

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

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

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

Именно на примере системных вызовов удобно продемонстрировать цепочную загрузку, и на то есть три причины...

«Если бы это двигали только ученые, то всю идею можно было бы класть в гроб и закапывать. Ученые — отличные генераторы идей и кадров, чтобы эти идеи реализовать.

Но как только мы выходим за рамки чистой идеи, и становится нужен минимальный менеджмент ресурсов, все оказывается плохо»

— Александр Нозик @darksnake, директор SPC

Когда мне предстоит начать работу с новым микроконтроллером, я обычно гляжу, а какое у него быстродействие GPIO. Сколько тактов на одну запись уходит по факту. Такая у меня традиция. Было дело, я так выяснил, что китайские клоны STM32 работают с GPIO чуть быстрее, чем оригинал. Для дешёвых контроллеров обычно ничего более интересного такие проверки не выявляют, но традиция есть традиция. Не изменял я ей и при начале освоения CH32x035 на базе RISC-V. И вот для него картинки получились такими интересными, что я решил поделиться ими с общественностью. Не то, чтобы там было что-то революционное, но от привычных мне они точно отличаются.

А ещё я добавлю к ним немного выводов… И нутром чую, что в комментариях мне объяснят, что я понимаю всё неправильно, а на самом деле… Но я буду только рад обоснованным высказываниям. Вместе мы установим истину.

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

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

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

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

Таким образом, возникают, казалось бы, взаимоисключающие и не разрешимые противоречия:

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

Но ключевым моментом в предыдущем абзаце является фраза "казалось бы".

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

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

$ rustup update stable

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

Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать канал beta (rustup default beta) или nightly (rustup default nightly). Пожалуйста, сообщайте обо всех встреченных вами ошибках.

В предыдущей статье я начал разбирать протокол управления блоком питания Fnirsi DPS-150. Там был разобран формат посылки, были выявлены команды и отклики на них, а также сделан черновой анализ внутренностей фирменной программы управления блоком. Детали процесса я обещал показать позже. Вот, эта пора настала. Сегодня мы получим настолько полные таблицы команд и откликов, насколько это требуется для реальной работы.

Осенью мы в YADRO совместно с сообществом FPGA Systems собрали FPGA-энтузиастов сразу в двух городах — Москве и Санкт-Петербурге. Получилось почти 12 часов докладов — по проектированию на FPGA и ASIC, альтернативным HDL, запуску GPU AMD на ПЛИС с RISC-V, искажению времени и другим фантастическим явлениям темам. Самые полезные, по мнению зрителей, — в этом посте.

Мне показалась очень интересной тема открытая в недавней статье

Собрал в одном большом гайде всё, что хотел бы знать, когда изучал язык C

 Во вступлении там написано:

"Очевидный факт: язык C — это основа большого количества современных экосистем программирования. Он обеспечивает фундамент многих операционных систем, базовых библиотек и системных инструментов."

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

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