[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/09/2013 03:43 PM, Ian Campbell wrote:

> 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?

Yes, I will write a line on this issue with ASSERT on the wiki.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.