From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 1 Sep 2021 01:10:40 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: <20210831231040.uarlc6yp3psx4zld@example.org> References: <121fd50e-cce3-b28b-f05c-0efaa4606d7b@gmail.com> <20210823092907.yyy6gxk6yjzrsbvx@example.org> <20210823114813.d3zjjeyh2xb7xmec@example.org> <9c42252f-bfb3-0e73-0bf2-12ea40de2144@gmail.com> <20210830181307.63hv45lgcgyxyaff@example.org> <21a4dd2e-f6b5-a8d3-f31c-7c62c41f1071@gmail.com> <20210831074046.aadrpzt5dp4apxqq@example.org> <5d28c168-d52b-326c-ddf1-64e636e89c7b@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5d28c168-d52b-326c-ddf1-64e636e89c7b@gmail.com> Subject: Re: [make-initrd] =?utf-8?b?Ym9vdGNoYWluK2FsdGJvb3Q6INGDINC80LXQvdGP?= =?utf-8?b?INC10YHRgtGMINC/0LvQsNC9?= X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 23:10:42 -0000 Archived-At: List-Archive: 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