From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 31 Aug 2021 09:40:46 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: <20210831074046.aadrpzt5dp4apxqq@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <21a4dd2e-f6b5-a8d3-f31c-7c62c41f1071@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 07:40:48 -0000 Archived-At: List-Archive: 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 наловил кучу дистрибутивных багов, не связанных с > > > > > > make-initrd. Не все умеют с ней работать, даже grub работает лишь в > > > > > > определённых условиях, в зависимости от образа. Нужно сначала > > > > > > понять, то ли > > > > > > я вообще сделал, что требовалось? Мне не удалось найти надёжного > > > > > > способа > > > > > > автоматического определения netconsole, поэтому пришлось ввести > > > > > > ещё один > > > > > > параметр nottys. Но вообще реализация получилась очень простой > > > > > > и, на первый > > > > > > взгляд, рабочей, и даже код определения размеров консоли > > > > > > пришёлся кстати. > > > > > > :-) > > > > > Надо будет посмотреть на этот код. Очень интересно. > > > > #283645 -- так быстрее. И... sorry for my English! )) > > > > > > > Допустил в README опечатку в конце. Но лучше этот код немного доделать. В > > > исходной реализации не было разделения процесса на две части, перевода на > > > передний план. Просто запрашивалась активация и выводились виджеты. В > > > последней реализации, которую пришлось существенно пересмотреть, всё сделано > > > для того, чтобы диалоги не мелькали лишний раз без надобности, чтобы их > > > вывод не смешивался с выводом на tty1 от демонов, который организует > > > make-initrd. > > > > > > Особенно при использовании nottys и rdshell хорошо заметно, как на > > > единственной текущей консоли дерутся за ввод и вывод rdshell, виджеты и > > > вывод от демонов. Возможно тут не хватает блокировок. > > rdshell и вывод на консоль это отдельная сложная задача. На консоль пишут > > не только сервисы, но и утилиты, которые про notty и вообще всё это ничего > > не знают. > > > > Есть два варианта: > > > > * перенаправить вывод сервисов в лог файлы. > > * использовать для их вывода другой tty, но в этом случае будут проблемы с > > serial/net console. > > > Думаю, будет не сложно добавить альтернативный вариант активации с > > > использованием текущей консоли, без разделения процесса через IM_exec(). > > Я вот этого не понял. > > API должен быть написан исходя из конкретных потребностей, а не чтобы просто > был. Кому и как может потребоваться API для работы с диалогами ввода/вывода? > Я исхожу из того, что "пользователи" API -- это фичи make-initrd, это > работающий код демонов, вывод которых уже куда-то перенаправлен, например в > журнал или на /dev/console. Или это обработчики событий. Вдруг, им > недостаточно события, а надо ещё и у пользователя что-то спросить? А может > они ждут события, чтобы после него спросить нечто у пользователя? Например, > PIN-код на вставленный токен. Так уже есть фичи, которые спрашивают пин и они пользуются console_lock. > При написании bootchain я всё это прошёл и по настоянию Антона Мидюкова > капитально переделал работу с консолью. > > Изначально идея была простая. В скрипте, в котором нужны виджеты, вызывается > IM_activate(). И далее в нём же выводятся диалоги. Чтобы сохранить и потом > восстановить tty1, занятой выводом сообщений make-initrd и демонов, ввод и > вывод внутри IM_activate() перенаправлялся на /dev/tty2 и туда производилось > немедленное переключение через chvt 2. Любой другой скрипт делал всё то же > самое, но повторно переключение на TTY2 не выполнялось, активация консоли > делалась лишь единожды. > > Причина переработки всей концепции заключалась в том, что если нет ввода, а > есть только вывод и этот вывод в процессе загрузки выполняется очень быстро > (2-3 секунды на практике), то и незачем видеть все эти лишние мелькания на > экране. У нас даже баг такой открыт на propagator -- ведь у него тоже это > имело место, причём он, в отличие от altboot, работал на tty1. > > Чтобы реализовать отложенную активацию консоли, процесс открытия терминала > tty2 и его инициализацию пришлось разделить на два процесса. IM_exec() > инициирует создание tty2 и запуска в нём указанного процесса, возможно > перезапустить тут сам демон с нужным параметром. А уже будучи запущенным > порождённый процесс вызывает IM_activate(). > > Такая реализация годится для bootchain, но чтобы переносить её на уровень > выше в make-initrd нужно заново определить всю концепцию диалогового > ввода/вывода. Я бы исходил из того, что: > > 1) По возможности, диалоги в/в не должны работать с tty1, т.к. эта консоль > для сообщений make-initrd. > 2) Не нужно иметь несколько tty'ов для диалогов, достаточно всего одного, > например, tty2. > 3) В случае netconsole все работают с единственной текущей консолью, что > требует вызова reset после работы с программой dialog, иначе теряется > клавиатурный ввод (не знаю, почему). Я бы использовал тут же блокировку для > процессов вывода сообщений и захвата клавиатурного ввода. > 4) Хорошо бы предусмотреть отложенное переключение на tty2 для диалогов > вывода. Но для ошибок и диалогов ввода оно должно быть немедленным. > 5) Хороший вопрос -- кто и когда должен освободить консоль tty2? Это > обязательно надо делать, иначе оставшийся мусор переезжает в stage2. В > случае с bootchain это делалось автоматически в exit_handler(). > > Теперь отвечу на вопрос. > > Можно вернуть исходную простую реализацию IM_activate(): http://git.altlinux.org/gears/m/make-initrd-bootchain.git?p=make-initrd-bootchain.git;a=blob;f=recent/bootchain/data/sbin/IM-sh-functions;h=c09ab2ed1c1833a6ad60ba4c871bb32d2d374d90;hb=974e6a5e7f662bcf484d3c9a432ed3a7ad65de1c#l32 > в расчёте на то, что демоны или обработчики make-initrd ничего не хотят > знать о разделении на два процесса, и если им нужно что-либо ввести или > вывести, то вызов любого виджета должен автоматом приводить к активации > нужного VT. > > Мне кажется, если фича intarcative попадает в образ, она должна готовить > tty2, а до перехода в stage2 его освобождать. Вообще, пока нет двух фич, > которым нужны диалоги, весьма муторно проектировать правила работы. В > нынешнем виде фича пригодна для единоличного использования другой фичей. Но > для общего пользования её придётся немного доработать, определившись с > концепцией в/в на уровне make-initrd. > > > > > В нынешнем виде фичу interactive может использовать любая другая фича. Но > > > как только станет два "пользователя", эта конструкция перестанет быть > > > рабочей. Как лучше воткнуть блокировки, тебе видней. Есть ещё фича kbd, и > > > она сбрасывает/перенастраивает консоли. Соответствующий демон должен > > > запускаться и полностью отрабатывать до фичи interactive, если попадает в > > > initramfs. Не знаю, как это лучше организовать. > > А kbd разве нужна для bootchain ? > > Нет, но она тоже использует tty2. А если демоны запускаются и работают > параллельно, то работающий код в kbd может что-то испортить на tty2 в > нынешнем bootchain-interactive. Вот почему предлагаю использовать тут > блокировки, ttyN -- это конкретный ресурс. > > > > Для синхронизации с kbd можно поступить как с сетью и сделать сервис > > kbd-ready, который можно ставить в зависимости других сервисов. > > А вот тут уже я не понял.)) На runlevel 3 запускаются сервисы. Чтобы синхронизировать свой запуск с асинхронными событиями такими как поднятие сети был сделан псевдосервис network-up (он приезжает с фичей network). Сервисы, которым нужна сеть ставят его в зависимости и будут запущены после него. Такую же штуку можно сделать и для настройки терминалов. В этом случае можно будет стартовать сервис после того как фича kbd отработает. > > > > [...] > > > > > > > > > > Отлично! Будет смысл согласовать "окно" после финальной проверки всего > > > > > > комплекса. Привязка по времени к продуктам на p10 необязательна, > > > > > > так как для > > > > > > тестирования решения более широкими массами оно должно сначала > > > > > > попасть в > > > > > > Сизиф и тогда есть шанс наловить больше багов на регулярках. При > > > > > > переносе в > > > > > > make-initrd мне придётся параллельно удалять это из Сизифа. > > > > > Ты предлагаешь растянуть мердж bootchain на несколько релизов > > > > > make-initrd? > > > > Наоборот, спрашиваю, как лучше. Тут только ты определяешь... > > > > > > Извини, что не ответил раньше. Я подзалип из-за релизе другого проекта. > > Вот и у меня получилось два месяца полной приостановки, так что хорошо > понимаю. Сейчас уже вернулся к altboot и уже очень скоро всё доделаю (по > плану). > > > > > Отправил пока всю пачку в Сизиф (#284217), чтобы начать полномасштабное > > > тестирование на железе. Тем временем доделываю формализацию и частичную > > > автоматизацию тестирования. В корне проекта появились новые скрипты для > > > этого и пока только частично написанный testplan. Но я освободился от других > > > больших дел, так что в свободное время оставшееся доделаю быстро. > > Мне бы не хотелось делать релиз make-initrd (не путать со сборкой пакета в > > сизиф) с частично рабочей фичей. Поэтому я предлагаю отладить патчи на > > сизифе и тогда я сделаю релиз. В этом случае мы сможем делать сборки и > > дорабатывать эту фичу. > > > > Что думаешь ? > > Да, конечно. Движение в апстрим я и сам хотел начать не раньше, чем будет > написан testpaln до конца, написаны все README, пройдены все тесты по > тестплану. Отправка в Сизиф сейчас увеличивает масштаб тестирования на > реальном железе, поскольку очень скоро на altboot будет переключена сборка > регулярок. > > Однако, меня просили поторопиться с pseudo-gui, вот я её и отделил пораньше, > запустил, как пробный шар. :-) Моё многословное объяснение выше о том, что > будучи в коде bootchain и тестируясь в составе bootchain фича interactive не > становится автоматом пригодной для работы в качестве API между несколькими > фичами, для этих целей её придётся дорабатывать и, в идеале, для этого нужен > второй "клиент" фичи interactive плюс утверждение концепции работы с tty с > твоей стороны. Так. Я понял, что я совсем не в контексте и не могу продуктивно обсуждать, то что не видел. Присылай патчи, мы их обсудим, а потом подумаем, что нужно от остального кода. -- Rgrds, legion