On Sun, 13 Sep 2009 14:49:42 +0400
Alexander GQ Gerasiov <gq@cs.msu.su> wrote:
> > Все три проблемы, описанные там явно (устройства в /dev, сетевые
> > интерфейсы и согласование номеров скриптов) я уже разобрал в ответе на
> > то письмо. Причём по построению решения видно, что они могут быть
> > решены в рамках sysvinit.
> Ну так предлагаемое решение как минимум совместимо с sysvinit.
Там явно написано, что инит будет заменён. То есть уже огромные проблемы
с возможными регрессиями при замене.
> > Может есть ещё источник, где проблемы разобраны и обоснована их
> > неразрешимость при наших ограничениях?
> Да проще всё:
>
> загрузка ядра стала событийной, можно тупо ждать пока оно полностью
> инициализируется, потом запустить удев и модютилс и повисеть на
> таймауте 30 секунд, чтобы убедиться, что все устройства запустились.
Не все устройства, а нужные тебе. Т.е. если через 30 секунд так и не
появилось /dev/disk/by-label/jbrown-secret-flash-disk, то ругаться. Если
появилось сразу, то и нечего ждать.
Более того, я считаю необходимым условием то, что когда init мне бодро
сообщил о завершении своей работы запуском xdm, система должна быть
готова к эксплуатации. Чему асинхронность инициализации ну никак не
товарищ.
> Но зачем? Если это мой ноутбук, который мне надо загрузить быстро?
У ноутбука есть кнопка suspend, нажимая которую ты дёргаешь не
/etc/rc?.d/*, а /etc/{suspend,resume}.d/*.
> Зачем запускать что-то последовательно и висеть то на процессоре, то на
> вводе-выводе, если у нас 2, 4, 8 ядер? Давайте распараллелим процесс
> загрузки, будем запускать сервисы и всякие инициализационные скрипты as
> early as possible.
> ...
> Ну и надо минимально напрячь мейтернеров пакетов, предоставляющих
> инит-скрипты.
Ты готов своей репутацией отвечать за то, что все инит-скрипты написаны
и будут писаться без race?
Даже если добавить в полиси строчку "инит-скрипт должен быть написан
так, чтобы позволять параллельное выполнение со другими инит-скриптами",
это не улучшит ситуацию. Система должна быть устойчивой к ошибкам by
design.
> Получается довольно прозрачная с точки зрения концепции идея: есть
> события, генерируемые ядром, есть события типа "сервис X стартовал",
> есть зависимости от событий в стартовой последовательности. И всё.
Если заходить со стороны отладки, то получается трудноотлаживаемая
конструкция. Потому что отследить по линейным логам, на каком из пяти
параллельно запущенных процессов инициализация "грохнулась", весьма и
весьма проблематично.
> И такие системы инициализации уже есть. Но мы говорим о mainline,
> поэтоум на практике всё немножно сложнее: надо оставить совместимость с
> LSB, то есть с system v init, надо решить проблему с тем, что делать,
> если вдруг один из сервисов не смог стартовать и т.д.
Типичный пример современной разработки: создать проблему, а потом её
героически решать.
--
Alexander Galanin
Attachment:
pgp4gVDd7jmiP.pgp
Description: PGP signature