On Fri, Apr 03, 2026 at 11:45:19AM +0900, Masami Hiramatsu wrote: > > I'm still uncertain about this approach. The goal is to identify and > > categorize the early parameters that are parsed prior to bootconfig > > initialization. > > Yes, if we support early parameters in bootconfig, we need to clarify > which parameters are inherently unsupportable, and document it. > Currently it is easy to say that it does not support the parameter > defined with "early_param()". Similary, maybe we should introduce > "arch_param()" or something like it (or support all of them). > > > > > Moreover, this work could become obsolete if bootconfig's initialization > > point shifts earlier or later in the boot sequence, necessitating > > another comprehensive analysis. > > If we can init it before calling setup_arch(), yes, we don't need to > check it. So that is another option. Do you think it is feasible to > support all of them? (Of course, theologically we can do, but the > question is the use case and requirements.)
I don't believe all early parameters can be supported by bootconfig. Some are inherently incompatible as far as I understand, while others depend on bootconfig's initialization point in the boot sequence. Regarding documenting arch_param(), I need clarification: should we document parameters that are currently called before bootconfig (as of today), or those that fundamentally cannot be called by bootconfig regardless of its location? > > Do you have any additional recommendations if I proceed with this > > approach? > > OK, > > First of all, even if we enable early parameter support in bootconfig, > this is only possible if bootconfig is embedded. In that case, we can > pass memory that has been pre-allocated at compile time to bootconfig > as a working area. However, this will consume a lot of memory, so it > needs to be selectable in Kconfig. > > If you're going to embed this, as Kiryl pointed out[1], it might be better > to pass pre-normalized (or compiled) data and avoid using a parser. > Compilation itself is relatively easy if you utilize the tools/bootconfig. > (However, in this case, there doesn't seem to be much point in using > bootconfig in the first place because we also can use embed kernel > cmdline.) > > [1] https://lore.kernel.org/all/acueCFv4neO7zQGI@thinkstation/ > > Can you clarify the main reason of requesting this feature and > examples? My primary objective is to enable early configuration of `irqchip.gicv3_pseudo_nmi`, allowing the kernel to support pseudo NMI on arm64 by default.
