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

[Leonid Krivoshein <klark.devel@gmail.com>]

Привет!


31.08.2021 10:40, Alexey Gladkov пишет:
> On Mon, Aug 30, 2021 at 10:54:35PM +0300, Leonid Krivoshein wrote:
>>>> 24.08.2021 4:16, Leonid Krivoshein пишет:
>>>>> 23.08.2021 14:48, Alexey Gladkov пишет:
>>>>>> On Mon, Aug 23, 2021 at 02:04:06PM +0300, Leonid Krivoshein wrote:
>>>>>>>> [...]
>>>>>>>> Не стоит ли сделать поддержку netconsole глобальной ?
>>>> Полагаю, глобальной должна быть опция nottys и организация захвата и
>>>> освобождения TTY'ов разными фичами. Тогда и вопрос расшаривания консоли
>>>> решается проще.
>>> Я не очень понял про захват tty в том смысле, что ты предлагаешь ?
>> Любая фича, которая хочет использовать конкретный 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, но я не нашёл 
надёжного способа такого определения на шеле.



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

Возможно, ты имеешь ввиду, что все диалоги должны происходить на одной 
консоли, той же, на которую runtime make-initrd выводит сообщения о 
запускаемых службах. Тогда да, можно не думать об отделении процесса 
через IM_exec(), тогда можно не заботиться о TTY'ах, можно блокировать 
консоль через пару console_lock() и console_unlock(), можно не думать о 
netconsole, так как это она и есть. Я это и имел ввиду под возвратом к 
более простой реализации, побочные эффекты которой -- мелькания диалогов 
вперемешку с выводом runtime. Если твоя концепция работы с TTY'ами будет 
именно такой, значит, под неё и придётся переделывать нынешнюю 
реализацию: #283645.



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

Отлично!



> [...]
> Так. Я понял, что я совсем не в контексте и не могу продуктивно обсуждать,
> то что не видел. Присылай патчи, мы их обсудим, а потом подумаем, что
> нужно от остального кода.

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


-- 
Best regards,
Leonid Krivoshein.