[devel] Замена для mkinitrd

[Alexey Gladkov]

On 22.05.2009 04:06, Dmitry V. Levin wrote:
>> Когда я на него смотрел, то мне не понравилось ещё и то что они тянут
>> в initrd glibc всегда.
> 
> По каким причинам сейчас может возникнуть желание не использовать glibc
> внутри initramfs?
> 
> $ du -Lhsc /lib64/ld-linux-x86-64.so.2 /lib64/libc.so.6 
> 136K	/lib64/ld-linux-x86-64.so.2
> 1,3M	/lib64/libc.so.6
> 1,5M	итого

Использовать только glibc слишком толсто. Например, чтобы не
переписывать наш /init initrd я портировал klibc-utils на glibc...
размер динамически собранных утилит оказался больше размера тех же
утилит статически собранных с klibc. Конечно, это копейки, но всё же.

Тот же mkinitcpio показал, что без glibc можно неплохо прожить.

Мы планировали не ударяться в крайности и использовать klibc пока это
возможно, но у нас предусмотрен механизм, чтобы положить на initrd
произвольную утилиту ... и только в этом случае на initrd будут
скопирована glibc и всё что нужно по зависимостям.

Такой подход, даёт в большенстве случаев маленький размер initrd. И
лишь если хочется странного, будут использованы тяжёлые утилиты. Я
надеюсь, что таких случаев будет не много.

> Мне кажется, что можно пожертвовать этими мегабайтами для того, чтобы
> получить взамен свободу использования разного софта внутри initramfs.
> 
>> В этом плане mkinitcpio гораздо привлекательнее.
> 
> Ты ведь наверняка уже смотрел разные реализации.  Не хочешь рассказать,
> где что сделано хорошо, и где что сделано плохо?

Когда я смотрел проекты, я оценивал несколько аспектов:

* как происходит формирование образа;
* возможности по конфигурированию;
* возможности по расширению;
* качество кода.

dracut
------
От души раздувает initrd... копирует туда glibc, sh, coreutils.
Модульность есть, но ограничена сваленными в кучу кусками кода.

Конфигурирование только через командную строку.

Качество кода так себе.

mkinitramfs
-----------
Ещё хуже. Так же всё берётся из системы... только берётся с запасом:
bash (не sh!), awk, sed, grep, find, fsck, passwd ...
Всё прибито гвоздями, модульность отсутствует. Хороший такой монолитик.

Конфигурирование через командную строку.

Качество кода брррр.

initramfs-tools
---------------
Что тут скажешь это откуда vsu@ черпал вдохновение для нашей
initramfs. Вот только у них модули копируются все подряд.

Модульность примерно такая же как в dracut... это не модули а хуки для
подхачивания образа.

Конфигурирование через конфиг и командную строку, но очень условное.
По сути на саму сборку повлиять нельзя (например не копировать
какие-то модули).

Глядя на этот код и на наш код видно что vsu@ проделал большую работу

mkinitcpio
----------
Отличается от перечислнных выше. Он использует только klibc. Для него
написано много утилит под klibc для комфортной жизни в initrd.

Оформленные модули и хуки. Они думали про модульность с самого начала.

Конфигурирование через конфиг и командную строку.

Код хоть и не оптимален, но лучше чем у всех.

К сожалению, сразу обнаружились проблемы в дизайне их /init и системе
загрузки модулей в runtime части. Это приводит к тому, что некоторые
комбинации загрузок а-ля lvm-over-usb работать не будут.

Итог
----
В общем, проглядев все эти решения у меня сложилось стойкая
убеждённость, в том что использовать чужое решение не удастся. Все
вендоры используют свой подход к генерации initramfs и решения у всех
отличаются. Любая адаптация приведёт к контролируемому(или нет) форку.
Собственно, текущая поддержка initramfs это тоже форк. Все эти проекты
имеют хорошие идеи, но также очень неприятные баги и часто в
архитектуре либо сборочной части, либо в runtime части.

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

-- 
Rgrds, legion