Hi Grant,
> On Mar 31, 2015, at 20:02 , Grant Likely <grant.likely@xxxxxxxxxxxx> wrote:
>
> Hi Pantelis,
>
> Thanks for the quick reply. Comments below...
>
> On Tue, 31 Mar 2015 13:03:05 +0300
> , Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx>
> wrote:
>> Hi Grant,
>>
>>> On Mar 30, 2015, at 22:04 , Grant Likely <grant.likely@xxxxxxxxxxxx> wrote:
>>>
>>> On Thu, 22 Jan 2015 22:31:46 +0200
>>> , Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx>
>>> wrote:
>>>> Hi Joe,
>>>>
>>>>> On Jan 21, 2015, at 19:37 , Joe Perches <joe@xxxxxxxxxxx> wrote:
>>>>>
>>>>> On Wed, 2015-01-21 at 19:06 +0200, Pantelis Antoniou wrote:
>>>>>> 90% of the usage of device node's full_name is printing it out
>>>>>> in a kernel message. Preparing for the eventual delayed allocation
>>>>>> introduce a custom printk format specifier that is both more
>>>>>> compact and more pleasant to the eye.
>>>>>>
>>>>>> For instance typical use is:
>>>>>> pr_info("Frobbing node %s\n", node->full_name);
>>>>>>
>>>>>> Which can be written now as:
>>>>>> pr_info("Frobbing node %pO\n", node);
>>>>
>>>>> Still disliking use of %p0.
>>>>>
>>>>
>>>> pO - Open Firmware
>>>>
>>>> pT for tree is bad, cause we plan to use a tree type in the future in OF.
>>>
>>> So, here's a radical thought. How about we reserve '%pO' for objects, as
>>> in kobjects. We'll use extra flags to narrow down specifically to
>>> device tree nodes, but we could teach vsprintf() to treat a plain '%pO'
>>> as plain kobject pointer, and if it is able to recognize the kobj_type,
>>> then run a specific decoder to format it.
>>>
>>> This also gives us a namespace for various kinds of firmware data
>>> output. %Od could be a struct device, %On for device tree node, %Oa for
>>> an ACPI node, etc.
>>>
>>
>> I’m fine with this. I also have a patch to turn an overlay to a kobj
>> so this fits naturally.
>>
>> OTOH if we do this, I would expect to rework the custom printk infrastructure
>> to be more generic.
>>
>> IMHO having the format specifier and the format print methods in lib/vsprintf.c
>> is not very nice.
>>
>> How about having a way to register object printk handlers with something like that?
>> We could put that in a special linker section and have the printk method pass control
>> there.
>>
>> PRINTK_OBJFMT(’n’, printk_objfmt_device_node);
>>
>> We might have to make a few printk methods public however.
>
> Honestly, I think trying to add registration is an overengineered
> solution at this point. We're not hitting a wall on the complexity of
> vsprintf.c, and having them all in one place helps to ensure we don't
> have conflicts.
>
>>
>>> I've dropped the refcount decoder. I know it is useful for debugging the
>>> core DT code, but it isn't something that will be used generally. Plus
>>> the returned value cannot be relied upon to be stable because there may
>>> be other code currently iterating over the tree.
>>>
>>
>> Yeah, I know it’s not something to rely on. If we do %pOk to be kobj
>> debug I can add it back in.
>
> Yes, that would be a good place to have refcount output.
>
>>> +Device tree nodes:
>>> +
>>> + %pOn[fnpPcCFr]
>>> +
>>> + For printing device tree nodes. The optional arguments are:
>>> + f device node full_name
>>> + n device node name
>>> + p device node phandle
>>> + P device node path spec (name + @unit)
>>> + F device node flags
>>> + c major compatible string
>>> + C full compatible string
>>> + Without any arguments prints full_name (same as %pOnf)
>>> + The separator when using multiple arguments is ‘:’
>> ^ separator is ‘.'
>
> ? I'm confused? The separator that I'm using is a colon. ':' Where do
> you see ','? I don't think ',' would be a good separator because it
> appears in node names and compatible strings. Originally, I think you
> were using pipe '|', but my personal opinion is that ':' is better
> because there is already precidence as a separator.
>
Ugh, -EJETLAG.
You’re correct, sorry for the confusion.
> g.
Regards
— Pantelis
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
