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

С чего все началось

Итак, в нашем замечательном приборе Беркут-ММТ (на базе PXA320 и GNU/Linux) есть не менее замечательный модуль OTDR (на базе STM32 и NutOS), представляющий собой импульсный оптический рефлектометр. Эта связка работает следующим образом: пользователь нажимает на экране на различные элементы UI, в приборе происходит немножечко магии, и желания пользователя трансформируются в команды вида «duration 300», которые уходят в измерительный модуль. Конкретно эта команда выставляет длительность измерений в 300 секунд. Модуль к прибору подключен по USB, для передачи команд поверх USB поднят CDC-ACM.

Кратенько — CDC-ACM позволяет эмулировать последовательный порт через USB. Так что для верхнего уровня наш измерительный модуль в системе доступен как /dev/ttyACM0. CDC-ACM служит для передачи команд в модуль или чтения текущих настроек/состояния модуля. Для передачи самой рефлектограммы служил USB Bulk интерфейс, который все свое время посвящал только одному — передаче данных рефлектограммы из модуля в прибор, как бинарного потока данных. В какой-то момент мы заметили, что рефлектограмма приходит к нам не полностью. Так мы открыли для себя, что USB может терять данные.

Однажды появилась такая необходимость обновить версии темплейтов OpenVZ загруженных в кэш Proxmox'а.

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

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

Итак, есть желание и пора приступать к его осуществлению. Для начала решим, что же конкретно должен делать наш скрипт.

Вторая часть

С чего всё начиналось

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

Но проблема в том, что для нас даже 1% брака недопустим: на каждый случай у тех поддержки и разработчиков уходило очень много времени на клиента. Да и для всех нас это недопустимо чисто из соображений профессиональной гордости. Мы хотели такой шлюз снять с производства, даже несмотря на то, что у нас была доля от каждого изделия. Это очень стыдно, когда дилеры про остальные изделия говорят: «у вас вообще брак бывает?», а про наши «мы боимся их продавать — у нас же потом ничего не купят».

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



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

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

Данный материал представляет собой перевод блог поста, который в реальном времени ведут ребята из Sourcegraph с конференции GopherCon 2015, которая проходит в эти дни в Денвере, Колорадо. Полное видео и слайды доклада будут добавлены к посту, как только будут доступны.

Ричард Л. Хадсон (Рик) знаменит по своим работам в управлении памятью, включая изобретение алгоритмов Train, Sapphire и Mississippi Delta, а так же GC stack maps, которые позволили реализовать сборку мусора в статически-типизированных языках вроде Java, C# и Go. Под его авторством были опубликованы документы о рантаймах языков, управлении памятью, многопоточности, синхронизации, моделей памяти и транзакционной памяти. Сейчас Рик является одним из членов команды Go в Google и работает над проблемами сборщика мусора и рантайма.

В последней части цикла я постараюсь рассказать о новшествах стандарта UEFI 2.5, первые реализации которого должны появиться примерно через полгода на новых платах с процессорами Intel Skylake и AMD R-Series. В первой и второй частях речь шла о более низкоуровневых (и потому менее интересных неспециалистам) стандартах PI 1.4 и ACPI 6.0, здесь же поговорим об изменениях, напрямую влияющих на работу ОС и возможности загрузки по сети. Если вы хотите узнать, что нового в UEFI 2.5, почему PXE уходит в прошлое и зачем UEFI поддержка WiFi и Bluetooth — искренне прошу под кат.

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

Наша компания участвует в открытых проектах с 2005 года – и благодаря разработке собственных open source решений (проекты OpenVZ, CRIU), участвуя в других открытых проектах (QEMU, OpenStack, libvirt, libcontainer, и т.д.). За 10 лет мы собрали несколько наиболее распространённых мифов об открытом программном обеспечении. Я расскажу про каждое из заблуждений и объясню, почему оно ошибочно. Наверняка, вы вспомните еще столько же, но, на мой взгляд, эти пять самые «адовые».

Человек, имеющий одни часы, твердо знает, который час. Человек, имеющий несколько часов, ни в чём не уверен.
Закон Сегала

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

1. Определять относительный порядок событий. Для этого используются часы, измеряющие время от «начала времён», «эпохи» или какого-то иного фиксированного события в прошлом.
2. Измерять длительность процессов. Для этого используются секундомеры, таймеры.
3. Не пропустить важное событие в будущем. Для этого нужны будильники.

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

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

При использовании такого конфигуратора вы существенно упрощаете начальный этап программирования, но делаете это не в ущерб пониманию процессов, происходящих на кристалле.
Ниже приведен пример использования конфигуратора для микроконтроллера C8051F930 от Silicon Labs. Будем управлять яркостью светодиода с потенциомера, написав руками всего две строчки кода. Just for fun, конечно.

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

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

Последние пару лет я пишу под ядро Linux и часто вижу, как люди страдают от незнания давнишних, общепринятых и (почти) удобных инструментов. Например, как-то раз мы отлаживали сеть на очередной реинкарнации нашего прибора и пытались понять, что за чудеса происходят с обработкой пакетов. Первым нашим позывом было открыть исходники ядра и вставить в нужные места printk, собрать логи, обработать их каким-нибудь питоном и потом долго думать. Но не зря я читал lwn.net. Я вспомнил, что в ядре есть готовые и прекрасно работающие механизмы трассировки и профилирования ядра: те базовые механизмы, с помощью которых вы сможете собирать какие-то показания из ядра, а затем анализировать их.

Продолжаем знакомство с новыми возможностями недавно вышедших из под пера UEFI Forum стандартов, и если в предыдущей части речь шла о внутреннем стандарте PI, то на этот раз она пойдет об ACPI 6.0 и его отличиях от предыдущей версии 5.1.
Если вам интересно, что именно изменилось за 10 месяцев разработки стандарта, и какими новшествами нас порадуют или огорчат будущие системы с поддержкой ACPI 6.0 — добро пожаловать под кат.

В апреле 2001 Пол Грэм написал статью «Превосходя посредственность» («Beating the averages» — ориг).

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

Секретное оружие

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

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

TL;DR Golang был разработан специально для того, чтобы расцвести в больших проектах, которые пишут большие группы программистов разных уровней, и в мире нет такой группы больше, чем open-source сообщество.

Абсолютно всё в жизни основано на компромиссах — первый закон термодинамики доказывает это, и языки программирования тут не исключение. Компромиссы в Go не уникальны, но именно благодаря их удачному сочетанию, Go и случился. Законы физики также утверждают, что каждое действие порождает противодействие, и, с ростом популярности, также возрастает количество критики в адрес языка, иногда обоснованной, иногда не очень. Позвольте мне объяснить, почему я считаю, что эта критика не важна, и Go обречён на успех несмотря ни на что.

Приветствую, %username%.

Перед вами вторая статья из цикла о разработке ОС на Go + asm.

Part 0x00
Part 0x01

Изначально я планировал, что вторая статья будет про обработку прерываний, но Go накладывает свои корректировки — сейчас будет описано простое выделение памяти и часть рантайма Go, которая нам пригодится, но будет переписано. На самом деле это подготовка к третьей статье — куче и допиливанию рантайма.

Кода к этой статье на гитхабе не будет (забыл вовремя сделать коммит, а теперь банально лень специально восстанавливать, если кто пришлет пулл реквест — буду благодарен).

Слабонервным просьба закрыть статью — все, что может быть написанно на Go будет написанно на нем!

by Niklaus Wirth
Professor (retired)
Swiss Federal Institute of Technology (ETH)
Zurich, Switzerland

В 1988 году мы с Юргом Гуткнехтом завершили и опубликовали язык программирования Оберон [1, 2], который являлся преемником двух других языков, Паскаля и Модулы-2, разработанных мной ранее. Язык Оберон был спроектирован нами изначально как более рациональный и эффективный, чем Модула-2, что облегчило студентам академической системы образования освоение компьютерной науки. Не останавливаясь на достигнутом, в 1990 году мы построили современную операционную систему (ОС) Оберон для рабочих станций, использующую окна и возможности для обработки текстов. Затем мы опубликовали книгу, раскрывающую детали как компилятора Оберона, так и одноимённой ОС. Книга, названная «Проект Оберон», включала в себя исходные тексты системы.

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

Всем привет.
В этой статье я расскажу, как мы делали sip-телефон на базе stm32f4-discovery с помощью своей встраиваемой ОС Embox. Характеристики stm32f4-discovery (144MHz, 192Kb RAM, 1Mb ROM) могут вызывать сомнения о возможности такой реализации. Нам самим было интересно, получится ли? В качестве ответа можно посмотреть видео, а в самой статье — технические подробности.

Доброго времени суток %username%.

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

Как некоторым известно, я очень люблю язык Go ну, и решил попробовать написать на нем. Что из этого получилось — под хабракатом.

Part 0x00
Part 0x01

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