Как вы уже знаете, наши коллеги плотно занимаются архитектурой ARM (и в частности AArch64). Например, участник Fedora ARM SIG, Rob Clark, потратил несколько лет своей жизни, чтоб к декабрю 2014 года у него появилась возможность играть в supertuxkart на ARM-платформе с видеочипом Adreno A4xx. А чего добился ты?

А вот наш коллега, известный велосипедист, Jon Masters, потратил несколько лет на стандартизацию AArch64-архитектуры, и теперь современная ARM-платформа не требует специального ядра для каждой конкретной материнской платы. Предсказуемо, но унификация была принята в штыки embedded-разработчиками, которые трудоустроены в хардверных ARM-компаниях, традиционно придерживавшихся стратегии максимально быстрого вывода продукта на рынок. Чтобы наконец убедить скептиков Grant Likely из Linaro постарался написать уже наверное стотыщпятисотую статью, почему надо взять ACPI, и отказаться от DeviceTree. Вкратце, ACPI выгодно для создателей операционных систем, в частности дистрибутивов Linux, т.к. его модель поддержки совершенно отличается от DeviceTree, который требует собирать ядро для каждой конфигурации. Действительно, DeviceTree вполне достаточно для сборки системы для телефона, которая больше не требует апгрейдов (маркетологи требуют сделать так, чтоб пользователь не апгрейдил телефон, а каждый раз покупал новый), и предназначена, чтоб запускать однопоточную джава-машину и играть там в птиц и свиней и веселую ферму. Но чтоб собирать дистрибутив, который бы работал без изменений на всех текущих и будущих системах, этого мало. Ядро там пересобирать при замене RAID-контроллера или сетевухи никто не будет, и удивительно, что embedded-разработчики всерьез это предлагают.

Вообще, вырисовывается интересная картина. ACPI, для не-embedded программиста наверное проще всего представить в виде некоей runtime-сущности, например, шины данных и/или протокола управления, а DeviceTree, это строго compile-time опция. Если так, то становится понятна деформация восприятия ACPI людьми, привыкшими "пересобирать мир". Интересно, что со статичностью DeviceTree его сторонники борются уже давно (например, мы как-то уже слышали про странную концепцию оверлеев).

К сожалению, и в этот раз статья Гранта убедила лишь тех, кто и так убежден, и споры начались уже в ленте Google+ автора. Более-менее развернутое контр-мнение, без детских вскриков про злой Microsoft и драгоценную юниксвэйную свободу выбора из десяти вариантов, привел Pavel Machek. Он обеспокоен следующим:

• ACPI требует интерпретатор в ядре (см. чуть выше - ACPI, это runtime-сервис, в то время, как DeviceTree, это compile-time фича).
• Больший объем байткода для поддержки драйверов в ACPI (и, как полагает Pavel, более хрупкий) вместо нескольких строчек в описании DeviceTree.
• ARM-серверы явно начинают архитектурно отличаться от embedded-ARM.

К дискуссии подключился и Jon Masters. В своей ленте Google+ он согласился с большей усложненностью ACPI, но еще раз привел три аргумента в его пользу - это стандарт, это стандарт, и это стандарт. Если не ACPI, то разработчикам дистрибутивов общего пользования придется продираться сквозь Cute Embedded Nonsense Hacks, более-менее общий перечень которых, как вы могли слышать, однажды составил Rich WM Jones. Терпеть это ради юниксвэйной свободы пересобирать ядро для поддержки любого мало мальски значимого изменения ядра никто не желает. Поэтому уже неважно, что думают несогласные с нами, и как они это аргументируют будет сопровождающееся овациями повсеместное внедрение ACPI и UEFI для ARM-платформы. Ну, примерно так, как это уже было с systemd.


Jon Masters аргументированно и по пунктам отвечает сторонникам DeviceTree

Пока в коробке мечутся, забавно сталкиваясь друг с другом, напуганные сторонники DeviceTree, наши коллеги, посматривая на них слегка свысока, но дружелюбно, продолжают работу. Marcin Juszkiewicz, недавно отмечавший двухлетнюю годовщину своей занятости над AArch64, сообщает, что запустил X11 на физическом железе AArch64.