On Wed, 15 Apr 2026 04:15:57 -0700 Breno Leitao <[email protected]> wrote:
> On Tue, Apr 07, 2026 at 03:19:09AM -0700, Breno Leitao wrote: > > 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. > > I've developed a patch series that relocates bootconfig initialization > to occur before setup_arch(). > > Adopting this approach would streamline the categorization considerably, > as only a small subset of kernel parameters are parsed before > setup_arch() is called. > > This enables a clearer distinction: parameters processed *before* > setup_arch() versus those handled afterward, rather than classifying > based on what occurs before bootconfig initialization. > > Just to close the look and link both discussion together, the proposed > patch series is available at: > > https://lore.kernel.org/all/[email protected]/ Thanks for working on this series!! Let me review the series. BTW, I found that the current __setup(), early_param(), module_param() are a bit complicated, for example, __setup() and early_param() are stored in the different array of module_param(), and those can use the same parameter (e.g. console). And as you found some of early_param() options are only applied via command line. Maybe we can introduce another special macro which is only for command line. Thanks, -- Masami Hiramatsu (Google) <[email protected]>
