Yes, unified kernel image could be a workaround for this issue. However, we need to integrate swupdate, the root command will be specified in run time not in build time. I don't know if there is a way that we can modify this command in swupdate. Adding a handler for it can be a way but it will need a big effort.
With best regards, Cheng Shu Mou Siemens Ltd., China RC-CN DI FA BL IE Tianyuan road No.99 611731 CHENGDU, China mailto:[email protected] www.siemens.com -----Original Message----- From: Kiszka, Jan (T CED) <[email protected]> Sent: Friday, June 17, 2022 4:12 PM To: Mou, ChengShu(Ben) (DI FA CTR SVC CN) <[email protected]> Cc: [email protected]; Schmidt, Adriaan (T CED SES-DE) <[email protected]>; Schild, Henning (T CED SES-DE) <[email protected]> Subject: Re: Length limitation for kernel parameters On 13.06.22 11:27, Jan Kiszka wrote: > On 13.06.22 10:46, Henning Schild wrote: >> Am Mon, 13 Jun 2022 09:24:52 +0200 >> schrieb Jan Kiszka <[email protected]>: >> >>> On 10.06.22 10:38, Mou, ChengShu(Ben) wrote: >>>> Thanks for your reply. Unfortunately, the parameters can't be >>>> reduced. This kernel is well-tuned for special real time purpose. I >>>> think we should find another way to solve this issue. >>> >>> Henning, Adriaan, do we really have to create such long lines with >>> isolcpus, rcu_nocbs & Co. that would exceed 256 chars easily? If so, >>> this topic needs to be prioritized. >> >> I just checked one target booting with preempt and several tuning >> params. >> >> $ wc -c /proc/cmdline >> 424 /proc/cmdline >> > > OK - will likely only drop when deprecating isolcpus and related > boot-time configurations. > >> I bet one could drop or shorten some, but going up to 1k or simply 4k >> might be a good idea. The number should probably be taken from what >> the kernel has, or what other bootloaders might have hardcoded. > > For v2 of the file format, we will surely not go for any hard-coded > sizes anymore. > Forgot to mention a workaround that is already available: unified kernel image [1] (on x86, you could also use the unified kernel image stub and tooling of systemd-boot). In that case, the command line is built into that image, and that is not size-constrained. You can use that also for non-secure boot - and you must use that anyway if you want to do secure boot. Jan [1] https://github.com/siemens/efibootguard/blob/master/docs/UNIFIED-KERNEL.md -- Siemens AG, Technology Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/e1fb8989c9e74049a10b1225cb9f1693%40siemens.com.
