Re: [Xen-devel] [PATCH V2 07/33] xen/arm: Create a hierarchical device tree

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-05-09 at 15:38 +0100, Julien Grall wrote:
> On 05/08/2013 04:34 PM, Ian Campbell wrote:
> 
> > On Wed, 2013-05-08 at 16:15 +0100, Julien Grall wrote:
> >> On 05/08/2013 02:41 PM, Ian Campbell wrote:
> >>
> >>> On Wed, 2013-05-08 at 14:34 +0100, Julien Grall wrote:
> >>>>> Which only leaves ones which are both? How many are these? I'm inclined
> >>>>> towards suggesting that if they are debug prints which are disabled by
> >>>>> default and require a recompile to enable then the person doing the
> >>>>> debugging can select whether they care about early or late messages by 
> >>>>> #define-ing DEBUG or EARLY_DEBUG or both as required.
> >>>>
> >>>> We can't choose at compile time. Early printk function is in init code
> >>>> section. So at the end of boot the function will disappear.
> >>>
> >>> Oh, right.
> >>>
> >>> Perhaps something could be conditional on system_state =
> >>> SYS_STATE_active, this happens not long before we discard the initial
> >>> sections.
> >>
> >>
> >> I think it's too late. If we use early_printk until this stage, we will
> >> lose some usefull debug when early printk is disabled (ie most of the 
> >> time).
> >>
> >> How about adding the missing system_state = SYS_STATE_boot just after
> >> console_init_preirq? Early printk will only be used when system_state ==
> >> SYS_STATE_early_boot.
> > 
> > I think this is a common thing so it'd need wider discussion.
> 
> 
> SYS_STATE_boot already exists for x86. We forgot to use it on Xen Arm.
> So all ARM boot is done with system_state equals to SYS_STATE_early_boot.

Oh, then great lets use that ;-)

> >>>> Device tree function could be called after the end of the boot. For the
> >>>> moment it's not the case.
> >>>>
> >>>> The best solution would be: early_printk is directly handled in console
> >>>> as linux does.
> >>>
> >>> That does sound best.
> >>
> >>
> >> I will send a patch later for this.
> > 
> > Does that make the above moot?
> 
> 
> Yes. I think this will avoid lots of headache to know if we need to use
> early_printk or printk in the code. It's really annoying when Xen is
> stucked with no log because an assert, which uses printk, is raised when
> console is not setup. But this changes will impact x86.

Yes, this is probably 4.4 material then?




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel