Re: [devel] Модульный initrd.img

["Michael A. Kangin" <mak@complife.ru>]

On 05/07/2018 10:42 AM, Leonid Krivoshein wrote:

> Вероятно Автоугадав здесь действительно не лучший термин, назовите его 
> Перестроителем или Построителем. :) На самом деле механизм 
> автоматического определения нужных модулей (страшный Автоугадав) большей 
> частью находится в самом ядре. И ему этот список зависимостей модулей в 
> определённый момент может потребоваться. 

Леонид, вы опять описываете это всё в очень странных терминах и 
понятиях. Я вам советую почитать маны на depmod, modules.dep, modprobe, 
для исключения путаницы, чтобы понимать, что для чего нужно.

И там нет НИКАКОГО "угадава", только списки экспортируемых и требуемых 
символов, как зависимости в RPM. Вы же деятельность apt-get update не 
называете автоугадавом?



> Чтобы перестроить (создать 
> заново) список зависимостей, нужно как минимум линейно пройтись по всем 
> заголовкам модулей, как минимум рекурсивно по всей директории с модулями 
> ядра. Для экономии времени на этапе начальной загрузки каждый модуль 
> ядра у нас пожат отдельно gzip'ом, сам же слой с модулями не пожат. На 
> этапе начальной загрузки ещё неизвестно, какие из модулей реально 
> потребуются, какие нет. Полный набор модулей (без фирмвари) -- это 
> порядка 75Мб в сжатом виде. 

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

Кроме того, я имел некоторый практический опыт по исследовательской 
загрузке многих типов хостов - виртуалки, сервера, тощие клиенты 
(включая допотопно-тормознутый Intel Atom) полным образом со всеми 
четыретыщ модулей. Задержка при загрузке от depmod не ощущается вообще 
никак, от слова "совсем", даже на вышуепомянутом атоме.
Гораздо и неизмеримо большее время уходит на прокачать такой 
бесмысленно-огромный образ по сети.

> На конкретной системе из этих 75Мб или 
> порядка 4450 модулей потребуется лишь 30-100 модулей.

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

> При загрузке 
> модулей, их распаковка выполняется автоматически. А теперь запустим 
> depmod -a на максимально возможном наборе. Чтобы заглянуть в файл 
> модуля, придётся его сначала распаковать, если не целиком, то хотя бы 
> первый блок. И так по каждому из 4450 модулей, которые ещё неизвестно, 
> потребуются или нет. gzip не умеет делать это во много потоков, только в 
> один,

Используйте pigz



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

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

Равно как и обратное - наличие в природе такой технологии никому не 
мешает жить по старому и пользоваться монолитными образами.



>> Я тут подумал - даже поддержка depmod со стороны initrd не нужна. Эту 
>> depmod и дёргающий её скриптик тоже можно притащить сторонним модулем.
>> Надо будет еще подумать, мне понравилось. Захват initrd на абордаж!

-- 
Michael A. Kangin