[devel] rfc: propagator, klibc, plymouth, make-initrd?

[devel] rfc: propagator, klibc, plymouth, make-initrd?

[Anton V. Boyarshinov]

Добрый день
В процессе внедрения plymouth взамен устаревшему bootsplash, я оказался
на некотором распутье, связанном с propagator. 
Как известно propagator и всё, что попадает в его initfs сейчас
собирается с klibc. Ощутимая экономия памяти, но в результате мы
получаем в initfs устаревший udev (который, рано или поздно, перестанет
поддерживаться ядрами и уже не поддерживается мантейнером udev) и
невозможность помещения туда произвольных программ (например, plymouth).

Мне видятся 3 пути дальнейшего развития propagator:
1) оставить всё +/- как есть, если надо что-то пометить в initfs,
собирать его статический вариант и помещать в initfs его. Правда, в
общем случае, вся экономия на klibc может потеряться. Ну и проблема
просто откладывается.

2) собрать propagator с glibc, создать инфраструктуру копирования в
initfs всех библиотек, необходимых для того, что там окажется. Заодно
можно получить там более человечный shell. Объём, конечно, увеличится,
но с учётом того, что современный alt linux всё равно не работает на
машинах со столь малым количеством памяти, чтоб это было актуально, это
не кажется мне проблемой

3) вообще отказаться от имеющегося propagator и ре-реализовать его
функциональность на базе make-initrd (вопросы можно dialog-ом
задавать). Лично мне этот вариант кажется наиболее перспективным
(поддержка такого propagator обещает быть проще по причине реализации
на языке более высогого уровня). Но он, очевидно, наиболее трудоёмок.

Есть ли у кого мнения, относительно предпочтительности одного из этих
путей или иные предложения?

Антон

Re: [devel] rfc: propagator, klibc, plymouth, make-initrd?

[Mykola S. Grechukh]

2010/11/23 Anton V. Boyarshinov <>:
> 2) собрать propagator с glibc, создать инфраструктуру копирования в
> initfs всех библиотек, необходимых для того, что там окажется. Заодно
> можно получить там более человечный shell. Объём, конечно, увеличится,
> но с учётом того, что современный alt linux всё равно не работает на
> машинах со столь малым количеством памяти, чтоб это было актуально, это
> не кажется мне проблемой

Когда-то он и собирался с glibc. Статикой, правда, ЕМНИП.

> 3) вообще отказаться от имеющегося propagator и ре-реализовать его
> функциональность на базе make-initrd (вопросы можно dialog-ом
> задавать). Лично мне этот вариант кажется наиболее перспективным
> (поддержка такого propagator обещает быть проще по причине реализации
> на языке более высогого уровня). Но он, очевидно, наиболее трудоёмок.

И, видимо, там же можно будет сделать монтирование оверлея. Так чтобы
на aufs был весь / .

-- 
Mykola Grechukh
RISC Group IT Solutions

Re: [devel] rfc: propagator, klibc, plymouth, make-initrd?

[Ivan Fedorov]

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

"Anton V. Boyarshinov" <boyarsh-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org>
writes:

> Мне видятся 3 пути дальнейшего развития propagator:
> 2) собрать propagator с glibc
>
> 3) вообще отказаться от имеющегося propagator и ре-реализовать его
> функциональность на базе make-initrd
>
> Есть ли у кого мнения, относительно предпочтительности одного из этих
> путей или иные предложения?

IMHO пора уже отказываться тянуть за собой неподдерживаемый софт - людей
и так ни на что не хватает!

Так что IMHO в 6.0 надо идти по пути 2, а потом уже начать путь 3...

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

Re: [devel] rfc: propagator, klibc, plymouth, make-initrd?

[Anton Farygin]

23.11.2010 20:26, Anton V. Boyarshinov пишет:
> 2) собрать propagator с glibc, создать инфраструктуру копирования в
> initfs всех библиотек, необходимых для того, что там окажется. Заодно
> можно получить там более человечный shell. Объём, конечно, увеличится,
> но с учётом того, что современный alt linux всё равно не работает на
> машинах со столь малым количеством памяти, чтоб это было актуально, это
> не кажется мне проблемой
>

Вариант 2 наиболее перспективный, особенно если учесть, что после 
монтирования рута пропагатор из памяти будет удалён.

Вариант 3 может быть и имеет смысл, но явно не сейчас - реализовать весь 
функционал пропагатора понадобиться время, а нам ехать.

Re: [devel] rfc: propagator, klibc, plymouth, make-initrd?

[Anton V. Boyarshinov]

> Есть ли у кого мнения, относительно предпочтительности одного из этих
> путей или иные предложения?
Я придумал и опробовал более тонкое извращение: упаковку init из
propagator в initrd, созданный make-initrd (сведя, таким образом,
большую часть проблем к уже решённым). Макетно оно работает, осталось
продумать как сделать дистрибутивно :D

Антон

Re: [devel] rfc: propagator, klibc, plymouth, make-initrd?

[Michael Shigorin]

On Tue, Nov 23, 2010 at 08:26:38PM +0300, Anton V. Boyarshinov wrote:
> 2) собрать propagator с glibc, создать инфраструктуру копирования в
> initfs всех библиотек, необходимых для того, что там окажется. Заодно
> можно получить там более человечный shell. Объём, конечно, увеличится,
> но с учётом того, что современный alt linux всё равно не работает на
> машинах со столь малым количеством памяти, чтоб это было актуально, это
> не кажется мне проблемой

JFYI, у меня есть минимум один железный хост с 64M RAM.
Хотелось бы пока не выпрыгивать за 128M в качестве минимального
системного требования, но как понимаю, до этого далеко.

> 3) вообще отказаться от имеющегося propagator и ре-реализовать его
> функциональность на базе make-initrd (вопросы можно dialog-ом
> задавать). Лично мне этот вариант кажется наиболее перспективным
> (поддержка такого propagator обещает быть проще по причине реализации
> на языке более высогого уровня). Но он, очевидно, наиболее трудоёмок.

Насколько понимаю, изначально существенной частью
функциональности propagator была функциональность udev по
загрузке нужных модулей (плюс обработка данных для установки
по сети или с HDD).  И эта часть сейчас при загрузке с диска
или флэшки не требуется вовсе, а для сетевого инсталятора
можно выписывать и впрямь отдельно.

> Есть ли у кого мнения, относительно предпочтительности одного
> из этих путей или иные предложения?

Для меня propagator -- чёрный ящик, и если не оставлять работу
над дистрибутивами, то рано или поздно это будет мешать. :)

Дурацкий вопрос -- а как в Fedora, openSUSE, Debian сейчас?

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

Re: [devel] rfc: propagator, klibc, plymouth, make-initrd?

[Anton V. Boyarshinov]

On Fri, 26 Nov 2010 20:39:41 +0200 Michael Shigorin wrote:

> JFYI, у меня есть минимум один железный хост с 64M RAM.
Ты часто на него устанавливаешься? ;)

Кроме того, если мы можем загрузиться из initrd, созданного
make-initrd, то памяти на этой машине достаточно.
> Хотелось бы пока не выпрыгивать за 128M в качестве минимального
> системного требования, но как понимаю, до этого далеко.

Re: [devel] rfc: propagator, klibc, plymouth, make-initrd?

[Michael Shigorin]

On Mon, Nov 29, 2010 at 01:04:17PM +0300, Anton V. Boyarshinov wrote:
> > JFYI, у меня есть минимум один железный хост с 64M RAM.
> Ты часто на него устанавливаешься? ;)

В этом году нет, а вообще дистрибутивы проверял.

> Кроме того, если мы можем загрузиться из initrd, созданного
> make-initrd, то памяти на этой машине достаточно.

И то хорошо.

> > Хотелось бы пока не выпрыгивать за 128M в качестве минимального
> > системного требования, но как понимаю, до этого далеко.

PS: на неделе засовывал что-то из свежих сборок (чуть ли не
altlinux-5.9.9-20101124-centaurus-i586-ru-install-dvd5.iso)
в виртуалку с 64M RAM (+VRAM), встало небыстро, но без проблем.

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

Re: [devel] rfc: propagator, klibc, plymouth, make-initrd?

[Anton Farygin]

05.12.2010 15:37, Michael Shigorin пишет:
> On Mon, Nov 29, 2010 at 01:04:17PM +0300, Anton V. Boyarshinov wrote:
>>> Хотелось бы пока не выпрыгивать за 128M в качестве минимального
>>> системного требования, но как понимаю, до этого далеко.
>
> PS: на неделе засовывал что-то из свежих сборок (чуть ли не
> altlinux-5.9.9-20101124-centaurus-i586-ru-install-dvd5.iso)
> в виртуалку с 64M RAM (+VRAM), встало небыстро, но без проблем.

а ты ради интереса попробуй на 4Tb раздел поставить ;)

я тут игрался с kvm + 4Tb дисками на server-light, впечатления 
удручающие (от ext4, в первую очередь).