From: Alexey Gladkov <gladkov.alexey@gmail.com> To: make-initrd@lists.altlinux.org Subject: Re: [make-initrd] bootchain+altboot: у меня есть план Date: Wed, 1 Sep 2021 01:10:40 +0200 Message-ID: <20210831231040.uarlc6yp3psx4zld@example.org> (raw) In-Reply-To: <5d28c168-d52b-326c-ddf1-64e636e89c7b@gmail.com> 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
next prev parent reply other threads:[~2021-08-31 23:10 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-21 19:14 Leonid Krivoshein 2021-08-22 19:29 ` Leonid Krivoshein 2021-08-23 9:29 ` Alexey Gladkov 2021-08-23 11:04 ` Leonid Krivoshein 2021-08-23 11:48 ` Alexey Gladkov 2021-08-24 1:16 ` Leonid Krivoshein 2021-08-30 17:14 ` Leonid Krivoshein 2021-08-30 18:13 ` Alexey Gladkov 2021-08-30 19:54 ` Leonid Krivoshein 2021-08-31 7:40 ` Alexey Gladkov 2021-08-31 22:02 ` Leonid Krivoshein 2021-08-31 23:10 ` Alexey Gladkov [this message] 2021-09-15 21:19 ` Leonid Krivoshein 2021-08-23 11:19 ` Leonid Krivoshein
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210831231040.uarlc6yp3psx4zld@example.org \ --to=gladkov.alexey@gmail.com \ --cc=make-initrd@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Make-initrd development discussion This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \ make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com public-inbox-index make-initrd Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.make-initrd AGPL code for this site: git clone https://public-inbox.org/public-inbox.git