LinuxCon + CloudOpen + Embedded LinuxCon Europe 2015: как это было12.10.2015 14:18

Раз в год в Европе проходит событие, которое мечтают посетить все, кто хоть что-то знает про Linux. Событие, которое собирает вокруг себя самое большое сообщество, когда-либо существовавшее на этой планете. Сообщество энтузиастов, хакеров, инженеров, программистов, админов, корпоративных боссов, всех тех, кто имеет работу и хобби благодаря Linux и open source. Мы в НТЦ Метротек привыкли делится знаниями и получать их, поэтому такое пропустить не могли. Дамы и господа, добро пожаловать в Дублин на тройную конференцию LinuxCon + CloudOpen + Embedded LinuxCon Europe 2015!

Ещё когда мы только взглянули на программу конференций мы поняли, что это будут очень насыщенные 3 дня. Каждый день с 9 утра до 6 вечера в огромном Convention Centre Dublin параллельно шло по 12(!) докладов. Естественно, хотелось посетить почти все, но наш маховик времени ещё не отправили с AliExpress, поэтому пришлось тщательно выбирать, куда пойти. Благо нас было двое (я и paulig) так что удалось посмотреть больше. В итоге, мы добрались до Дублина и началось.

День первый

В огромном выставочном/конференц центре собрались тысячи (в буквальном смысле) линуксоиды всех мастей: слащавые стартап хипстеры запускающие докер-контейнеры с Node.js приложениями, прекрасные женщины стоящие на страже управлением питанием и документации, до седовласых Unix-хакеров, которые помнят времена когда разработка Linux велась через тарболлы.

Отвечая сразу на подсознательный вопрос — да, Линус Торвальдс здесь есть. А также Грег Кроа-Хартман, Дирк Хонделл и десяток других мэйнтейнеров ядра Linux. А ещё ребята из Apache Foundation, Docker, Red Hat, IBM, GitHub, Google, Oracle, Intel и других замечательных компаний — все те, кто создают индустрию открытого ПО.

В первый день тусовка протекает довольно скромно, многие пока ещё не раскрепостились (включая нас), кого-то сковывает языковой барьер (Европа всё-таки), да и вообще пока что первый день.

Как и любая конференция всё начинается с keynote'ов, вступительных докладов от разных топ-менеджеров. На LinuxCon, уже традиционно, таким человеком является Джим Землин — президент Linux Foundation.

Со сцены Convention Center Dublin он поздравил всех с двумя знаменательными датами: 24 день рождения Linux и 30-летний юбилей Free Software Foundation.

Linux Foundation развивает множество проектов, помимо, собственно Linux. Совокупная стоимость проектов, развиваемых под эгидой Linux Foundation составляет 5 миллиардов долларов.

Также Джим объявил о создании нового проекта — «Real time collaborative project» — в рамках которого будут развивать RT-патч для Linux, а также о найме основого его разработчика Томаса Глейкснера. Немного контекста. Недавно Томас разыграл драму по поводу того, что ему никто не платит за его неимоверные усилия и поэтому он собирается его забросить.

После этого выступал Шон Горли (Sean Gourley) с темой «Человек против машины». На примере высокочастотного трейдинга было показано, что в современном мире есть сферы в которых человек уступает алгоритмам и информационным системам. Машины быстрее чем люди — если человек принимает решение за 0.7 секунд, то машина за это время успевает осуществить целую серию торговых операций. Но тем не менее машина ошибается, и эти ошибки дорого стоят. Самый известный пример здесь это история Knight Capital. Тем не менее это мир, в котором мы живём, мир в котором 61% всего интернет трафика не имеет отношения к людям.

Дальше был доклад IBM, в котором они рекламировали себя. Ничего интересного, но они главный спонсор, поэтому пришлось терпеть.

И в конце ребята из Drone Project и ETH Zurich рассказали про дронов. Дроны это не военные устройства, а всем известные коптёры. Смысл проекта Drone Project в том, чтобы создать открытые средства для создания таких устройств. На текущий момент существуют Pixhawk (Open hardware платформа) и ROS (Robot operating system).

Дальше я пошёл на доклады. Первым был «Application driven storage», где ребята из CNEX Labs рассказывали про идею т.н. «open channel SSDs» и их использование в приложениях. Open channel SSD — это SSD, у которой весь FTL убран и отдан на откуп разработчику. То есть само приложение управляет тем, как будут размещаться данные, как удалять данные и делать сборку мусора, ремапить блоки и т.д. Тем самым убирается лишние уровни абстракции и сложности, которые больше мешают чем помогают. Всё это нужно, когда вы разрабатываете приложение, которое активно работает с диском, имеет особые жёсткие требования к нему и прекрасно знает о своих паттернах доступа. Например, базы данных, которые всё время своего существования борются с операционными системами и реализуют свои собственные кеши, планировщики ввода/вывода и пр. Не исключением стал и докладчик, который рассказывал про RocksDB, специально заточенную под SSD key-value БД, форкнутую от LevelDB, и новую подсистему ядра LightNVM, которая предоставляет аппаратно-независимое API для прокидывания информации и управления в userspace. Про LightNVM должен быть отдельный доклад, поэтому основное внимание было на RocksDB. По сути, всё находится в зачаточном состоянии, по производительности новое решение проигрывает(!) в разы(!!) старому POSIX API на обычных SSD из-за отсутсвия страничного кеша и использования одного канала SSD. Но в будущем обещают феерическое ускорение, почти на уровне утилизации SSD. А пока вот так. Само железо (open channel SSD) сейчас реализовано на FPGA, но в дальнейшем планируется делать ASIC'и.

Следующим был доклад «RTFM? Write a better FM!». Суть заключается в «stop being a jerk, get to know your audience». Банальные вещи, потому что, как заметил сам докладчик, люди которые ходят слушать такие темы обычно молодцы, а тем кому это действительно надо они не доходят.

Дальше я пошёл на докладчика с которым был заочно знаком по коду — Alan Tull из Altera, код которого я изучал и допиливал под нужды наших продуктов. Он рассказывал про хорошо знакомый мне FPGA management framework. Ну, вернее, сначала про FPGA, про SoC FPGA, потом про то, как раньше с FPGA работали, историю разработки и то, в каком состоянии это находится сейчас. Технических деталей про сам FPGA management было немного, больше про DeviceTree overlays. Посмотрели на последнюю версию и её API. Надо посмотреть, что изменилось.

Продолжая тему FPGA был ещё доклад под красочным названием «Using FPGA for driver testing», от которого я ожидал чудесных откровений. Но на деле оказалось, что разработчики U-Boot'а берут простенькие Lattice FPGA, и делают для них прошивку, которая занимается fuzzy тестированием аппаратных шин и устройств. В частности, FPGA подключают к I2C или SPI шине, и пускают на неё рандомные и просто ошибочные команды, а дальше смотрят упал драйвер шины или нет. Аналогично поступают для тестирования самой шины, когда на FPGA симулируют странное устройство типа SD карты. Если честно, я ожидал большего.

«Maximum performance. How to get it and how to avoid pitfalls» за авторством Кристофа Ламетера (Cristoph Lameter), активного разработчика сетевой подсистемы ядра, был довольно общим, в котором систематизировался большой опыт по тюнингу производительности. Обычно софт уже оптимизирован на производительность для большинства случаев или популярных аппаратных платформ. Но порой это не то, что вам нужно, и если вы хотите добиваться максимумов, то необходимо чем-то жертвовать: деньгами, простотой, поддержкой и/или производительностью других частей. Как правило тюнят 2 вещи — ввод/вывод и сеть, как самые долгие и ресурсоёмкие части. Но, т.к. современные системы хранения данных по сути повторяют поведение сетей (передача команд, инкапсуляция сообщений), то можно сказать, что «Storage today is network communication». И если вы хотите оптимизировать ваше приложение, то вам нужно идти вниз к железу. Вместо использования API вашего языка программирования использовать буферизированное I/O из glibc, либо дёргать Socket API, либо переписать всё на RDMA API, либо перейти на FPGA или ASIC. При оптимизации обращения к памяти нужно помнить про иерархию кешей и стараться ей помогать. Для оптимизации работы CPU стоит использовать векторизацию (если позволяет приложение) или вообще отдать обработку на откуп GPU. Короче говоря, основной посыл заключался в том, что если вы хотите максимальной производительности, то затачивайтесь под своё железо и избавляйтесь от лишних слоев и операционных систем, что и сделали люди из проектов LightNVM и RocksDB, о которых я говорил вначале. Будем думать над использованием в B100.

В заключении были очередные keynotes, из которых наиболее интересным было Kernel Developers Panel, когда собирают разработчиков ядра Linux и задают им вопросы, обсуждая разные темы. Помимо стандартных «Как вы дошли до жизни такой» в основном пытались понять как привлечь новых людей и как помочь мэйнтейнерам в их неблагодарной работе. Сошлись на том, что работы невпроворот и людям надо помогать вступать в сообщество, в том числе помогая мэйнтейнерам.

И мы пошли искать мэйнтейнеров в барах

День второй

Второй день обещал быть более интересным, с точки зрения докладов. Я собирался послушать про LLVM/Clang, Btrfs и снэпшоты, Buildroot и профилирование.

Утренние кейноты второго дня были интереснее первых. Сначала выступала девушка Ли Ханивелл (Leigh Honeywell) из Slack Technologies на тему «Securing an open future». Отталкиваясь от всем известного Heartbleed, говорила о возможных действиях по предотвращению таких ситуаций. Если в кратце, то разработчикам стоит не забывать о безопасности и делать хоть что-нибудь в этом направлении: изучать средства, возможные векторы атак и пр., т.е. попытаться думать как злоумышленник. Для менеджеров стоит создавать здоровую культуру, в которой люди не чувствовали себя виноватыми, потому что это приводит к сокрытию реальных проблем. В довесок стоит почитать хорошие практики организации безопасной разработки, например Microsoft SDL.

Далее был Container Panel — открытое обсуждение на тему контейнеров. Основные тезисы:

Готовы ли контейнеры к продакшену? Да, основа контейнеров в ядре существует уже порядка 10 лет и всё с ней хорошо. Docker показал как этим можно удобно пользоваться, и вот тут есть чем заниматься.
Можем ли мы заменить традиционный способ дистрибуции приложений через rpm или deb пакеты контейнерами? С одной стороны, контейнер это чёрный ящик в который можно засунуть что угодно и пользоваться таким не очень приятно. С другой стороны, когда мы ставим какое-нибудь сложное приложение, которое тянет за собой кучу зависимостей, мы не проверяем, что в пакетах. Всё дело в доверии и проверке подлинности, и вот именно проверка подлинности контейнеров это то, что сейчас реально нужно.

В заключение кейнотов поговорили про IoT, куда ж без него. Если кратко, то IoT изменит мир, но должен решить важные проблемы:

Безопасность
Недостаток экспертов в embedded системах
Взаимодействие вещей

Дальше пошли доклады. Первым я пошёл слушать «Boosting Developer productivity with Clang» от Тимана Шеллера из Samsung.

Во-первых, Clang правильно говорить как «Клэнг», а не «Шланг» или как вы там его обзываете. Для тех, кто знаком с LLVM и Clang было скучновато. Тиман рассказал, что LLVM — это модульный фреймворк для разработки компиляторов и инфрастуктура для множества проектов, например:

Clang — компилятор C/C++/Objective C
LLDB — отладчик
lld — фреймворк для линкеров
polly — polyhedral optimizer

Сейчас LLVM используется в WebKit FtL JIT, Rust, Android NDK, OpenCL реализациях, CUDA И т.д., что говорит о более чем достаточной зрелости.

Главная фишка LLVM — это IR, Intermediate Representation. RISC-подобный Промежуточный биткод с информацией о типах, в который транслируется исходный код, и в рамках которого осуществляются все оптимизации. IR затем транслируется в ассемблер или машинный код соответсвующей архитектуры.

Clang — это мощный компилятор C/C++/Objective C, с богатыми возможностями по диагностике. На основе Clang'а сделано несколько довольно интересных утилит, а именно:

Clang static analyzer — статический анализатор С кода
clang-format — форматтер кода
clang-modernize — приводит С++ код к новым стандартам
clang-tidy — поиск нарушений правил разработки (coding conventions)
Sanitizers:
- AddressSanitizer
- ThreadSanitizer
- LeakSanitizer
- MemorySanitizer
- UBSanitizer (undefined behaviour)

По производительности, код сгенерированный Clang в среднем на 2% медленнее gcc. но зато время компиляции значительно меньше и возможности диагностики шире. Дальше мы посмотрели возможности диагностики на примерах в сравнении с gcc. И вывели рецепт наилучшего ускорения сборки большого C++ проекта (самого LLVM). Рецепт такой — Clang + gold + PGO (profile guided optimizations) + Split Dwarf + optimized TableGen + Ninja. Получается в 2 раза быстрее gcc. Детали, спрашивайте у докладчика.

Далее я пошёл на интригующий доклад «Btrfs and rollback», но был разочарован поверпоинтом и отвратительной подачей материала.

Ушёл на «Project Ara architecture». Из того, что я услышал узнал, что для модульного телефона разработали шину UniPro, каждый модуль имеет маленький CPU, чтобы общаться по UniPro, когда модуль вставляется, то драйвер шины получает уведомление о новом модуле, подгружает драйвер и при необходимости просит Андроид обновить софт из облака.

Посетил великолепный туториал по Buildroot. Томас Петазонни из Free Electrons на глазах собирал систему для BeagleBone Black из BuildRoot, показал конфигурировать компоненты, как добавлять свои патчи ядра. Посмотрели как делать собственный пакет и кастомизировать rootfs. 2 часа мы провели в демо с вопросами и ответами, и теперь я с большим энтузиазмом отношусь к Buildroot и собираюсь его попробовать.

И последний доклад был на тему «Linux performance profiling and monitoring», который был абсолютно неинтересным любому, кто хоть чуть-чуть пытался этим заниматься. Доклад состоял из перечисления утилит типа vmstat, sar, top(>_<), упоминания ftrace и perf. Если вам действительно интересно, то вам сюда — brendangregg.com/linuxperf.html

Заключительные кейноты состояли из «Fireside chat» с Линусом Торвальдсом и Дирком Хонделлом. Дяденьки мило пообщались про состояние ядра и чем Линус собирается заниматься. С ядром всё хорошо, Линус ничем не хочет заниматься.

И потом всё тот же Томас Петазонни рассказал, как они своей маленькой компанией из 6 человек умудряются делать весомый вклад в развитие ядра, в частности ARM SoC'ов. Секрет просто — маленькая команда и отсутсвие проблем с коммуникациями, фокус на продвижении в апстрим, постоянный обмен знаниями, общение на конференциях.

День третий

Помимо конференции параллельно шла небольшая выставка, на которой спонсоры показывали себя, кто-то хантил, кто-то проводил мини-саммит (UEFI и Yocto, например). Но в основном там ели и пили, что заметно на фотографии.

Кейноты третьего дня открыл Мартин Финк из HP, который представил проект OpenSwitch — современная открытая ОС для сетевых устройств (коммутаторов). С большим интересом смотрим за проектом, надеясь использовать его в наших коммутаторах. Также Мартин обозначил одной из главных угроз open source наличие большого количества лицензий (порядка 70), которые в большинстве не совместимы друг с другом (читай пример про ZFS, DTrace и Linux), тролльнул Oracle и IBM и был таков.

Далее мы узнали, что интернету вещей нужна открытая платформа, над которой у нас будет контроль (привет, Lenovo) и начало ей положено проектом J-Core CPU — открытом, в смысле open hardware, процессору.

И потом был жуткий рекламный доклад от Huawei в лучших традициях Death by PowerPoint, который никто не слушал.

Пошёл на доклады. Очень хотел посетить рассказ про Multifunctional devices (mfd), но докладчик начал на 10 минут раньше (зачем?!), быстро протараторил вводную и пошёл кидаться сумбурными кусками кода. Убежал на доклад про Open Channel SSDs.

Open Channel SSDs — это SSD устройства, которые предоставляют пользовательским (и ядерным) приложениям доступ к внутренней информации, а именно «геометрии» SSD:

NAND носитель
Каналы, тайминги
Список bad блоков
Некий PPA формат
ECC

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

Тим Бёрд (Bird) выступил со своим ежегодным докладом «Status of Embedded Linux», где он рассказал, что интересного произошло за год в Linux для embedded систем, и что будет происходить. Нет смысла перечислять всё, поэтому обойдусь кратким списком:

За чем стоит понаблюдать в будущем году:

kdbus
RT-preempt (теперь под покровительством Linux Foundation пойдёт в гору)
Persistent Memory
SoC mainlining

Далее было 2 доклада про отладчики — «How debuggers work» и «Debugging Linux kernel with GDB».

Про то, как работают отладчики рассказывал Павел Молл из ARM. Если вкратце, то через ptrace. Если длиннее, то отладчики форкают процесс, делают там ptrace(PTRACE_TRACEME,...) и execve. В родительском же процессе (отладчике) происходит всё управление. Установка breakpoint'а по адресу заключается в сохранении инструкций по этому адресу где-нибудь у отладчика и их замену на архитектурно специфичные. Например, для x86 это int 3, а для ARM есть специально определённая неопределённая инструкция (there is a defined undefined instruction). Каламбур-с, да. Когда исполнение достигает такой специальной инструкции, то происходит исключение, которое порождает сигнал SIGILL, который доставляется родительском процессу, т.е. отладчику. А он уже может делать всё, что хочет. Для того, чтобы делать что-то интересное, исследуемый процесс должен поставлять debug info, которая обычно хранится в отдельных секциях ELF файла в DWARF формате.

Про отладку ядра Linux рассказывал Питер Гриффин (совсем не такой) из Linaro. Предлагал 4 способа отладки:

gdb remote до kgdb stub в ядре
gdb remote до qemu
gdb remote до gdb-совместимого JTAG, например OpenOCD
gdb и kernel dump, утилита crash

Также рассказал о прогрессе поддержки отладки Linux в GDB.

Также из Linaro рассказывали доклад на пафосную тему «Rethinking the core OS in 2015». Но по сути, унылый бородач рассказывал банальности в духе «А давайте заменим gcc на Clang, а glibc на musl!». В итоге огребаем кучу проблем, и выигрыша особого нет. Странно.

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

Заключение

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

А ещё у меня есть 2 фотки, которым многие друзья теперь завидуют.

На этом всё. Спасибо за внимание!