Hi Heinrich, On Tue, 30 Sept 2025 at 05:35, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
On 9/30/25 13:24, Simon Glass wrote:
Hi Heinrich,
On Mon, 29 Sept 2025 at 20:02, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
Am 30. September 2025 02:51:31 MESZ schrieb Simon Glass <sjg@u-boot.org>:
From: Simon Glass <sjg@chromium.org>
Provide some developer documentation on the priority feature for global bootmeths.
Signed-off-by: Simon Glass <sjg@chromium.org> ---
doc/develop/bootstd/overview.rst | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/doc/develop/bootstd/overview.rst b/doc/develop/bootstd/overview.rst index ca76bad7bca..4c924e2eb21 100644 --- a/doc/develop/bootstd/overview.rst +++ b/doc/develop/bootstd/overview.rst @@ -133,7 +133,8 @@ which scans for available bootflows, optionally listing each find it finds (-l) and trying to boot it (-b).
When global bootmeths are available, these are typically checked before the -above bootdev scanning. +above bootdev scanning, but it is possible provide a priority to make them +run later, by setting the glob_prio field in the driver's bind() method.
Controlling ordering @@ -614,9 +615,9 @@ simply copied into the iterator. Either way, the `method_order` array it set up, along with `num_methods`.
Note that global bootmeths are always put at the end of the ordering. If any are -present, `cur_method` is set to the first one, so that global bootmeths are done -first. Once all have been used, these bootmeths are dropped from the iteration. -When there are no global bootmeths, `cur_method` is set to 0. +present, `cur_method` is set to the first one, so that global bootmeths are +processed first, so long as their priority allows it. Bootstd keeps track of +which global bootmeths have been used, to make sure they are only used once.
At this point the iterator is ready to use, with the first bootmeth selected. Most of the other fields are 0. This means that the current partition @@ -719,6 +720,23 @@ When it sees `BF_NO_MORE_DEVICES` it knows that there is nothing more it can do so it should immediately return. The caller of `iter_incr()` is responsible for updating the `err` field, based on the return value it sees.
+Global bootmeths can have a non-zero priority, which indicates where in the +iteration sequence they should run. Each time a new bootdev is produced by a +hunter, all of the global bootmeths are first checked to see if they should run +before this new bootdev. For example, if the bootdev was produced by a hunter +with priority BOOTDEVP_6_NET_BASE,
This would imply that the EFI bootmgr never runs if there is no huntable network device or network devices are not hunted.
I hope this is not true.
Any unused global boot bootmeths are run at the end, after all bootdevs are exhausted.
What happens if I have 3 bootmeths:
local-1, prio 3 global-2, prio 4 local-3, prio 5
global should still be the 2nd bootmeth to be executed.
Only global bootmeths have a priority. It is meaningless for normal bootmeths since they are used repeatedly on each bootdev. So the picture might be: bootdev priority 3: local-1, local-3 global-2, prio 4 bootdev priority 5: local-1, local-3 This will work as expected, since when the priority-5 hunter / label is about to be used, the global-2 bootmeth will be used first. Regards, SImon
then a quick check is made for global
+bootmeths with that priority or less. If there are any, they run before the new +bootdev is processed. + +Assuming they are enabled and the iteration sequence runs right to the end, all +global bootmeths will be used. This is handled by a special case at the end of +iter_incr(), where it processes amy so-far-unused global bootmeths. + +Of course if a specific bootmeth ordering is provided, then this overrides the +default ordering. Global bootmeths must be listed at the end, reflecting their +hybrid nature (they are bootmeths but operate on the system as a whole, not on +a particular bootdev). + The above describes the iteration process at a high level. It is basically a very simple increment function with a checker called `bootflow_check()` that checks the result of each iteration generated, to determine whether it can