From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Message-ID: <4A16A5E1.9030501@altlinux.ru> Date: Fri, 22 May 2009 17:17:21 +0400 From: Alexey Gladkov User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.8.1.18) Gecko/20081202 Thunderbird/2.0.0.18 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: ALT Linux Team development discussions References: <20090521234843.GA12238@wo.int.altlinux.org> <4A15EA23.5060103@altlinux.ru> <20090522000657.GA17907@wo.int.altlinux.org> In-Reply-To: <20090522000657.GA17907@wo.int.altlinux.org> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [devel] =?utf-8?b?0JfQsNC80LXQvdCwINC00LvRjyBta2luaXRyZA==?= 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: Fri, 22 May 2009 13:18:33 -0000 Archived-At: List-Archive: List-Post: 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