LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Joe Perches <joe@perches.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rob Herring <robherring2@gmail.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	linux-doc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] of: Custom printk format specifier for device node
Date: Tue, 31 Mar 2015 20:14:58 +0300	[thread overview]
Message-ID: <2C46053A-892C-4808-9CD8-896BD1BE359B@konsulko.com> (raw)
In-Reply-To: <20150331170229.58DCEC40856@trevor.secretlab.ca>

Hi Grant,

> On Mar 31, 2015, at 20:02 , Grant Likely <grant.likely@secretlab.ca> wrote:
> 
> Hi Pantelis,
> 
> Thanks for the quick reply. Comments below...
> 
> On Tue, 31 Mar 2015 13:03:05 +0300
> , Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> wrote:
>> Hi Grant,
>> 
>>> On Mar 30, 2015, at 22:04 , Grant Likely <grant.likely@secretlab.ca> wrote:
>>> 
>>> On Thu, 22 Jan 2015 22:31:46 +0200
>>> , Pantelis Antoniou <panto@antoniou-consulting.com>
>>> wrote:
>>>> Hi Joe,
>>>> 
>>>>> On Jan 21, 2015, at 19:37 , Joe Perches <joe@perches.com> 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


  reply	other threads:[~2015-03-31 17:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-21 17:06 Pantelis Antoniou
2015-01-21 17:37 ` Joe Perches
2015-01-21 17:39   ` Pantelis Antoniou
2015-01-21 17:52     ` Joe Perches
2015-01-21 17:59     ` Måns Rullgård
2015-01-22 20:31   ` Pantelis Antoniou
2015-03-30 19:04     ` Grant Likely
2015-03-31 10:03       ` Pantelis Antoniou
2015-03-31 17:02         ` Grant Likely
2015-03-31 17:14           ` Pantelis Antoniou [this message]
2015-04-01  4:52         ` Grant Likely
2015-04-01  5:07           ` Joe Perches
  -- strict thread matches above, loose matches on Subject: below --
2015-01-20 14:34 Pantelis Antoniou
2015-01-20 14:47 ` Rob Herring
2015-01-20 14:52   ` Pantelis Antoniou
2015-01-20 17:59     ` Joe Perches
2015-01-20 18:06       ` Pantelis Antoniou
2015-01-20 18:16         ` Joe Perches
2015-01-20 15:24   ` Geert Uytterhoeven
2015-01-20 15:27     ` Pantelis Antoniou
2015-01-20 16:05       ` Måns Rullgård
2015-01-20 17:13         ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2C46053A-892C-4808-9CD8-896BD1BE359B@konsulko.com \
    --to=pantelis.antoniou@konsulko.com \
    --cc=akpm@linux-foundation.org \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@secretlab.ca \
    --cc=joe@perches.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=robherring2@gmail.com \
    --subject='Re: [PATCH] of: Custom printk format specifier for device node' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).