Damien Zammit, le dim. 16 juil. 2023 10:38:31 +0000, a ecrit:
> This standardises the format of the boot parameters so that
> they all use the same parameter --next-task to specify the next
> task in the boot order. It does assume the next task is always exec,
> however. This may not be a problem.
That however brings confusion, I don't think we want this. I understand
that this looks nice to just have to put servers one after the other,
but this is hiding the fact that the user *has* to pass exec exactly
after the root filesystem. I'd rather see the grub module know the
notion of exec server task, and pass the option as appropriate (others
can be looked up through mach devices).
Samuel
> ---
> libdiskfs/opts-std-startup.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libdiskfs/opts-std-startup.c b/libdiskfs/opts-std-startup.c
> index e5531a46..e14a39b7 100644
> --- a/libdiskfs/opts-std-startup.c
> +++ b/libdiskfs/opts-std-startup.c
> @@ -47,6 +47,7 @@ mach_port_t diskfs_kernel_task = MACH_PORT_NULL;
> #define OPT_BOOT_INIT_PROGRAM (-6)
> #define OPT_BOOT_PAUSE (-7)
> #define OPT_KERNEL_TASK (-8)
> +#define OPT_NEXT_TASK (-9)
>
> static const struct argp_option
> startup_options[] =
> @@ -69,8 +70,9 @@ startup_options[] =
> " at bootstrap instead of init"},
> {"host-priv-port", OPT_HOST_PRIV_PORT, "PORT"},
> {"device-master-port", OPT_DEVICE_MASTER_PORT, "PORT"},
> - {"exec-server-task", OPT_EXEC_SERVER_TASK, "PORT"},
> + {"exec-server-task", OPT_EXEC_SERVER_TASK, "PORT"}, // Deprecated
> {"kernel-task", OPT_KERNEL_TASK, "PORT"},
> + {"next-task", OPT_NEXT_TASK, "PORT"},
>
> {0}
> };
> @@ -121,6 +123,8 @@ parse_startup_opt (int opt, char *arg, struct argp_state
> *state)
> _hurd_host_priv = atoi (arg); break;
> case OPT_EXEC_SERVER_TASK:
> diskfs_exec_server_task = atoi (arg); break;
> + case OPT_NEXT_TASK:
> + diskfs_exec_server_task = atoi (arg); break;
> case OPT_KERNEL_TASK:
> diskfs_kernel_task = atoi (arg); break;
> case OPT_BOOT_CMDLINE:
> --
> 2.40.1
