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. After checking the code of tools, I found that struct BG_ENVDATA is used for recording environment variables. It will be written to(or read from) a specific file located in configuration partition by bg_setenv. Reading or writing data with fixed size is more convenient than handling data with variable size. The field kernelparams is defined the same as field kernelfile with the length limitation of Linux file names. I think we can add a new constant variable larger than 255(e.g. 1024) for field kernelparams and modify related logic code to avoid this limitation. This solution won't break the current mechanism of handling environment variables. I don't know if I misunderstood something about this solution. Hope your suggestions.
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: Tuesday, June 7, 2022 2:57 PM To: Mou, ChengShu(Ben) (DI FA CTR SVC CN) <[email protected]>; [email protected] Subject: Re: Length limitation for kernel parameters On 07.06.22 07:58, Mou, ChengShu(Ben) wrote: > Hello all, > > I’m sorry to trouble you. I met a problem when I use bg_setenv. I > tried to specify kernel parameters but it failed with message “Error, > kernel arguments string is too long. Maximum of 255 characters permitted.” > > After checking the code, I found that a constant variable > ENV_STRING_LENGTH limited the length of file names and kernel > parameters. As we know, Linux has a length limitation(255) for file > names. For kernel parameters, there is no limitation like this. If I > use a customized Linux kernel with parameters more than 255 > characters, it will fail. > > So, can you provide a workaround for this? Thanks. > You are right, EFI Boot Guard has this unfortunate limitations. We cannot easily overcome it for the existing versions because it would break backward compatibility in the field. However, I'm planning to renovate the config file with a "version 2" and enable EBG to read both versions. No code written yet, though, just the intention. Meanwhile, there might be ways for you to reduce your command line length. Can you explain what makes it that long? E.g., we recently dropped MTD layout parameters from an embedded board by moving it into the device tree [1]. That wasn't hitting EBG's limits yet but was getting close and also improved readability and maintanability. Jan [1] https://github.com/siemens/meta-iot2050/commit/85040da46f6ec3009b96a934bc12fb6cb28de508 -- 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/07d753603cd9445395939f6e036932c0%40siemens.com.
