From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=uFjegICz5RdprySx9iNbmr/WMMxT/qjpWdyCw02B5SI=; b=O09LJhTrX8w/TKcO/px3JtlfIVJ17JLEudShCN6Oa+vkV2cA6QP7zqXAloaEetpHlE Ne5R9G220SAmRzemMa+2VOkqMY9uwsOnaRDzPH/F4mkfBOBB7PoPCd17CKrjFwv5+SJH YXoh5BEWTuZHJHTJDXMzbGVn0C/oFzHkax65gRTnNnhhXlmMeFmp2n8xFTOpfnrAgI/Z ju6p9ki4N3+/hbBRfrU61U1OLoZgKzWdFR3hC+V5coZkXsRltydvAqe+TJ2a7qrP6iGL texXBDWWTgnNOMIeScntF2EAPNQbvvVJXmQOB8slF39RvnAnOvgYmN8ATg6phOy0mrWm M31w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=uFjegICz5RdprySx9iNbmr/WMMxT/qjpWdyCw02B5SI=; b=avd1Eo5Uq7uAHcG+roIYdnBoBgsic0GPSoWiBvy83/B2/0h7N8OKQG/zi5ag9U/+7C I77sEYYJrCifMwkxl593bm0k58PcOPcyNy/D2QDS+hUyluAoZlKiZhOoMqrP/J/UR6L5 uBksfWovp2huQTkJnYGmdLdI2rBXM51nTXqQetnC/0DlMnB8r6deifBASPVqwlmUm2lu 6Og9HJyqetbSSPQY/NyfBB8Toe70Pk0ZE/Rp0wSB+XwsXhc9ETj/KCmTvuMFT0gSq31r 5pzU+GmZMY3pTLPKLuE5imD4m7ak7m5QnuVEBcfH09lnfnbYqeRUv4kFvHQHiuG0X4j6 Mhyw== X-Gm-Message-State: AOAM5316ORyTIz8o1TEcPdMEZDmMM+iQeM8HFQkz/bDg9di36Zljf1gF M/Z/vG8fMtq/2X2zwlSWQINMK/ZZr5k= X-Google-Smtp-Source: ABdhPJxJqZN4pDheRWgyoSnV7nAxtRe95FWuhj7L3+iknIF/OiR3YYLEWV9qqAmXriMjJhvFtzeVcA== X-Received: by 2002:a05:6512:2295:: with SMTP id f21mr30091874lfu.647.1636209551625; Sat, 06 Nov 2021 07:39:11 -0700 (PDT) To: make-initrd@lists.altlinux.org References: <20211024172108.668CDA5E4C@lists.altlinux.org> <20211026105516.jfbatbtjfah74vou@example.org> <37c46f84-217f-81bd-56a9-1d5b8d02d670@gmail.com> <20211026135552.wratyys3jkvboqm6@example.org> <20211026140528.pqyv5jgqclcef4ry@example.org> <20211106131130.zvwsnnikmaq7oqmz@example.org> From: Leonid Krivoshein Message-ID: <7c5ab56f-e0d3-c48c-6ee6-02f47ed3f33b@gmail.com> Date: Sat, 6 Nov 2021 17:39:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20211106131130.zvwsnnikmaq7oqmz@example.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru Subject: Re: [make-initrd] [PATCH v6 08/22] bootchain-waitdev: introduces an optional waitdev_timeout 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: Sat, 06 Nov 2021 14:39:14 -0000 Archived-At: List-Archive: 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 окажется невозможно, каждый будет сам по себе. -- Best regards, Leonid Krivoshein.