[make-initrd] bootchain+altboot: у меня есть план

[Alexey Gladkov]

On Wed, Sep 01, 2021 at 01:02:09AM +0300, Leonid Krivoshein wrote:
> > > Любая фича, которая хочет использовать конкретный TTY или общий
> > > /dev/console, вроде как не должна это делать на своё усмотрение. Хорошо бы
> > > иметь общий механизм захвата и освобождения указанной TTY, например, в
> > > initrd-sh-functions:
> > В rdshell-sh-functions уже есть console_lock/console_unlock, которые
> > уже применяются в коде. Правда, выбора номера терминала они не
> > предусматривают.
> > 
> > > lock_tty(n)
> > > unlock_tty(n)
> > > 
> > > где n, номер VT либо 0 для /dev/console и netconsole.
> > > 
> > > иначе асинхронная работа двух разных фич с одним терминалом не будет
> > > согласованной.
> > А как код будет понимать, что ему лочить N или 0 ? Я всё ещё не понимаю,
> > что будет в netconsole.
> 
> В случае netconsole у нас вообще нет TTY'ов. Я даже не понял, почему их нет.
> Поэтому логично вызов lock_tty(n) переадресовывать на console_lock() при
> nottys в /proc/cmdline. Ещё лучше, найти способ авто-определения netconsole
> и выставлять внутренне NOTTYS=1, если нет TTY'ов даже, если это не указано в
> /proc/cmdline, но я не нашёл надёжного способа такого определения на шеле.

Я не уверен, но если попытаться свести lock_tty к console_lock, то в
некоторых случаях можно будет получить deadlock.

> > > [...]
> > > API должен быть написан исходя из конкретных потребностей, а не чтобы просто
> > > был. Кому и как может потребоваться API для работы с диалогами ввода/вывода?
> > > Я исхожу из того, что "пользователи" API -- это фичи make-initrd, это
> > > работающий код демонов, вывод которых уже куда-то перенаправлен, например в
> > > журнал или на /dev/console. Или это обработчики событий. Вдруг, им
> > > недостаточно события, а надо ещё и у пользователя что-то спросить? А может
> > > они ждут события, чтобы после него спросить нечто у пользователя? Например,
> > > PIN-код на вставленный токен.
> > Так уже есть фичи, которые спрашивают пин и они пользуются console_lock.
> 
> Возможно, ты имеешь ввиду, что все диалоги должны происходить на одной
> консоли, той же, на которую runtime make-initrd выводит сообщения о
> запускаемых службах. Тогда да, можно не думать об отделении процесса через
> IM_exec(), тогда можно не заботиться о TTY'ах, можно блокировать консоль
> через пару console_lock() и console_unlock(), можно не думать о netconsole,
> так как это она и есть. Я это и имел ввиду под возвратом к более простой
> реализации, побочные эффекты которой -- мелькания диалогов вперемешку с
> выводом runtime. Если твоя концепция работы с TTY'ами будет именно такой,
> значит, под неё и придётся переделывать нынешнюю реализацию: #283645.

Я текущая реализация использует /dev/console и console_lock/console_unlock
именно потому, что я не хотел полагаться на локальные tty. У меня нет
тестов, но я всегда старался думать о netconsole.

Совершенно не обязательно иметь мелькание диалогов вперемешку с
сообщениями. Я делал реализацию quiet, которая вроде как работает и не
мешает показывать сплеэш. Основную консоль можно сделать чистой и
перенаправить сообщения в файл или отдельные логи.

По сути я не вижу большой разницы между plymouth и диалогами bootchain.

> > [...]
> > > > Для синхронизации с kbd можно поступить как с сетью и сделать сервис
> > > > kbd-ready, который можно ставить в зависимости других сервисов.
> > > А вот тут уже я не понял.))
> > На runlevel 3 запускаются сервисы. Чтобы синхронизировать свой запуск с
> > асинхронными событиями такими как поднятие сети был сделан псевдосервис
> > network-up (он приезжает с фичей network). Сервисы, которым нужна сеть
> > ставят его в зависимости и будут запущены после него.
> > 
> > Такую же штуку можно сделать и для настройки терминалов. В этом случае
> > можно будет стартовать сервис после того как фича kbd отработает.
> 
> Отлично!

Ок. Тогда так и сделаем.

> > [...]
> > Так. Я понял, что я совсем не в контексте и не могу продуктивно обсуждать,
> > то что не видел. Присылай патчи, мы их обсудим, а потом подумаем, что
> > нужно от остального кода.
> 
> Если нужно пораньше фичу interactive (pseudo-gui), то вот: #283645. Она уже
> давно оттестирована и не меняется. На днях с ней будут делаться регулярки, и
> тестирование будет иметь более широкий охват на железе. Если всё вместе, то
> уже работаю над этим всё свободное время, благо теперь у меня его больше.
> Для обсуждения концепции работы с TTY'ми можем организовать конфколл, Антона
> Мидикова позвать, надо ведь разные архитектуры учесть...

Я только за. Пишите, когда у вас есть время и сможем организоваться.

-- 
Rgrds, legion