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

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

[Kirill A. Shutemov]

legion@ и я сейчас пытаемся разработать более гибкую систему сборки initrd.

Основные особенности:

- Модульность. Есть набор модулей каждый из которых добавляет в initrd какую-то
функциональность. Например lvm или сжатие образа. Каждый модуль описывает
как реализовать функциональность и когда(после/до каких стадий) это должно быть
сделано.

- Отсутствие автодетекта расположения рута. mkinitrd ищет и помещает модули
ядра в образ, которые могут помочь добраться до рутового раздела. Однако, это
работает только для тривиальных случаев. Поскольку путь до рута может быть
сколь угодно сложным (например мне нужно
lvm-over-luks-over-lvm-over-usbstorage),
мы пока отказались от автодетекта. Пользователь сам описывает какой
функциональностью должен обладать initrd, в том числе какие модули в него
помещать. Возможно автодетект в том либо ином объёме будет добавлен позже.

Сейчас есть два прототипа которые реализуют практически одни и те же идеи, но
используют разный инструментарий. Одна реализована на смеси make + shell,
подобно mkimage. make используется для описания зависимостей модулей.
Вторая, подобно mkinitrd, написана на shell и реализует механизм зависимостей
самостоятельно. Обе смотреть в public на git.alt у legion@.
make-initrd и mkinitramfs
соответственно.

Мне более симпатичен первый вариант, Алексею второй. Хотелось бы узнать какое
направление движения devel@ считает более перспективным. Надеемся на
конструктивную критику.

P.S. Хотелось бы отметить, что это лишь прототипы отражающие некоторые идеи и
не готовы к реальному применению (хотя мне удавалось загрузиться с результатом
их работы ;)

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

[Eugene Ostapets]

2009/5/21 Kirill A. Shutemov <kirill shutemov.name>:
> legion@ и я сейчас пытаемся разработать более гибкую систему сборки initrd.
>
Хм... А вы не смотрели на уже существующие и достаточно отлаженные
решения, которые могут все нижеперечисленное и еще кучу всего, что вам
даже в голову не пришло?
Федора переходит на это:
http://fedoraproject.org/wiki/Initrdrewrite
Точно по вашим принципам работает mkinitrd из Suse и (по слухам - сам
не смотрел в его потроха) в Debian...

Хотелось бы услышать хоть одну вескую причину для изобретения
очередного пятиколесного лисапета с колесами разного диаметра и
формы...


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

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

[Dmitry M. Maslennikov]

21 мая 2009 г. 16:07 пользователь Eugene Ostapets <eostapets@gmail.com> написал:
> Хм... А вы не смотрели на уже существующие и достаточно отлаженные
> решения, которые могут все нижеперечисленное и еще кучу всего, что вам
> даже в голову не пришло?
> Федора переходит на это:
> http://fedoraproject.org/wiki/Initrdrewrite
> Точно по вашим принципам работает mkinitrd из Suse и (по слухам - сам
> не смотрел в его потроха) в Debian...
>
> Хотелось бы услышать хоть одну вескую причину для изобретения
> очередного пятиколесного лисапета с колесами разного диаметра и
> формы...
Присоединяюсь к вопросу. Мне в свое время нравилось решение от
ArchLinux: http://wiki.archlinux.org/index.php/Mkinitcpio

-- 
Dmitry M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

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

[Alex Gorbachenko]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

On Thu, 21 May 2009 15:01:58 +0300
Kirill wrote:

>Основные особенности:

mkinitrd(5)
mkinitrd
mkinitrd(5)

NAME
       mkinitrd - description of modular scripts layout

DESCRIPTION
       mkinitrd  creates initial ramdisk images for booting Linux. It
       is designed to be modular, so that functionality required by
       other programs can be maintained in separate scripts.

это OpenSUSE. 

-- 
np: Brand New Sin - Broken Soul

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

On Thu, May 21, 2009 at 03:07:13PM +0300, Eugene Ostapets wrote:
> 2009/5/21 Kirill A. Shutemov <kirill shutemov.name>:
> > legion@ и я сейчас пытаемся разработать более гибкую систему сборки initrd.
> >
> Хм... А вы не смотрели на уже существующие и достаточно отлаженные
> решения, которые могут все нижеперечисленное и еще кучу всего, что вам
> даже в голову не пришло?
> Федора переходит на это:
> http://fedoraproject.org/wiki/Initrdrewrite

%description
dracut is an attempt to build a new, event-driven initramfs infrastructure 
based around udev.

Этот dracut, по вашему мнению, отлаженный?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Alexey Gladkov]

On 22.05.2009 03:48, Dmitry V. Levin wrote:
> %description
> dracut is an attempt to build a new, event-driven initramfs infrastructure 
> based around udev.
> 
> Этот dracut, по вашему мнению, отлаженный?

Когда я на него смотрел, то мне не понравилось ещё и то что они тянут
в initrd glibc всегда.

В этом плане mkinitcpio гораздо привлекательнее.

-- 
Rgrds, legion

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

On Fri, May 22, 2009 at 03:56:19AM +0400, Alexey Gladkov wrote:
> On 22.05.2009 03:48, Dmitry V. Levin wrote:
> > %description
> > dracut is an attempt to build a new, event-driven initramfs infrastructure 
> > based around udev.
> > 
> > Этот dracut, по вашему мнению, отлаженный?
> 
> Когда я на него смотрел, то мне не понравилось ещё и то что они тянут
> в 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	итого

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

> В этом плане mkinitcpio гораздо привлекательнее.

Ты ведь наверняка уже смотрел разные реализации.  Не хочешь рассказать,
где что сделано хорошо, и где что сделано плохо?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Led]

On Friday, 22 May 2009 03:06:57 Dmitry V. Levin wrote:
> On Fri, May 22, 2009 at 03:56:19AM +0400, Alexey Gladkov wrote:
> > On 22.05.2009 03:48, Dmitry V. Levin wrote:
> > > %description
> > > dracut is an attempt to build a new, event-driven initramfs
> > > infrastructure based around udev.
> > >
> > > Этот dracut, по вашему мнению, отлаженный?
> >
> > Когда я на него смотрел, то мне не понравилось ещё и то что они тянут
> > в 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	итого

... в 6 раз больше, чем uClibc


-- 
Led

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

On Fri, May 22, 2009 at 03:22:13AM +0300, Led wrote:
> On Friday, 22 May 2009 03:06:57 Dmitry V. Levin wrote:
> > On Fri, May 22, 2009 at 03:56:19AM +0400, Alexey Gladkov wrote:
> > > On 22.05.2009 03:48, Dmitry V. Levin wrote:
> > > > %description
> > > > dracut is an attempt to build a new, event-driven initramfs
> > > > infrastructure based around udev.
> > > >
> > > > Этот dracut, по вашему мнению, отлаженный?
> > >
> > > Когда я на него смотрел, то мне не понравилось ещё и то что они тянут
> > > в 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	итого
> 
> ... в 6 раз больше, чем uClibc

... и на 2 порядка меньше, чем то, что будет запущено по окончании работы
initramfs.  В чём выгода от уменьшения размера initramfs такой ценой?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Led]

On Friday, 22 May 2009 03:25:43 Dmitry V. Levin wrote:
> On Fri, May 22, 2009 at 03:22:13AM +0300, Led wrote:
> > On Friday, 22 May 2009 03:06:57 Dmitry V. Levin wrote:
> > > On Fri, May 22, 2009 at 03:56:19AM +0400, Alexey Gladkov wrote:
> > > > On 22.05.2009 03:48, Dmitry V. Levin wrote:
> > > > > %description
> > > > > dracut is an attempt to build a new, event-driven initramfs
> > > > > infrastructure based around udev.
> > > > >
> > > > > Этот dracut, по вашему мнению, отлаженный?
> > > >
> > > > Когда я на него смотрел, то мне не понравилось ещё и то что они тянут
> > > > в 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	итого
> >
> > ... в 6 раз больше, чем uClibc
>
> ... и на 2 порядка меньше, чем то, что будет запущено по окончании работы
> initramfs.  В чём выгода от уменьшения размера initramfs такой ценой?

Какой "такой" ценой?
В любом случае, а не говорил о какой-то выгоде (хотя в ряде случаев она 
будет), просто сказал только то, что сказал.

-- 
Led

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

[Kirill A. Shutemov]

2009/5/22 Dmitry V. Levin <ldv@altlinux.org>:
> On Fri, May 22, 2009 at 03:56:19AM +0400, Alexey Gladkov wrote:
>> On 22.05.2009 03:48, Dmitry V. Levin wrote:
>> > %description
>> > dracut is an attempt to build a new, event-driven initramfs infrastructure
>> > based around udev.
>> >
>> > Этот dracut, по вашему мнению, отлаженный?
>>
>> Когда я на него смотрел, то мне не понравилось ещё и то что они тянут
>> в 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    итого
>
> Мне кажется, что можно пожертвовать этими мегабайтами для того, чтобы
> получить взамен свободу использования разного софта внутри initramfs.

Для базового функционала у нас используется klibc, c которой в тривиальных
случаях, которых  большенство, образ получается приблизительно вдвое
меньше. glibc добавляется если это необходимо т.е. если мы добавляем в
образ ELF динамически слинкованый с glibc, например lvm. Думаю, это
правильно.

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

[Afanasov Dmitry]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

On Fri, May 22, 2009 at 03:56:19AM +0400, Alexey Gladkov wrote:
> On 22.05.2009 03:48, Dmitry V. Levin wrote:
> > dracut is an attempt to build a new, event-driven initramfs infrastructure 
> > based around udev.
... 
> в initrd glibc всегда.
udev, glibc...
выбор, какой initrd хочется - glibc'ный, udev'ный, гвоздями прибитый -
планируется делать?

initrd критичен для remote загрузки, не всегда в буфера влезает.

-- 
С уважением
Афанасов Дмитрий

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Eugene Ostapets]

2009/5/22 Dmitry V. Levin <ldv altlinux.org>:
> On Thu, May 21, 2009 at 03:07:13PM +0300, Eugene Ostapets wrote:
>> 2009/5/21 Kirill A. Shutemov <kirill shutemov.name>:
>> > legion@ и я сейчас пытаемся разработать более гибкую систему сборки initrd.
>> >
>> Хм... А вы не смотрели на уже существующие и достаточно отлаженные
>> решения, которые могут все нижеперечисленное и еще кучу всего, что вам
>> даже в голову не пришло?
>> Федора переходит на это:
>> http://fedoraproject.org/wiki/Initrdrewrite
>
> %description
> dracut is an attempt to build a new, event-driven initramfs infrastructure
> based around udev.
>
> Этот dracut, по вашему мнению, отлаженный?
Нет, отлаженый и работающий неcколько лет - mkinitrd в suse/debian, а
dracut - это новый проект на тех же принципах, но и он уже очень
далеко ушел по части функциональности и стабильности от двух
предложеных велоси^W концептов.


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

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

[Wartan Hachaturow]

2009/5/22 Led <ledest@gmail.com>:
>> $ 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  итого
>
> ... в 6 раз больше, чем uClibc

Кто-то хочет поподдерживать uclibc'шный тулчейн?

-- 
Regards, Wartan.

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

[Led]

On Friday, 22 May 2009 12:02:38 Wartan Hachaturow wrote:
> 2009/5/22 Led <ledest@gmail.com>:
> >> $ 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  итого
> >
> > ... в 6 раз больше, чем uClibc
>
> Кто-то хочет поподдерживать uclibc'шный тулчейн?

Кому нужно - будет поддерживать - ничего сложного здесь нет. Тем более, что 
uClibc - не только для initrd используется.

-- 
Led

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

[Kirill A. Shutemov]

2009/5/21 Dmitry M. Maslennikov <maslennikovdm@gmail.com>:
> 21 мая 2009 г. 16:07 пользователь Eugene Ostapets <eostapets@gmail.com> написал:
>> Хм... А вы не смотрели на уже существующие и достаточно отлаженные
>> решения, которые могут все нижеперечисленное и еще кучу всего, что вам
>> даже в голову не пришло?
>> Федора переходит на это:
>> http://fedoraproject.org/wiki/Initrdrewrite

Initial ideas

* One initrd to rule them all - Instead of one for the livecd, one for
the installer,
  one for the distro

Я не хочу initrd такого размера. А вы?

>> Точно по вашим принципам работает mkinitrd из Suse и (по слухам - сам
>> не смотрел в его потроха) в Debian...

Дайте ссылку на исходники mkinitrd из Suse, пожалуйста.

> Присоединяюсь к вопросу. Мне в свое время нравилось решение от
> ArchLinux: http://wiki.archlinux.org/index.php/Mkinitcpio

По документации выглядит неплохо.

У нас несколько другой подход к подключению дополнительного функционала. В
mkinitcpio в HOOKS указывается _порядок_ добавления функционала в образ. Мы
же пытаемся сделать так, что бы пользователь лишь заявлял какой функционал от
initrd ему требуется (см. FEATURES в make-initrd), а сами модули
пишутся так, что
бы порядок в стеке устройств (например, lusk поверх lvm, или наоборот) на этапе
сборки образа был не важен.

Ещё, похоже он не умеет загружаться по UUID= и LABEL=, которые используются
у нас.


Я считаю, что это не случайно, что каждый более-менее большой дистрибутив имеет
свой инструментарий для сборки initrd. У каждого дистрибутива хватает
специфики в
области начальной загрузки. Если вы желаете адаптировать любой из выше
обозначенных вариантов для ALT -- попробуйте. Мне кажется получится форк,
который никто поддерживать не будет.

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

[Sergey Bolshakov]

>>>>> "Stanislav" == Stanislav Ievlev <stanislav.ievlev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
[skipped]
 >> Initial ideas
 >> 
 >> * One initrd to rule them all - Instead of one for the livecd, one for
 >> the installer,
 >> one for the distro
 >> 
 >> Я не хочу initrd такого размера. А вы?

 > А я бы хотел, на замену propagator ;)
Что, новый и менюшки рисовать будет ?

-- 

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

[Mykola S. Grechukh]

22 мая 2009 г. 14:54 пользователь Sergey Bolshakov <> написал:
>>>>>> "Stanislav" == Stanislav Ievlev <stanislav.ievlev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> [skipped]
>  >> Initial ideas
>  >>
>  >> * One initrd to rule them all - Instead of one for the livecd, one for
>  >> the installer,
>  >> one for the distro
>  >>
>  >> Я не хочу initrd такого размера. А вы?
>
>  > А я бы хотел, на замену propagator ;)
> Что, новый и менюшки рисовать будет ?

+1

Re: [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

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

[Michael Shigorin]

On Fri, May 22, 2009 at 05:17:21PM +0400, Alexey Gladkov wrote:
> mkinitcpio
> ----------
> Отличается от перечислнных выше. Он использует только klibc. Для него
> написано много утилит под klibc для комфортной жизни в initrd.
> 
> Оформленные модули и хуки. Они думали про модульность с самого начала.
> 
> Конфигурирование через конфиг и командную строку.
> 
> Код хоть и не оптимален, но лучше чем у всех.
> 
> К сожалению, сразу обнаружились проблемы в дизайне их /init и системе
> загрузки модулей в runtime части. Это приводит к тому, что некоторые
> комбинации загрузок а-ля lvm-over-usb работать не будут.

А с ними не пробовали общаться по этой теме?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Dmitry M. Maslennikov]

22 мая 2009 г. 17:17 пользователь Alexey Gladkov <legion@altlinux.ru> написал:
> ...
Меня практически убедили. А когда мы сможем попробовать результат, а
то у меня уже давно есть желание грузиться с lvm.

Кроме того для отладки очень удобно иметь жирный initrd, так что не
плохо было бы заиметь модуль, который сразу добавит в initrd bash и
все что нужно для нормальной работы, а то в текущем очень сложно
понять в чем проблема, когда он выкидывает в консоль из-за недостатка
утилит.

-- 
Dmitry M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

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

[Kirill A. Shutemov]

2009/5/22 Dmitry M. Maslennikov <maslennikovdm@gmail.com>:
> 22 мая 2009 г. 17:17 пользователь Alexey Gladkov <legion@altlinux.ru> написал:
>> ...
> Меня практически убедили. А когда мы сможем попробовать результат, а
> то у меня уже давно есть желание грузиться с lvm.

Будет анонсиравано дополнительно.

> Кроме того для отладки очень удобно иметь жирный initrd, так что не
> плохо было бы заиметь модуль, который сразу добавит в initrd bash и
> все что нужно для нормальной работы, а то в текущем очень сложно
> понять в чем проблема, когда он выкидывает в консоль из-за недостатка
> утилит.

Подробней, пожалуйста. Каких именно утилит вам нехватает? Лично мне
нехватало ls. legion@ написал мне маленький ls :)

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

[Alexey Gladkov]

On 22.05.2009 17:33, Michael Shigorin wrote:
>> К сожалению, сразу обнаружились проблемы в дизайне их /init и системе
>> загрузки модулей в runtime части. Это приводит к тому, что некоторые
>> комбинации загрузок а-ля lvm-over-usb работать не будут.
> 
> А с ними не пробовали общаться по этой теме?

Не пробовал. У меня были нарекания на все проекты и я не ставил себе
цели исправлять их. Тем более, когда проблемы в архитектуре.

-- 
Rgrds, legion

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

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]


Twas brillig at 16:45:27 22.05.2009 UTC+03 when kirill@shutemov.name did gyre and gimble:

 >> Меня практически убедили. А когда мы сможем попробовать результат, а
 >> то у меня уже давно есть желание грузиться с lvm.

 KAS> Будет анонсиравано дополнительно.

А где смотреть in-progress?

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 834 bytes --]

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

[Michael Shigorin]

On Fri, May 22, 2009 at 04:45:27PM +0300, Kirill A. Shutemov wrote:
> Подробней, пожалуйста. Каких именно утилит вам нехватает? Лично
> мне нехватало ls. legion@ написал мне маленький ls :)

Некоторые из нас выкручивались echo * (echo /lib/modules/*),
но иметь mkinitrd-module-debug и комфорт в виде ls и поддержки
readline в такие вечера даже не мечталось...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Dmitry M. Maslennikov]

22 мая 2009 г. 17:45 пользователь Kirill A. Shutemov
<kirill@shutemov.name> написал:
> Подробней, пожалуйста. Каких именно утилит вам нехватает? Лично мне
> нехватало ls. legion@ написал мне маленький ls :)
Сейчас уже не помню. Помню только, что когда появлялась задача, то
просто не знаешь, как сделать то или иное действие, потому что нет
практически ничего.

-- 
Dmitry M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

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

[Michael Shigorin]

On Fri, May 22, 2009 at 05:46:34PM +0400, Alexey Gladkov wrote:
> >> К сожалению, сразу обнаружились проблемы в дизайне их /init
> >> и системе загрузки модулей в runtime части. Это приводит к
> >> тому, что некоторые комбинации загрузок а-ля lvm-over-usb
> >> работать не будут.
> > А с ними не пробовали общаться по этой теме?
> Не пробовал. У меня были нарекания на все проекты и я не ставил
> себе цели исправлять их. Тем более, когда проблемы в архитектуре.

Ну иногда не только ты их осознаёшь, а и апстрим тоже.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Kirill A. Shutemov]

2009/5/22 Mikhail Gusarov <dottedmag@altlinux.org>:
>
> Twas brillig at 16:45:27 22.05.2009 UTC+03 when kirill@shutemov.name did gyre and gimble:
>
>  >> Меня практически убедили. А когда мы сможем попробовать результат, а
>  >> то у меня уже давно есть желание грузиться с lvm.
>
>  KAS> Будет анонсиравано дополнительно.
>
> А где смотреть in-progress?

git://git.altlinux.org/people/legion/public/make-initrd.git
git://git.altlinux.org/people/legion/public/mkinitramfs.git

Это два прототипа. Какой из них будет жить пока не решили. Думаю, скоро
определимся. Высказывайте свои прдпочтения.

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

[Led]

On Friday 22 May 2009 16:45:27 Kirill A. Shutemov wrote:
> 2009/5/22 Dmitry M. Maslennikov <maslennikovdm@gmail.com>:
> > 22 мая 2009 г. 17:17 пользователь Alexey Gladkov <legion@altlinux.ru> 
написал:
> >> ...
> >
> > Меня практически убедили. А когда мы сможем попробовать результат, а
> > то у меня уже давно есть желание грузиться с lvm.
>
> Будет анонсиравано дополнительно.
>
> > Кроме того для отладки очень удобно иметь жирный initrd, так что не
> > плохо было бы заиметь модуль, который сразу добавит в initrd bash и
> > все что нужно для нормальной работы, а то в текущем очень сложно
> > понять в чем проблема, когда он выкидывает в консоль из-за недостатка
> > утилит.
>
> Подробней, пожалуйста. Каких именно утилит вам нехватает? Лично мне
> нехватало ls. legion@ написал мне маленький ls :)

А почему бы не влючить было его в УЖЕ существующем в initrd busybox?


-- 
Led

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

[Led]

On Friday 22 May 2009 16:49:27 Michael Shigorin wrote:
> On Fri, May 22, 2009 at 04:45:27PM +0300, Kirill A. Shutemov wrote:
> > Подробней, пожалуйста. Каких именно утилит вам нехватает? Лично
> > мне нехватало ls. legion@ написал мне маленький ls :)
>
> Некоторые из нас выкручивались echo * (echo /lib/modules/*),
> но иметь mkinitrd-module-debug и комфорт в виде ls и поддержки
> readline в такие вечера даже не мечталось...

Зачем "мечтать", когда парой кликов на клавиатуре можно поправить конфиг 
busybox'а, добавив в него ls?

-- 
Led

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

[Dmitry M. Maslennikov]

22 мая 2009 г. 18:03 пользователь Led <ledest@gmail.com> написал:
>> Подробней, пожалуйста. Каких именно утилит вам нехватает? Лично мне
>> нехватало ls. legion@ написал мне маленький ls :)
>
> А почему бы не влючить было его в УЖЕ существующем в initrd busybox?
Я могу ошибаться, но busybox для initrd был собран без поддержки
многих команд, в частности без ls.

--
Dmitry M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

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

[Kirill A. Shutemov]

2009/5/22 Led <ledest@gmail.com>:
> On Friday 22 May 2009 16:45:27 Kirill A. Shutemov wrote:
>> 2009/5/22 Dmitry M. Maslennikov <maslennikovdm@gmail.com>:
>> > 22 мая 2009 г. 17:17 пользователь Alexey Gladkov <legion@altlinux.ru>
> написал:
>> >> ...
>> >
>> > Меня практически убедили. А когда мы сможем попробовать результат, а
>> > то у меня уже давно есть желание грузиться с lvm.
>>
>> Будет анонсиравано дополнительно.
>>
>> > Кроме того для отладки очень удобно иметь жирный initrd, так что не
>> > плохо было бы заиметь модуль, который сразу добавит в initrd bash и
>> > все что нужно для нормальной работы, а то в текущем очень сложно
>> > понять в чем проблема, когда он выкидывает в консоль из-за недостатка
>> > утилит.
>>
>> Подробней, пожалуйста. Каких именно утилит вам нехватает? Лично мне
>> нехватало ls. legion@ написал мне маленький ls :)
>
> А почему бы не влючить было его в УЖЕ существующем в initrd busybox?

Сейчас busybox в mkinitrd не используется.

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

[Vladimir Lettiev]

Led пишет:
> On Friday 22 May 2009 16:49:27 Michael Shigorin wrote:
>> On Fri, May 22, 2009 at 04:45:27PM +0300, Kirill A. Shutemov wrote:
>>> Подробней, пожалуйста. Каких именно утилит вам нехватает? Лично
>>> мне нехватало ls. legion@ написал мне маленький ls :)
>> Некоторые из нас выкручивались echo * (echo /lib/modules/*),
>> но иметь mkinitrd-module-debug и комфорт в виде ls и поддержки
>> readline в такие вечера даже не мечталось...
> 
> Зачем "мечтать", когда парой кликов на клавиатуре можно поправить конфиг 
> busybox'а, добавив в него ls?

Да, действительно, в busybox есть практически всё что нужно. Но
частенько в уже готовом busybox отсутствуют нужные утилиты. Недавно
пересобирал debain'овский busybox, добавляя findfs, switch_root.
Если я не ошибаюсь busybox можно собрать с uclibc, тогда он будет совсем
крохотный.

-- 
Vladimir Lettiev aka crux

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

[Kirill A. Shutemov]

2009/5/22 Vladimir Lettiev <thecrux@gmail.com>:
> Led пишет:
>> On Friday 22 May 2009 16:49:27 Michael Shigorin wrote:
>>> On Fri, May 22, 2009 at 04:45:27PM +0300, Kirill A. Shutemov wrote:
>>>> Подробней, пожалуйста. Каких именно утилит вам нехватает? Лично
>>>> мне нехватало ls. legion@ написал мне маленький ls :)
>>> Некоторые из нас выкручивались echo * (echo /lib/modules/*),
>>> но иметь mkinitrd-module-debug и комфорт в виде ls и поддержки
>>> readline в такие вечера даже не мечталось...
>>
>> Зачем "мечтать", когда парой кликов на клавиатуре можно поправить конфиг
>> busybox'а, добавив в него ls?
>
> Да, действительно, в busybox есть практически всё что нужно. Но
> частенько в уже готовом busybox отсутствуют нужные утилиты. Недавно
> пересобирал debain'овский busybox, добавляя findfs, switch_root.
> Если я не ошибаюсь busybox можно собрать с uclibc, тогда он будет совсем
> крохотный.

Мы строим initrd вокруг klibc. Собрать busybox с klibc, думаю, будет не
тривиально. И не думаю, что нужно.

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

[Led]

On Friday 22 May 2009 17:26:27 Kirill A. Shutemov wrote:
> 2009/5/22 Vladimir Lettiev <thecrux@gmail.com>:
> > Led пишет:
> >> On Friday 22 May 2009 16:49:27 Michael Shigorin wrote:
> >>> On Fri, May 22, 2009 at 04:45:27PM +0300, Kirill A. Shutemov wrote:
> >>>> Подробней, пожалуйста. Каких именно утилит вам нехватает? Лично
> >>>> мне нехватало ls. legion@ написал мне маленький ls :)
> >>>
> >>> Некоторые из нас выкручивались echo * (echo /lib/modules/*),
> >>> но иметь mkinitrd-module-debug и комфорт в виде ls и поддержки
> >>> readline в такие вечера даже не мечталось...
> >>
> >> Зачем "мечтать", когда парой кликов на клавиатуре можно поправить конфиг
> >> busybox'а, добавив в него ls?
> >
> > Да, действительно, в busybox есть практически всё что нужно. Но
> > частенько в уже готовом busybox отсутствуют нужные утилиты. Недавно
> > пересобирал debain'овский busybox, добавляя findfs, switch_root.
> > Если я не ошибаюсь busybox можно собрать с uclibc, тогда он будет совсем
> > крохотный.
>
> Мы строим initrd вокруг klibc. Собрать busybox с klibc, думаю, будет не
> тривиально.

Врядли получится. О чём разработчики busybox прямо и заявляют. Рекомендуют 
uClibc и (AFAIR) dietlibc

> И не думаю, что нужно. 

-- 
Led

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

[Led]

On Friday 22 May 2009 17:11:34 Kirill A. Shutemov wrote:
> 2009/5/22 Led <ledest@gmail.com>:
> > On Friday 22 May 2009 16:45:27 Kirill A. Shutemov wrote:
> >> 2009/5/22 Dmitry M. Maslennikov <maslennikovdm@gmail.com>:
> >> > 22 мая 2009 г. 17:17 пользователь Alexey Gladkov <legion@altlinux.ru>
> >
> > написал:
> >> >> ...
> >> >
> >> > Меня практически убедили. А когда мы сможем попробовать результат, а
> >> > то у меня уже давно есть желание грузиться с lvm.
> >>
> >> Будет анонсиравано дополнительно.
> >>
> >> > Кроме того для отладки очень удобно иметь жирный initrd, так что не
> >> > плохо было бы заиметь модуль, который сразу добавит в initrd bash и
> >> > все что нужно для нормальной работы, а то в текущем очень сложно
> >> > понять в чем проблема, когда он выкидывает в консоль из-за недостатка
> >> > утилит.
> >>
> >> Подробней, пожалуйста. Каких именно утилит вам нехватает? Лично мне
> >> нехватало ls. legion@ написал мне маленький ls :)
> >
> > А почему бы не влючить было его в УЖЕ существующем в initrd busybox?
>
> Сейчас busybox в mkinitrd не используется.

А зря. В текущем busybox'е даже лёгкий заменитель udev есть.

-- 
Led

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

[Kirill A. Shutemov]

2009/5/22 Led <ledest@gmail.com>:
> On Friday 22 May 2009 17:11:34 Kirill A. Shutemov wrote:
>> 2009/5/22 Led <ledest@gmail.com>:
>> > On Friday 22 May 2009 16:45:27 Kirill A. Shutemov wrote:
>> >> 2009/5/22 Dmitry M. Maslennikov <maslennikovdm@gmail.com>:
>> >> > 22 мая 2009 г. 17:17 пользователь Alexey Gladkov <legion@altlinux.ru>
>> >
>> > написал:
>> >> >> ...
>> >> >
>> >> > Меня практически убедили. А когда мы сможем попробовать результат, а
>> >> > то у меня уже давно есть желание грузиться с lvm.
>> >>
>> >> Будет анонсиравано дополнительно.
>> >>
>> >> > Кроме того для отладки очень удобно иметь жирный initrd, так что не
>> >> > плохо было бы заиметь модуль, который сразу добавит в initrd bash и
>> >> > все что нужно для нормальной работы, а то в текущем очень сложно
>> >> > понять в чем проблема, когда он выкидывает в консоль из-за недостатка
>> >> > утилит.
>> >>
>> >> Подробней, пожалуйста. Каких именно утилит вам нехватает? Лично мне
>> >> нехватало ls. legion@ написал мне маленький ls :)
>> >
>> > А почему бы не влючить было его в УЖЕ существующем в initrd busybox?
>>
>> Сейчас busybox в mkinitrd не используется.
>
> А зря. В текущем busybox'е даже лёгкий заменитель udev есть.

А вот об mdev мы думали. Посмотрим.

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

[Michael Shigorin]

On Fri, May 22, 2009 at 05:05:11PM +0300, Led wrote:
> > > Подробней, пожалуйста. Каких именно утилит вам нехватает?
> > > Лично мне нехватало ls. legion@ написал мне маленький ls :)
> > Некоторые из нас выкручивались echo * (echo /lib/modules/*),
> > но иметь mkinitrd-module-debug и комфорт в виде ls и поддержки
> > readline в такие вечера даже не мечталось...
> Зачем "мечтать", когда парой кликов на клавиатуре можно
> поправить конфиг busybox'а, добавив в него ls?

Видишь ли, в тех случаях это бывало совсем поздно.
Да и раскрытия звёздочки хватало.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Alexey Gladkov]

On 22.05.2009 18:42, Led wrote:
>>> А почему бы не влючить было его в УЖЕ существующем в initrd busybox?
>>
>> Сейчас busybox в mkinitrd не используется.
> 
> А зря. В текущем busybox'е даже лёгкий заменитель udev есть.

Вот только с такой заменой предётся сделать одно из двух: переписать
всё что сейчас у нас в initrd есть на busybox-utils или портировать
утилиты из klibc на другую libc. Первое через чур... тем более что
утилиты из klibc очень хорошо оптимизированы под свою задачу. Второй
вариант удвоит размер initrd (если использовать glibc). Если
портировать на что-то другое, то размер будет меньше, а работы по
портированию гораздо больше.

Мне кажется, что утилиты напрямую не относящиеся к процессу загрузки
не стоят таких усилий.

-- 
Rgrds, legion

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

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

On Fri, May 22, 2009 at 05:49:59PM +0400, Dmitry M. Maslennikov wrote:
>> Подробней, пожалуйста. Каких именно утилит вам нехватает? Лично мне
>> нехватало ls. legion@ написал мне маленький ls :)
DMM> Сейчас уже не помню. Помню только, что когда появлялась задача, то
DMM> просто не знаешь, как сделать то или иное действие, потому что нет
DMM> практически ничего.

Интересно, а есть какие-то противопоказания положить туда (по желанию)
busybox?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]


Twas brillig at 01:16:39 24.05.2009 UTC+04 when mithraen@altlinux.ru did gyre and gimble:

 DMM>> Сейчас уже не помню. Помню только, что когда появлялась задача,
 DMM>> то просто не знаешь, как сделать то или иное действие, потому что
 DMM>> нет практически ничего.

 ДС> Интересно, а есть какие-то противопоказания положить туда (по
 ДС> желанию) busybox?

Он на klibc не соберётся. Так что либо glibc+busybox (жирно), либо
uclibc-шный тулчейн собирать.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 834 bytes --]

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

[Kirill A. Shutemov]

2009/5/24 Денис Смирнов <mithraen@altlinux.ru>:
> On Fri, May 22, 2009 at 05:49:59PM +0400, Dmitry M. Maslennikov wrote:
>>> Подробней, пожалуйста. Каких именно утилит вам нехватает? Лично мне
>>> нехватало ls. legion@ написал мне маленький ls :)
> DMM> Сейчас уже не помню. Помню только, что когда появлялась задача, то
> DMM> просто не знаешь, как сделать то или иное действие, потому что нет
> DMM> практически ничего.
>
> Интересно, а есть какие-то противопоказания положить туда (по желанию)
> busybox?

Ради одной-двух утилит проще положить эти утилиты, пусть собраные с glibc,
чем ложить busybox с кучей ненужного.

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

[Led]

On Sunday, 24 May 2009 00:21:46 Mikhail Gusarov wrote:
> Twas brillig at 01:16:39 24.05.2009 UTC+04 when mithraen@altlinux.ru did
> gyre and gimble:
>
>  DMM>> Сейчас уже не помню. Помню только, что когда появлялась задача,
>  DMM>> то просто не знаешь, как сделать то или иное действие, потому что
>  DMM>> нет практически ничего.
>
>  ДС> Интересно, а есть какие-то противопоказания положить туда (по
>  ДС> желанию) busybox?
>
> Он на klibc не соберётся. Так что либо glibc+busybox (жирно), либо
> uclibc-шный тулчейн собирать.

А этот пресловутый "uclibc-шный тулчейн" - это не полдюжины мелких патчей на 
gcc+binutils?

-- 
Led

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

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

On Sun, May 24, 2009 at 12:36:52AM +0300, Kirill A. Shutemov wrote:

>> Интересно, а есть какие-то противопоказания положить туда (по желанию)
>> busybox?
KAS> Ради одной-двух утилит проще положить эти утилиты, пусть собраные с glibc,
KAS> чем ложить busybox с кучей ненужного.

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

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Max Ivanov]

> оперативной памяти значения настолько не имеют. А вот удобство -- имеет.

По мне так rescue initrd бывает очень нехватает! С сетью, ssh, fdisk,
rsync, vim и пр.

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

[Michael Shigorin]

On Sun, May 24, 2009 at 08:58:01AM +0400, Max Ivanov wrote:
> > оперативной памяти значения настолько не имеют. А вот удобство -- имеет.
> По мне так rescue initrd бывает очень нехватает! С сетью, ssh,
> fdisk, rsync, vim и пр.

Ну не в качестве же штатного.  Это если даже загрузиться 
с CD/DVD/USB/сети объективно не судьба.

Вообще мысля делать "в сторонку" для текущего загружаемого 
по умолчанию ядра более толстый initrd (правда, я скорее думал
про стораджевые ядерные модули, чтоб легче переживать смену
контроллера дисков) и вписывать его как initrd-failsafe.img
уже приходила, но ничего не застав, ушла.

Может, мне тогда хотя бы на mkinitrd хотелку повесить?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Afanasov Dmitry]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

On Sun, May 24, 2009 at 01:18:35PM +0300, Michael Shigorin wrote:
> On Sun, May 24, 2009 at 08:58:01AM +0400, Max Ivanov wrote:
> > > оперативной памяти значения настолько не имеют. А вот удобство -- имеет.
> > По мне так rescue initrd бывает очень нехватает! С сетью, ssh,
> > fdisk, rsync, vim и пр.
> 
> Ну не в качестве же штатного.  Это если даже загрузиться 
> с CD/DVD/USB/сети объективно не судьба.
...
> контроллера дисков) и вписывать его как initrd-failsafe.img
> уже приходила, но ничего не застав, ушла.
кстати, мысль. пуст базовый initrd остается худым и тонким, чуть ли не с
тупым insmod. а вот failsafe да, хоть с ssh-сервером :)

-- 
 С уважением
 Афанасов Дмитрий

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Marat Khayrullin]

В сообщении от Sunday 24 May 2009 14:31:19 Afanasov Dmitry написал(а):
> кстати, мысль. пуст базовый initrd остается худым и тонким, чуть ли не с
> тупым insmod. а вот failsafe да, хоть с ssh-сервером :)
> 

А мне понравилось в openSUSE возможность удалённой переинсталяции с помощью встроенного ssh-сервера:

title install from net
    kernel (hd0,1)/install/boot/x86_64/loader/linux ssh=1 sshpassword=password \  install=http://download.opensuse.org/distribution/11.1/repo/oss/
    initrd (hd0,1)/install/boot/x86_64/loader/initrd

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

[Wartan Hachaturow]

2009/5/24 Led <ledest@gmail.com>:
> А этот пресловутый "uclibc-шный тулчейн" - это не полдюжины мелких патчей на
> gcc+binutils?

Плюс сама uclibc. Плюс далеко не всегда gcc с ней собирается.

-- 
Regards, Wartan.