From: Leonid Krivoshein <klark.devel@gmail.com> To: make-initrd@lists.altlinux.org Subject: Re: [make-initrd] make pseudo GUI from bootchain-interactime common feature Date: Mon, 28 Jun 2021 19:34:02 +0300 Message-ID: <3d683f36-0115-499b-6815-7b8d561e3351@gmail.com> (raw) In-Reply-To: <20210628160624.gglemxc5st6ucqog@example.org> 28.06.2021 19:06, Alexey Gladkov пишет: > On Mon, Jun 28, 2021 at 05:43:48PM +0300, Leonid Krivoshein wrote: >>> [...] >>> Леонид, а у тебя какие планы на bootchain-interactive ? >> Планы -- как можно быстрее интегрировать всю связку в make-initrd. >> >> Идея переместить bootchain-interactive на верхний уровень и сделать частью >> make-initrd, независимой от bootchain была с самого начала, поэтому весь код >> этой фичи так написан, что он совсем не зависит от других модулей bootchain. >> Есть, правда, пара "но". Именно bootchain-interactive, как концепция, >> создана наспех, для написания остального кода altboot, поэтому её хорошо бы >> поревьювить именно в части общей пригодности интерфейса и арифметики. > Ну это не проблема. > > Кстати, однажды Олег Нестеров подсказал мне вот такой код: > > ttysz() > { > local esc cols rows > echo -ne "\e[s\e[1000;1000H\e[6n\e[u" > IFS=';[' read -s -t2 -dR esc rows cols || > { echo >&2 'ttysz() FAILED'; return 0; } > stty rows $rows cols $cols > } > > Думаю, что его можно модифицировать и использовать для твоих нужд. Для определения размеров TTY и для сохранения/восстановления консоли в первых реализациях я тоже использовал stty. Но потом обнаружил, что сохранение/восстановление поддерживается далеко не всеми TTY, поэтому использовал отдельную консоль, которую просто чищу за собой, а определение размера не проблема, dialog'ом её тоже можно решать достаточно надёжно. Если оставить как сейчас -- не будет лишней зависимости. >> Второй момент куда более важный. bootchain (изначально pipeline) мне видится >> как решение проблемы синхронизации последовательности выполняемых действий >> независимо от последовательности входящих событий. Так, фича overlayroot в >> bootchain сейчас может "гоняться" с фичей "resume" make-initrd. С ней вообще >> много чего может "гоняться". > Я специально не трогал pipeline, чтобы не ломать тебе ничего. Я решал > примерно такую же проблему с kickstart. На время работы таких фич как > kickstart и pipeline нужно выключать обработку эвентов в ueventd. Но не > всех, а только тех, что отвечают за разбор того, что пришло из udev. > > Это реализовано в kickstart. Перед запуском kickstart ставит на паузу > очередь udev и снимает с паузы после обработки сценария (если управление > возвращается initramfs). Насколько это хорошее решение пока не знаю, но > это работает. > > Примерно это же можно делать и в bootchain т.е. блокировать обработку > очереди udev эвентов при заходе в условный main_loop. > Интересно, надо будет посмотреть повнимательней. >> Было бы здорово сделать весь bootchain частью >> интерфейса make-initrd, и чтобы код разных его фич можно было более тесно >> интегрировать с bootchain, при необходимости. В первую очередь network, да и >> всё, что можно конфигурировать через диалоги, запрос паролей не только на >> токены, но и crypto-luks. Но это такие мечты и отдалённые задачи, наверняка >> решаемые уже после того, как удастся заапстримить bootchain. > Ты наверно имел в виду не весь bootchain, а фичу с диалогами ? Нет, имел ввиду весь bootchain. И даже более широко. Было бы хорошо в самом make-initrd иметь наряду с параллельной событийно-ориентированной обработкой интерфейс, позволяющий выполнять что угодно последовательно, не только с диалогами. pipeline/bootchain эту задачу решают, но возможно на уровне интерфейса make-initrd её можно решить ещё лучше, а bootchain со своими "входами" и "выходами" сделать частным использованием этого общего интерфейса make-initrd. Некоторые вещи нужно обрабатывать последовательно, а не как карта ляжет. Например resume, fsck, создание оверлеев... > Мне сразу в голову пришло примерно как это сделано в dpkg-configure. У нас > же примерно такая же задача. У нас есть параметры, которые могут быть > заданы, если нет, то о них нужно спросить или же использовать некие > дефолты если возможно. Нужно будет поизучать как это у них уже > реализовано. Да, классная идея, но это уже следующий уровень интеллекта. Не уверен, что сходу достижимый, по крайней мере, без изменения интерфейса регистрируемых аргументов make-initrd. Но если отталкиваться не от параметров make-initrd, а от того, как данные описываются в d-i (dpkg-configure использует эту модель, если не ошибаюсь), то да, но скорее всего диалоги там не автоматически формируются, а тоже используют библиотеку доступа к этим данным. Давно изучал вопрос, поэтому плохо помню, что там и как. >> При написании документации (уже около 30 страниц) обнаружил пару >> архитектурных изъяна в bootchain и сейчас их уже почти исправил, но пока не >> выгрузил обновления. При этом добился полной совместимости с pipeline, для >> его пользователей теперь вообще ничего можно не менять. С ipmi/novga >> консолями и utf8 тоже пока остаётся вопрос, как решать, ещё не заходил на >> эту задачу. И останется всё ещё раз прогнать на стендах, так-то оно вроде >> работало. После этого можно переходить к движению в апстрим в твоим >> участием! :-) > Ok. Нет проблем :) > -- Best regards, Leonid Krivoshein.
next prev parent reply other threads:[~2021-06-28 16:34 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-28 14:01 ` Alexey Gladkov 2021-06-28 14:43 ` Leonid Krivoshein 2021-06-28 16:06 ` Alexey Gladkov 2021-06-28 16:34 ` Leonid Krivoshein [this message] 2021-06-28 18:48 ` Alexey Gladkov 2021-06-28 19:43 ` Leonid Krivoshein 2021-06-28 23:38 ` Alexey Gladkov 2021-06-29 0:50 ` Leonid Krivoshein 2021-06-29 8:28 ` Alexey Gladkov 2021-06-28 16:39 ` Leonid Krivoshein 2021-08-22 13:09 ` Leonid Krivoshein 2021-06-28 15:57 ` 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=3d683f36-0115-499b-6815-7b8d561e3351@gmail.com \ --to=klark.devel@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