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

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 05/08/2013 02:11 PM, Ian Campbell wrote:

> On Wed, 2013-05-08 at 03:33 +0100, Julien Grall wrote:
> 
>> +/**
>> + * Dump device tree message with printk
>> + * TODO: Find another way to switch between early_printk and printk
>> + * int the device tree code
>> + */
>> +void __init dt_switch_to_printk(void);
> 
> The issue here is that there is code which wants to log which can be
> called either via dt_unflatten_host_device_tree or later on?


Right.


> There seems to be at least some calls to dt_dprintk which are only
> called via dt_unfla..., I think these can and should just use
> early_printk (or a macro to make them a debug thing). Likewise if there
> are functions which are only called later then they should just use
> printk direct (or a macro..)

There are lots of dt_dprintk in functions to retrieve an IRQ and an address.

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

>> +/**
>> + * Host device tree
>> + * DO NOT modify it!
> 
> Can it be const?

No :/. I choose to runtime information in the device tree. It's usefull
to know if a device is used by Xen or someone else.

I have just notice that dt_host is only used in domain_build.c to browse
all the nodes. I can either provide a helper which return the host DT or
add a function to call a function and recurse on each node.

-- 
Julien Grall

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