Make-initrd development discussion
 help / color / mirror / Atom feed
From: Alexey Gladkov <gladkov.alexey@gmail.com>
To: make-initrd@lists.altlinux.org
Subject: Re: [make-initrd] [PATCH v6 08/22] bootchain-waitdev: introduces an optional waitdev_timeout
Date: Sat, 6 Nov 2021 15:55:52 +0100
Message-ID: <20211106145552.g6itg2jycnwhmady@example.org> (raw)
In-Reply-To: <7c5ab56f-e0d3-c48c-6ee6-02f47ed3f33b@gmail.com>

On Sat, Nov 06, 2021 at 05:39:10PM +0300, Leonid Krivoshein wrote:
> 
> 06.11.2021 16:11, Alexey Gladkov пишет:
> > On Tue, Oct 26, 2021 at 10:31:58PM +0300, Leonid Krivoshein wrote:
> > > > > А как происходит этот fallback ?
> > > > > 
> > > > > В твоей реализации если достигнут таймаут, то последующие waitdev просто
> > > > > exit 0 делают и невозможно понять дождались они чего-то или нет.
> > > > > 
> > > > > Получается, что следующий шаг может только гадать о результате waitdev.
> > > > > 
> > > > > Потому что мне сейчас приходит в голову сделать параметр (или шаг)
> > > > > onfail, но это явно не то чем пользуешься ты для failback.
> > > > Ох. Ты спрятал его в 16 патче в next_bootchain. Но тогда у меня всё равно
> > > > вопрос, как будет происходить fallback если next_bootchain waitdev не
> > > > вызывает ?
> > > Без вызова next_bootchain и многоходовочки:
> > > 
> > > waitdev,waidev,localdev waitdev_timeout=7 waitdev=... waitdev=...
> > > altboot_localdev=...
> > > 
> > > Имеем два wiatdev, один localdev и общий таймаут на все waitdev'ы.
> > > 
> > > Если первый или второй waidev не уложатся в 7 секунд, т.е. если за заданное
> > > время не будет найдено всех заданных устройств waitdev, не тормозим, а
> > > переходим к следующему шагу localdev. В этом суть fallback'а и общего
> > > таймаута. localdev может проверить результат предыдущего шага, ему
> > > достаточно проверить только последний waitdev.
> > Леонид, но это же чёрная магия. Получается неявное использование timeout и
> > расчёт на отсутствие результата у последнего waitdev.
> 
> timeout_waitdev=... в /proc/cmdline задаётся вполне себе явно. И если не
> задаётся, то и не используется. Логика к тому же также явно определяет общее
> поведение: мы даём некоторое время на отработку всех вместе взятых
> waitdev'ов, но если что-то пойдёт не так, то переходим к сканированию
> устройств или выбору их в диалоге. Как раз тут никакой магии.
> 
> 
> > Кроме того, получается, что нужно всё время держать в голове такую
> > особенность, а также, что только localdev проверяет предыдущий шаг.
> 
> На самом деле любой шаг может передавать следующему какой-то результат
> работы. И если мы не хотим, чтобы следующий шаг его использовал, необходимо
> вставить специальный разделитель в цепочку -- внутренний шаг "noop". Всё это
> было сделано для обеспечения возможности объединения двух плохо стыкуемых
> концепций -- pipeline и propagator.
> 
> 
> > Хотя, это детали реализации шага и если это исправлять, то мы перейдём к
> > метапрограммированию в cmdline. Я не знаю, что лучше ((
> 
> Моё предложение заключалось в том, чтобы добавить префикс TIMEOUT=... для
> конкретного шага, если в нём тоже есть польза, но не убирать общий
> waitdev_timeout=..., чтобы оставить возможность отрабатывать fallback, как
> сказано в описании. Иначе придётся отказываться от нескольких коммитов
> вокруг bootchain-waitdev, тогда состыковать шаги waitdev и altboot окажется
> невозможно, каждый будет сам по себе.

OK. Пусть будет так как есть сейчас.

-- 
Rgrds, legion



  reply	other threads:[~2021-11-06 14:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-26 10:55 ` Alexey Gladkov
2021-10-26 11:25   ` Leonid Krivoshein
2021-10-26 13:55     ` Alexey Gladkov
2021-10-26 14:05       ` Alexey Gladkov
2021-10-26 19:31         ` Leonid Krivoshein
2021-11-06 13:11           ` Alexey Gladkov
2021-11-06 14:39             ` Leonid Krivoshein
2021-11-06 14:55               ` Alexey Gladkov [this message]
2021-10-26 18:13       ` 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=20211106145552.g6itg2jycnwhmady@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