On Fri, Sep 28, 2018 at 09:19:56AM -0600, Jan Beulich wrote: > >>> On 28.09.18 at 17:12, <wei.l...@citrix.com> wrote: > > On Fri, Sep 28, 2018 at 09:08:34AM -0600, Jan Beulich wrote: > >> >>> On 28.09.18 at 10:24, <wei.l...@citrix.com> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel