Russian Fedora - сообщество русскоязычных участников международного проекта Fedora

Как вы могли заметить, в RHEL 7 забросили поддержку 32-битных микропроцессоров, в т.ч. x86. К сожалению, это означает, что для 32-битных ARM RHEL 7 не будет. Конечно, неофициальные пересборки будут существовать, но официально Red Hat будет заниматься только 64-битным ARM, вся архитектура которых спроектирована с участием нашего коллеги, инженера Red Hat, участника Fedora ARM SIG Jon Masters.

Коммьюнити тяжело принимало рекомендации Red Hat - ACPI, UEFI, как обязательные стандарты для ARM. Очевидные недостатки ARM-систем (не микропроцессоров, а систем, построенных на базе лицензируемых у ARM Holdings технологий) некоторыми виделись, не как недостатки, а как преимущества - свобода выбора и свобода реализации. В принципе так оно и есть, потому что любое следование стандартам и правилам, это отказ от некоторых свобод. Но понятно, что это не то, что нам, как разработчикам дистрибутива, и нашим коллегам, разработчикам и архитекторам серверных платформ, хочется. Заметьте, очень характерно то, что не существует ARM-дистрибутива - есть ARM-сборки для той машинки, для другой, для третьей, и т.п., с зачастую общим userland, но различными ядрами, и методами установки и последующей загрузки. Как курьез можно привести архитектурное решение, использованное в Raspberry Pi - в процессе загрузки используется видеопроцессор. Стандартизация ARM-систем, начавшаяся с Device Tree и unified kernel и продолжившая с UEFI, ACPI была принята разработчиками дистрибутивов как манна небесная, хотя разработчики ядра и были недовольны свалившейся на них работой и новыми проблемами.

Так или иначе, вроде коммьюнити в целом успокоилось по поводу перехода на новые стандарты, как вдруг все началось снова. Мы уже говорили, что инженер Google, Olof Johansson, был недоволен ACPI-кодом, но свое недовольство он выражал в ленте Google+. Внезапно он написал в мэйллист пост, в котором предложил вообще отказаться от ACPI в ARM. Вместо него он предложил разработать тонкую прослойку перед ядром, которая бы читала ACPI-таблицы, и формировала бы на ее основе DeviceTree. Чуть позже, он предложил кое-что еще более удивительное - подождать, пока Microsoft отладит и допишет стандарт на ACPI для ARM. У многих в этот момент, при словах "Майкрософт разработает стандарт", проснулись болезненные воспоминания - Russell King и Mark Rutland почти одновременно высказались о том, что было б очень наивно ожидать, что Microsoft разработает хороший открытый стандарт, который потом можно будет беспроблемно реализовать в открытом ПО. Russel высказался еще об одном моменте - сейчас Linux доминирует в ARM-мире, и отдавать это преимущество просто потому что кто-то из разработчиков Google не хочет следовать стандарту, стратегически неверно. К диалогу присоединился Jon Masters и мастерски завоевал всеобщую любовь, сказав, что решать уже нечего, т.к. серверные производители у себя, за речкой, все давно решили в пользу ACPI, потому что ваш DT - глючный отстой, и сами вы все дураки. Чуть позже он закрепил успех сказав, что Red Hat тоже хочет ACPI на ARM, хотя не планирует выпускать коммерческий продукт в ближайшее время, так что разработчикам ARM надо все переписывать с DT на ACPI прямо сейчас. Проблема усугубилась тем, что оказалось, что Jon подписал какое-то адское NDA, запрещающее ему рассказывать публично, что же такого хорошего в ACPI по сравнению с DT?

С таким вот настроением разработчики приступили к обсуждению того, все таки, как работать ядру с ACPI на ARM? Основные проблемы в том, что ACPI - это немаленькая (особенно по меркам разработчиков ARM) виртуальная машина в ядре, и в том, что реализация еще очень далека от стабилизации. Идея Olof о трансляции ACPI в DT, хотя и будет работать в каких-то случаях, не будет работать, когда в ACPI будут использоваться скрипты на ACPI Machine Language (AML), порой используемые для инициализации сложного оборудования. Увы, но аналогов в DT просто нет. Так или иначе придется реализовывать ACPI для ARM, и теперь уже понятно, что этот скандал был не последним в LKML - впереди еще UEFI.

Корни сложившейся ситуации в том, что в организациях, ответственных за стандарты ARM, из авторитетных Linux-компаний есть лишь Red Hat и коллектив участников Linaro. Пока коммьюнити радовалось свободе выбора и сотням форков Linux - по одному на каждое ARM-устройство, индустрия требовала стандартов, и недождавшись конструктивного диалога с любителями "поковыряться с девайсом", решила двигаться сама. Хорошо хоть вес Red Hat в Linaro Enterprise Group сделал свое дело, и коммьюнити постепенно начало переходить к стандартизированным технологиям.

Вдоволь наругавшись, начали писать код. Недавно инженерами Linaro была добавлена возможность загрузки ядра с UEFI, реализованы сервисы UEFI, и включен базовый функционал ACPI для ARM64. Этак дело пойдет, и не придется пересобирать ядро 2.6.17.4 и старые версии U-Boot с out-of-tree патчами!