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

В предыдущей статье я рассмотрел существующие в платформе 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. Здесь небольшая история о том, откуда появилась ошибка и какие проводились исследования по поиску причин её возникновения.

После полугода разработки организация UEFI Forum выложила наконец в открытый доступ документацию по новым стандартам Platform Initialization 1.4, Advanced Configuration and Power Interface 6.0 и Unified Extensible Firmware Interface 2.5, на базе которых сейчас разрабатывается абсолютное большинство прошивок для ПК и серверов.
Обычно между выпуском новых версий стандартов и первыми прошивками на их базе проходит обычно от 4 до 6 месяцев, но уже сейчас можно предсказать с высокой долей вероятности, какие именно новые возможности появятся в UEFI для платформ на базе процессоров Intel Skylake и AMD Falcon Series.
Я решил разделить описание новшеств на 3 части, иначе оно рискует оказаться очень длинным и читать его никто не станет. Если вас интересуют новшества, описанные в стандарте PI 1.4 и мои комментарии к ним — добро пожаловать под кат.

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

Модуль в Оберонах — это не только единица компиляции, загрузки и связывания, это ещё и механизм инкапсуляции. При обращении к сущностям подключенного( импортированного ) модуля, требуется обязательная квалификация этого модуля. Например, если модуль A импортирует модуль B, и использует его переменную v, то обращение к этой переменной должно иметь форму B.v, что снижает количество трудноотcлеживаемых ошибок использования совершенно других сущностей с тем же именем в немодульных языках, зависящих от последовательности подключения файлов и поведения компилятора.

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

Этой обзорной статьёй я открываю серию статей, посвящённых языку Активный Оберон и операционной системе A2, написанной на этом языке.

Итак, встречайте — Активный Оберон

Первая публикация по Активному Оберону появилась в 1997 году, но понятно, что язык и его реализация появились несколько раньше. За эти годы произошло много изменений в языке, переработана среда времени выполнения, написана операционная система A2…