From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,FUZZY_XPILL, RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 To: devel@lists.altlinux.org References: <61310192-890b-1f93-a05c-09afb4a8efdd@gmail.com> <38eee31c-3666-461f-1c1b-0a23a5064ef1@complife.ru> <3811d2e4-d1e1-8bab-b07d-ba23e15035f0@complife.ru> <3f73de94-85d8-9f69-c42e-4bf793c16cd6@gmail.com> From: "Michael A. Kangin" Message-ID: Date: Mon, 7 May 2018 13:52:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <3f73de94-85d8-9f69-c42e-4bf793c16cd6@gmail.com> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [devel] =?utf-8?b?0JzQvtC00YPQu9GM0L3Ri9C5IGluaXRyZC5pbWc=?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 11:52:59 -0000 Archived-At: List-Archive: List-Post: 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