Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1690531 > unrolled thread

Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv]

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv] Joe Perches <joe@perches.com> - 2017-07-18 20:00 +0200
    Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv] Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2017-07-18 20:00 +0200
      Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv] Joe Perches <joe@perches.com> - 2017-07-18 20:40 +0200
    Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv] Mark Salyzyn <salyzyn@android.com> - 2017-07-18 22:00 +0200
      Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv] Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2017-07-20 12:40 +0200
        Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv] Mark Salyzyn <salyzyn@android.com> - 2017-07-20 20:00 +0200
          Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv] Joe Perches <joe@perches.com> - 2017-07-21 06:10 +0200

#1690531 — Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv]

On Thu, 2017-06-08 at 16:47 +0300, Andy Shevchenko wrote:
> Recently I have noticed too many users of struct rtc_time that printing
> its content field by field.
> 
> In this series I introduce %pt[dt][rv] specifier to make life a bit
> easier.

Hey Andy.

I just saw a patch with a printk for rtc time from Mark Salyzyn.
https://lkml.org/lkml/2017/7/18/885

Any idea if you want to push this extension?

I like the concept and still think it could be extended a bit more.

from: https://lkml.org/lkml/2017/6/8/1134

My preference would be for %pt[type]<output style>
where <type> is mandatory and could be:

        r for struct rtc_time
        6 for time64_t
        k for ktime_t
        T for struct timespec64
        etc

and <output style> has an unspecified default of
YYYY-MM-DD:hh:mm:ss

Perhaps use the "date" formats without the leading
% uses for <output style> for additional styles.

[toc] | [next] | [standalone]

#1690535

On Tue, 2017-07-18 at 10:50 -0700, Joe Perches wrote:
> On Thu, 2017-06-08 at 16:47 +0300, Andy Shevchenko wrote:
> > Recently I have noticed too many users of struct rtc_time that
> > printing
> > its content field by field.
> > 
> > In this series I introduce %pt[dt][rv] specifier to make life a bit
> > easier.
> 
> Hey Andy.
> 
> I just saw a patch with a printk for rtc time from Mark Salyzyn.
> https://lkml.org/lkml/2017/7/18/885

Same!

> Any idea if you want to push this extension?

Yes, just really lack of time for everything.

I like the idea to make it conditional (config BLABLABLA). It will
address some comments about footprint for no users.

> I like the concept and still think it could be extended a bit more.
> 
> from: https://lkml.org/lkml/2017/6/8/1134
> 
> My preference would be for %pt[type]<output style>
> where <type> is mandatory and could be:
> 
>         r for struct rtc_time
>         6 for time64_t
>         k for ktime_t
>         T for struct timespec64
>         etc

I dunno about this.

However, I like this more than do conversion in each case where input
reference has different type.

> and <output style> has an unspecified default of
> YYYY-MM-DD:hh:mm:ss

I'm against this, sorry. Too many variations for almost no use (users).

> Perhaps use the "date" formats without the leading
> % uses for <output style> for additional styles.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

[toc] | [prev] | [next] | [standalone]

#1690560

On Tue, 2017-07-18 at 20:55 +0300, Andy Shevchenko wrote:
> On Tue, 2017-07-18 at 10:50 -0700, Joe Perches wrote:
> > On Thu, 2017-06-08 at 16:47 +0300, Andy Shevchenko wrote:
> > > Recently I have noticed too many users of struct rtc_time that
> > > printing
> > > its content field by field.
> > > 
> > > In this series I introduce %pt[dt][rv] specifier to make life a bit
> > > easier.
> > 
> > Hey Andy.
> > 
> > I just saw a patch with a printk for rtc time from Mark Salyzyn.
> > https://lkml.org/lkml/2017/7/18/885
> 
> Same!
> 
> > Any idea if you want to push this extension?
> 
> Yes, just really lack of time for everything.
> 
> I like the idea to make it conditional (config BLABLABLA). It will
> address some comments about footprint for no users.

Only one of the other %p<foo> extensions is conditional
and that
conditional is probably not too useful.

I think the code size is relatively small and not
particularly valuable for the additional complexity.

For instance, all of the code that emits MAC and
IP[46] addresses %pM and %pI variants is 2.5K.
(x86 allnoconfig)

There are lots more code size savings than that
lying about.

And auditing all the code that might emit a MAC
address when CONFIG_NET is not set is probably
not worth the effort for the size reduction.

$ size lib/vsprintf.o*
   text	   data	    bss	    dec	    hex	
filename
  12140	      4	      0	  12144	   2f70	
lib/vsprintf.o.allnoconfig.new
  14785	      4	      0	  14789	   39c5	
lib/vsprintf.o.allnoconfig.old
---
 lib/vsprintf.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 86c3385b9eb3..de95e78ca5f0 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -933,6 +933,7 @@ char *bitmap_list_string(char *buf, char *end, unsigned long *bitmap,
 	return buf;
 }
 
+#ifdef CONFIG_NET
 static noinline_for_stack
 char *mac_address_string(char *buf, char *end, u8 *addr,
 			 struct printf_spec spec, const char *fmt)
@@ -1241,6 +1242,7 @@ char *ip4_addr_string_sa(char *buf, char *end, const struct sockaddr_in *sa,
 
 	return string(buf, end, ip4_addr, spec);
 }
+#endif
 
 static noinline_for_stack
 char *escaped_string(char *buf, char *end, u8 *addr, struct printf_spec spec,
@@ -1741,6 +1743,7 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
 		default:
 			return bitmap_string(buf, end, ptr, spec, fmt);
 		}
+#ifdef CONFIG_NET
 	case 'M':			/* Colon separated: 00:01:02:03:04:05 */
 	case 'm':			/* Contiguous: 000102030405 */
 					/* [mM]F (FDDI) */
@@ -1777,6 +1780,7 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
 			}}
 		}
 		break;
+#endif
 	case 'E':
 		return escaped_string(buf, end, ptr, spec, fmt);
 	case 'U':

[toc] | [prev] | [next] | [standalone]

#1690613

On 07/18/2017 10:50 AM, Joe Perches wrote:
> On Thu, 2017-06-08 at 16:47 +0300, Andy Shevchenko wrote:
>> Recently I have noticed too many users of struct rtc_time that printing
>> its content field by field.
>>
>> In this series I introduce %pt[dt][rv] specifier to make life a bit
>> easier.
> Hey Andy.
>
> I just saw a patch with a printk for rtc time from Mark Salyzyn.
> https://lkml.org/lkml/2017/7/18/885
>
> Any idea if you want to push this extension?
>
> I like the concept and still think it could be extended a bit more.
>
> from: https://lkml.org/lkml/2017/6/8/1134
>
> My preference would be for %pt[type]<output style>
> where <type> is mandatory and could be:
>
>          r for struct rtc_time
>          6 for time64_t
>          k for ktime_t
>          T for struct timespec64
>          etc
>
> and <output style> has an unspecified default of
> YYYY-MM-DD:hh:mm:ss
>
> Perhaps use the "date" formats without the leading
> % uses for <output style> for additional styles.
>
YYYY-MM-DD hh:mm:ss.nnnnnnnnn ?

[toc] | [prev] | [next] | [standalone]

#1692771

On Tue, 2017-07-18 at 12:57 -0700, Mark Salyzyn wrote:
> On 07/18/2017 10:50 AM, Joe Perches wrote:
> > On Thu, 2017-06-08 at 16:47 +0300, Andy Shevchenko wrote:
> > > Recently I have noticed too many users of struct rtc_time that
> > > printing
> > > its content field by field.
> > > 
> > > In this series I introduce %pt[dt][rv] specifier to make life a
> > > bit
> > > easier.
> > 
> > Hey Andy.
> > 
> > I just saw a patch with a printk for rtc time from Mark Salyzyn.
> > https://lkml.org/lkml/2017/7/18/885
> > 
> > Any idea if you want to push this extension?
> > 
> > I like the concept and still think it could be extended a bit more.
> > 
> > from: https://lkml.org/lkml/2017/6/8/1134
> > 
> > My preference would be for %pt[type]<output style>
> > where <type> is mandatory and could be:
> > 
> >          r for struct rtc_time
> >          6 for time64_t
> >          k for ktime_t
> >          T for struct timespec64
> >          etc
> > 
> > and <output style> has an unspecified default of
> > YYYY-MM-DD:hh:mm:ss
> > 
> > Perhaps use the "date" formats without the leading
> > % uses for <output style> for additional styles.
> > 
> 
> YYYY-MM-DD hh:mm:ss.nnnnnnnnn ?

As a separate modifier, yes.

See my answer to subthread in patch 4.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

[toc] | [prev] | [next] | [standalone]

#1693144

On 07/20/2017 03:33 AM, Andy Shevchenko wrote:
> On Tue, 2017-07-18 at 12:57 -0700, Mark Salyzyn wrote:
>> On 07/18/2017 10:50 AM, Joe Perches wrote:
>>> On Thu, 2017-06-08 at 16:47 +0300, Andy Shevchenko wrote:
>>>> Recently I have noticed too many users of struct rtc_time that
>>>> printing
>>>> its content field by field.
>>>>
>>>> In this series I introduce %pt[dt][rv] specifier to make life a
>>>> bit
>>>> easier.
>>> Hey Andy.
>>>
>>> I just saw a patch with a printk for rtc time from Mark Salyzyn.
>>> https://lkml.org/lkml/2017/7/18/885
>>>
>>> Any idea if you want to push this extension?
>>>
>>> I like the concept and still think it could be extended a bit more.
>>>
>>> from: https://lkml.org/lkml/2017/6/8/1134
>>>
>>> My preference would be for %pt[type]<output style>
>>> where <type> is mandatory and could be:
>>>
>>>           r for struct rtc_time
>>>           6 for time64_t
>>>           k for ktime_t
>>>           T for struct timespec64
>>>           etc
>>>
>>> and <output style> has an unspecified default of
>>> YYYY-MM-DD:hh:mm:ss
>>>
>>> Perhaps use the "date" formats without the leading
>>> % uses for <output style> for additional styles.
>>>
>> YYYY-MM-DD hh:mm:ss.nnnnnnnnn ?
> As a separate modifier, yes.
>
> See my answer to subthread in patch 4.
>
It would probably need to take struct timespec64 as an argument. Pass by 
structure might be difficult to swallow, so pass by pointer?

As for my need for this in my suspend/resume/hibernate/restore patch 
set, we have already been told three times to _not_ report wall clock 
time. I could imagine being a consumer of it in the future if we have 
difficulty migrating the analysis tools ... so tepid support from me.

-- Mark

[toc] | [prev] | [next] | [standalone]

#1693379

On Thu, 2017-07-20 at 10:57 -0700, Mark Salyzyn wrote:
> It would probably need to take struct timespec64 as an argument. Pass by 
> structure might be difficult to swallow, so pass by pointer?

Every %p<foo> extension is passed via a pointer.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web