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

Для начала предыстория:

Некоторое время назад я приобрёл на Ebay б/у ноутбук Lenovo Thinkpad W520. Как известно, W-серия — это очень мощные ноутбуки, железки в которых дадут фору многим более современным машинам. Конечно же, я начал его обустраивать под себя, и, в частности, решил проапгрейдить имеющуюся память всем, что было в наличии, а в наличии было немало: 2 свободные планки DDR3-1600 из старого ноута — 4 и 8 гигабайт. Посмотрев на то, что было установлено продавцом, я обнаружил, что из 3 установленных планок 2 — DDR3-1600, а одна — 1333. Учитывая, что первые две были по 8 гигабайт, а последняя — 2 гигабайта, от неё я и решил избавиться. Рассчитывая получить после апгрейда 8+8+8+4=28 гигабайт DDR3-1600 в рабочем ноуте, я залил всё слюной и всё это быстренько подключил. И получил 28 гигабайт… DDR3-1333. «Что за...», подумал я и полез в гугл.

После непродолжительных поисков я обнаружил, что как официально, так и неофициально W520 поддерживает только DDR3-1333, а владельцы более быстрой памяти зря тратили на неё деньги. Мне стало немного обидно за всех таких владельцев, и я решил попробовать избавиться от этой несправедливости, тем более, что контроллер памяти, нынче, как известно, в процессоре, и установленный в моей модели Intel Core i7 2720QM официально поддерживает DDR3-1600.

Некоторые считают, что современный мир почти не знает Никлауса Вирта и даже не догадывается о его огромном вкладе в мировую компьютерную науку. Кто-то полагает его «отцом Паскаля». Вирта вспоминают не только педагоги в ВУЗах, когда преподают студентам Turbo Pascal, но и коммерческие разработчики, пишущие на Delphi.

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

Предисловие

Недавно мною было замечено, что при просмотре мультикастового IPTV через Wi-Fi часть трафика теряется. После детального изучения проблемы было выяснено, что такое поведение объясняется природой мультикаст-трафика, а именно – MAC-адрес получателя пакета. Он не зависит от получателя и формируется из адреса мультикаст-группы. Соответственно, на такие пакеты претендуют все клиенты, подключенные к беспроводной точке доступа. Вследствие этого нам достается лишь часть пакетов и мы видим обрывистую картинку.

Штатными средствами проблема решается либо созданием отдельной точки доступа для клиента, либо созданием статического маршрута для определенных мультикаст-групп, или же выведением клиента в отдельный VLAN. Вся “сила” таких решений проявится, когда в сети будет несколько IPTV-приставок, желающих посмотреть один и тот же канал, плюс необходимость их в интернете добавит сложность к настройке роутера. Свое решение данной проблемы предлагаю ниже.

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

Итак, давайте разберёмся как это работает.

9-10 июня в Иннополисе пройдет третья конференция OS Day, посвященная созданию операционных систем. Российские производители программного обеспечения и микроэлектроники обсудят возможности организации полного цикла производства и разработки отечественного процессорного оборудования и системного софта.

Тема OS DAY 2016: «Cвоя система — свой процессор» выбрана не случайно. В России разрабатывается множество прикладного и системного ПО, производятся современные микропроцессоры. Тем не менее, вопрос построения полного стека отечественных технологий пока не решён. Российские процессоры, как правило, работают под управлением импортных операционных систем, а отечественное системное ПО требует процессоров зарубежного производства. Даже российские прикладные программы не всегда адаптированы для отечественных дистрибутивов операционных систем.

Организаторы конференции планируют уделить особое внимание вопросам интеграции российских разработок и, в первую очередь, системного ПО и процессоров отечественного производства. Кроме того, впервые на OS DAY ожидаются выступления производителей процессоров, а также доклады о том, какие задачи ставят перед процессорами разработчики прикладных систем и СУБД.

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

Технология Intel ME (или AMT, Active Management Technology) является одним из самых загадочных и мощных элементов современных x86-платформ. Инструмент изначально создавался в качестве решения для удаленного администрирования. Однако он обладает столь мощной функциональностью и настолько неподконтролен пользователям Intel-based устройств, что многие из них хотели бы отключить эту технологию, что сделать не так-то просто.

На прошедшем 17 и 18 мая в Москве форуме Positive Hack Days VI исследователи Positive Technologies Максим Горячий и Марк Ермолов представили несколько техник отключения Intel ME, сопроводив доклад видеодемонстрацией процесса.

Мы рады представить новую версию Rust 1.9. Rust — это системный язык программирования, нацеленный на безопасную работу с памятью, скорость и параллельное выполнение кода.

Как обычно, вы можете установить Rust 1.9 с соответствующей страницы официального сайта, а также ознакомиться с подробным списком изменений в этой версии на GitHub. В этот релиз вошло порядка 1400 патчей.

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

Управляемая размотка стека

Самое большое изменение в Rust 1.9 — стабилизация модуля std::panic, который предоставляет методы остановки процесса размотки стека, запущенного паникой:

Ровно месяц назад Dropbox анонсировал Dropbox Infinite — «революционно новый способ доступа к вашим файлам», как писала компания в корпоративном блоге. В демонстрационном видео показали, что десктопный клиент Dropbox предоставляет прямой доступ к облачному хранилищу файлов на уровне файловой системы, без необходимости запускать браузер. Локальный диск «увеличивается» на размер облачного хранилища, файлы доступны напрямую. Облачное хранилище может быть больше по размеру, чем локальный диск. Сейчас компания раскрыла технические подробности, как работает эта функция.

Сразу после первого анонса эксперты высказали опасения, что Project Infinite откроет доступ в систему посторонним, если они найдут уязвимости в клиенте Dropbox. Собственное расширение ядра от Dropbox станет тогда своеобразным бэкдором в системе.

Итак, вкратце опишу суть проблемы: если вы используете HTTP/2 на базе Nginx и Ubuntu 14.x-, то с 31 мая HTTP/2 в Chrome работать перестанет. Но решить проблему достаточно просто.

В 2012 году Эндрю Мортон был пессимистично настроен в отношении будущего проекта CRIU (Checkpoint and Restore In Userspace), когда принимал первые изменения в Linux ядро для поддержки C/R (Checkpoint/Restore). Идея реализовать функциональность сохранения и восстановления запущенных процессов в пространстве пользователя выглядела сумасшедшей, а спустя 4 года проект не только жив, а всё больше вызывает интерес к себе. До старта проекта CRIU предпринимались попытки реализовать C/R в Linux (DMTCP, BLCR, OpenVZ, CKPT и т.д.), но и все они по разным причинам были обречены на провал в то время как CRIU стал жизнеспособным проектом. К сожалению от этого задача C/R в Linux не стала проще. В этой статье я расскажу об особенностях тестирования CRIU.

^{Мужик приходит устраиваться работать на стройку. Его спрашивает мастер:
— Что делать умеешь?
— Могу копать…
— А что еще?
— Могу не копать…}

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

Неактивным процессор может быть не только для экономии энергии, но и в результате возникновения особых ситуаций, в процессе выполнения протоколов инициализации или как итог намеренных действий системных программ. Почему это интересно? При написании программных моделей (в том числе виртуальных машин) компьютерных систем, необходимо корректно моделировать переходы между состояниями виртуальных процессоров. В работе системных программ регулярно возникают ситуации, когда по тем или иным причинам ЦПУ должен «притормозить». Умение корректно использовать и моделировать эти ситуации зависит от знания и понимания спецификаций.

В статье фокус делается на программной стороне вопроса состояний процессора. Я не буду концентрироваться на деталях реализации (напряжения, пины, частоты и т.д.), так как 1) они существенно различаются между поколениями и моделями процессоров даже одной архитектуры, тогда как программный интерфейс остаётся обратно совместимым; 2) они не видны напрямую программам и ОС. Это попытка просуммировать информацию, разбросанную по многим страницам справочника Intel IA-32 and Intel 64 Software Developer Manual.

Начнём с простой и всем знакомой ситуации — процессор включён, бодр и весел.

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

Для начала введём определение bus master: устройство, способное быть не только ведомым, но и ведущим на шине компьютера. То есть — не только отвечать на транзакции ввода-вывода, инициированные процессором, но и самостоятельно их инициировать — по собственной инициативе «ходить» в память.

История таких устройств уходит корнями в понятие DMA: ещё во времена прародителя микропроцессоров, микропроцессора 8080 (КР5080ИК80), появилось понимание, что процессор хорошо бы разгрузить от рутинной операции перетаскивания байтиков между устройствами в-в и памятью.

Сегодня выходной, так что напишу коротко про мелочи, до которых, как правило, руки не доходят.

TCP FS

Есть ещё одна вещь, которой нет в современном Юниксе и которую я хочу иметь в unix box фантома. Она проста как мычание, и почему её никто не сделал — непостижимо:

#cat /tcp/host/port > local_file

Правда, я хочу использовать иной синтаксис имени файла, URL style — tcp://host:port, но это уже детали. Естественно, наравне с TCP просится UDP, и там вообще проблем нет.



Для TCP есть очевидная проблема — нужен ли нам listen или connect, но её можно решить через указание в имени «файла» определённого суффикса.

Сказать на эту тему настолько больше нечего, что перейдём без остановки к следующей.

TRFS — тривиальная дистанционная файловая система.

Здравствуйте, уважаемые читатели! С наступающими вас праздниками.

В последней апрельской публикации мы хотели бы рассказать вам о замечательной книге Майкла Керриска «Linux Programming Interface», которая в очередной раз вернулась в наше поле зрения благодаря превосходным продажам другой литературы по Linux:



Конечно, сложная книга о системном программировании объемом 1500+ страниц — литература, прямо скажем, на любителя. Но, поскольку отзывы о ней до сих пор восторженные, а нам потратиться на Linux завсегда не жалко предлагаем почитать ее обзор, опубликованный в далеком 2011 году.

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

Эта идея пришла мне в голову очень давно и даже где-то была мной описана. Триггер к тому, чтобы её описать сегодня — обсуждение сетевых драйверов Линукса в комментариях к Анатомии драйвера.

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

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

То есть хотелось бы такого вызова функции, который при необходимости можно конвертировать в старт нити. Но по цене вызова функции, если нить реально не оказалась нужна.

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

Как это.

Опять вернёмся в традиционную область разработки операционных систем (и приложений для микроконтроллеров) — написание драйверов.

Я попробую выделить некоторые общие правила и каноны в этой области. Как всегда — на примере Фантома.

Драйвер — функциональная компонента ОС, ответственная за отношения с определённым подмножеством аппаратуры компьютера.

С лёгкой руки того же Юникса драйвера делятся на блочные и байт-ориентированные. В былые времена классическими примерами были драйвер диска (операции — записать и прочитать сектор диска) и драйвер дисплея (прочитать и записать символ).

В современной реальности, конечно, всё сложнее. Драйвер — типичный инстанс-объект класса, и классов этих до фига и больше. В принципе, интерфейс драйверов пытаются как-то ужать в прокрустово ложе модели read/write, но это самообман. У драйвера сетевой карты есть метод «прочитать MAC-адрес карты» (который, конечно, можно реализовать через properties), а у драйвера USB — целая пачка USB-специфичных операций. Ещё веселее у графических драйверов — какой-нибудь bitblt( startx, starty, destx, desty, xsize, ysize, operation ) — обычное дело.

Цикл жизни драйвера, в целом, может быть описан так:

• Инициализация: драйвер получает ресурсы (но не доступ к своей аппаратуре)
• Поиск аппаратуры: драйвер получает от ядра или находит сам свои аппаратные ресурсы
• Активация — драйвер начинает работу
• Появление/пропадание устройств, если это уместно. См. тот же USB.
• Засыпание/просыпание аппаратуры, если это уместно. В контроллерах часто неиспользуемая аппаратура выключается для экономии.
• Деактивация драйвера — обслуживание запросов прекращается
• Выгрузка драйвера — освобождаются все ресурсы ядра, драйвер не существует.

(Вообще я написал в прошлом году черновик открытой спецификации интерфейса драйвера — см. репозиторий и документ.)

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

• Поллинг
• Прерывания
• Нити (threads)

В прошлый раз мы рассказали об Intel Management Engine (ME) — подсистеме, которая встроена во все современные компьютерные платформы (десктопы, лэптопы, серверы, планшеты) с чипсетами компании Intel. Эта технология многими воспринимается как аппаратная «закладка», и на то есть причины. Достаточно сказать, что Intel ME является единственной средой исполнения, которая:

• работает даже тогда, когда компьютер выключен (но электропитание подаётся);
• имеет доступ ко всему содержимому оперативной памяти компьютера;
• имеет внеполосный доступ к сетевому интерфейсу.

Ошарашенный присутствием такого компонента в компьютере, пользователь (получается, что именно «пользователь», а не «владелец») наверняка задавался вопросом: можно ли выключить Intel ME?

Эта статья целиком посвящена этому вопросу.

Это — статья-вопрос. У меня нет идеального ответа на то, что здесь будет описано. Какой-то есть, но насколько он удачен — неочевидно.

Статья касается одной из концептуальных проблем ОС Фантом, ну или любой другой системы, в которой есть персистентная и «волатильная» составляющие.

Для понимания сути проблемы стоит прочесть одну из предыдущих статей — про персистентную оперативную память.

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

В процессе работы над ОС Фантом, которая вообще не Юникс никаким местом, мне, тем не менее, захотелось сделать в нём Unix-compatible подсистему. Не то, чтобы прямо POSIX, но что-то достаточно близкое. Отчасти из любопытства, отчасти для удобства, отчасти как ещё один migration path. (Ну и вообще было интересно, насколько трудно написать простенький Юникс «из головы».) В качестве цели номер 1 была поставлена задача запустить quake 1 for Unix, которая и была достигнута.

В процессе, естественно, появились open/close/r/w/ioctl, и появилось ощущение, что последний неприлично, постыдно устарел. В качестве упражнения для размятия мозга я реализовал (в дополнение к обычному ioctl) некоторый альтернативный API, который бы позволил управлять свойствами устройств более гибким и удобным с точки зрения пользователя способом. Этот API, конечно, имеет свои очевидны минусы, и, в целом, эта статья — RFC, aka request For Comments.

Итак, API на уровне пользователя:

// returns name of property with sequential number nProperty, or error
errno_t listproperties( int fd, int nProperty, char *buf, int buflen );

errno_t getproperty( int fd, const char *pName, char *buf, int buflen );
errno_t setproperty( int fd, const char *pName, const char *pValue );

Правила:

1. Никаких дефайнов с номерами, только имена.
2. Никаких бинарных данных, только строки