|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V2 07/33] xen/arm: Create a hierarchical device tree
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. > >>>> 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. -- Julien _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |