Re: [Xen-devel] [PATCH 2/2] xen: make opt_xen_console true before console initialisation

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Sep 28, 2018 at 09:19:56AM -0600, Jan Beulich wrote:
> >>> On 28.09.18 at 17:12, <wei.liu2@xxxxxxxxxx> wrote:
> > On Fri, Sep 28, 2018 at 09:08:34AM -0600, Jan Beulich wrote:
> >> >>> On 28.09.18 at 10:24, <wei.liu2@xxxxxxxxxx> wrote:
> >> > --- a/xen/drivers/char/console.c
> >> > +++ b/xen/drivers/char/console.c
> >> > @@ -91,7 +91,8 @@ static uint32_t conringc, conringp;
> >> >  static int __read_mostly sercon_handle = -1;
> >> >  
> >> >  #ifdef CONFIG_X86
> >> > -static bool __read_mostly opt_console_xen; /* console=xen */
> >> > +/* Set to true at start of day to catch early boot issues */
> >> > +static bool __read_mostly opt_console_xen = true; /* console=xen */
> >> 
> >> When Andrew suggested this, iirc he said to make the variable
> >> tristate. Otherwise ...
> > 
> > I figure it doesn't need to be tristate.
> > 
> >> 
> >> > @@ -821,6 +822,10 @@ void __init console_init_preirq(void)
> >> >  
> >> >      serial_init_preirq();
> >> >  
> >> > +#ifdef CONFIG_X86
> >> > +    opt_console_xen = false;
> >> > +#endif
> >> 
> >> ... you possibly override a user specified "true" here.
> > 
> > Do I? This is right before option parsing, during which opt_console_xen
> > is set.
> 
> Hmm, I see - I didn't recall we still have this ad hoc parsing in
> place, instead of using custom_param(). But isn't this too early then,
> as messages issued from the parsing code then would not be visible?

To me it doesn't make anything worse than before. But I see your point.
I will see if there is an easy way to fix this.

Wei.

> 
> Jan
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel