From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alessandro Zummo <a.zummo@towertech.it>,
Alexandre Belloni <alexandre.belloni@free-electrons.com>,
linux-rtc@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Joe Perches <joe@perches.com>, Mark Salyzyn <salyzyn@android.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Guan Xuetao <gxt@mprc.pku.edu.cn>, Ingo Molnar <mingo@kernel.org>,
Jason Wessel <jason.wessel@windriver.com>,
Jonathan Corbet <corbet@lwn.net>,
Jonathan Hunter <jonathanh@nvidia.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Thierry Reding <thierry.reding@gmail.com>
Subject: Re: [PATCH v2 01/21] lib/vsprintf: Print time and date in human readable format via %pt
Date: Wed, 21 Feb 2018 16:02:28 +0200 [thread overview]
Message-ID: <1519221748.10722.34.camel@linux.intel.com> (raw)
In-Reply-To: <CAMuHMdVwjP6cWM=Ku6KRVz9F8_n4OsgeK42UZa6BenKij4iu4Q@mail.gmail.com>
On Wed, 2018-02-21 at 10:33 +0100, Geert Uytterhoeven wrote:
> Hi Andy,
>
> On Tue, Feb 20, 2018 at 10:43 PM, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > There are users which print time and date represented by content of
> > struct rtc_time in human readable format.
> >
> > Instead of open coding that each time introduce %ptR[dt][rv]
> > specifier.
>
> Thanks for your patch!
>
> > Note, users have to select PRINTK_PEXT_TIMEDATE option in a Kconfig.
>
> Is it worthwhile making this an option?
People were complaining before
https://lists.01.org/pipermail/kbuild-all/2017-June/034950.html
> > --- a/Documentation/core-api/printk-formats.rst
> > +++ b/Documentation/core-api/printk-formats.rst
> > @@ -412,6 +412,37 @@ Examples::
> >
> > Passed by reference.
> >
> > +Time and date
> > +-------------
> > +
> > +::
> > +
> > + %pt[R] YYYY-mm-dd HH:MM:SS
> > + %pt[R]d YYYY-mm-dd
> > + %pt[R]t HH:MM:SS
>
> [R] suggests the "R" is optional?
> But if it's missing, it prints the hex pointer value?
Yes.
> > + %pt[R][dt]
>
> What's the purpose of this?
A place holder to extend.
> > +
> > + R for struct rtc_time
> > +
> > +Note, users have to select PRINTK_PEXT_TIMEDATE option in a
> > Kconfig.
> > +
> > +struct rtc_time
> > +~~~~~~~~~~~~~~~
> > +
> > +::
> > +
> > + %ptR[dt][rv]
>
> What's the purpose of this paragraph, compared to the previous one?
This is first batch to make it working for struct rtc_time. We have
several users (and I have some local patches WIP) to print time64_t /
timespec64 which would use different letters and paragraphs to explain.
I could remove it and return like it was in v1 (with the exception for
new R letter added).
TBH, I don't see much consensus among developers on this topic.
I wouldn't like to send a new version until it would be a consensus.
> > +static noinline_for_stack
> > +char *date_str(char *buf, char *end, const struct rtc_time *tm,
> > bool v, bool r)
> > +{
> > + int year = tm->tm_year + (r ? 0 : 1900);
> > + int mon = tm->tm_mon + (r ? 0 : 1);
> > +
> > + if (unlikely(v && (unsigned int)tm->tm_year > 200))
> > + buf = string(buf, end, "****", default_str_spec);
> > + else
> > + buf = number(buf, end, year, default_dec04_spec);
> > +
> > + if (buf < end)
> > + *buf = '-';
>
> Instead of all these checks to avoid overflowing the passed buffer, it
> may be simpler to format everything in a fixed-size buffer on the
> stack,
> and copy whatever will fit in the target buffer at the end.
I dropped that idea since the most heavier call is number().
We still need to do several of them one way or the other.
So, I really don't see much benefit of doing your way.
> > +static noinline_for_stack
> > +char *rtc_str(char *buf, char *end, const struct rtc_time *tm,
> > const char *fmt)
> > +{
> > + bool have_t = true, have_d = true;
> > + bool validate = false;
> > + bool raw = false;
> > + int count = 1;
> > + bool found;
> > +
> > + switch (fmt[++count]) {
> > + case 'd':
> > + have_t = false;
> > + break;
> > + case 't':
> > + have_d = false;
> > + break;
> > + }
> > +
> > + /* No %pt[dt] supplied */
> > + if (have_d && have_t)
> > + --count;
>
> First increment count, then rollback.
> What about:
>
> switch (fmt[count]) {
> case 'd':
> have_t = false;
> count++;
> break;
> case 't':
> have_d = false;
> count++;
> break;
> }
Or simple:
default:
--count;
break;
?
I really need to come up with the next pile for time64_t which I suppose
will require rethinking of format parsing and printing functions here.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2018-02-21 14:02 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-20 21:43 [PATCH v2 00/21] lib, rtc: Print rtc_time via %ptR[dt][rv] Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 01/21] lib/vsprintf: Print time and date in human readable format via %pt Andy Shevchenko
2018-02-20 23:55 ` Joe Perches
2018-02-21 7:38 ` Rasmus Villemoes
2018-02-21 13:23 ` Andy Shevchenko
2018-02-21 14:19 ` Geert Uytterhoeven
2018-02-22 12:46 ` Andy Shevchenko
2018-02-21 9:16 ` Alexandre Belloni
2018-02-21 13:19 ` Andy Shevchenko
2018-02-21 9:33 ` Geert Uytterhoeven
2018-02-21 14:02 ` Andy Shevchenko [this message]
2018-02-21 14:05 ` Andy Shevchenko
2018-03-14 16:54 ` Dmitry Torokhov
2018-02-20 21:43 ` [PATCH v2 02/21] rtc: Switch to use %ptR Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 03/21] rtc: at91rm9200: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 04/21] rtc: at91sam9: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 05/21] rtc: m41t80: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 06/21] rtc: m48t59: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 07/21] rtc: mcp795: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 08/21] rtc: pcf50633: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 09/21] rtc: pic32: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 10/21] rtc: pm8xxx: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 11/21] rtc: puv3: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 12/21] rtc: rk808: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 13/21] rtc: rx6110: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 14/21] rtc: rx8025: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 15/21] rtc: s3c: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 16/21] rtc: s5m: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 17/21] rtc: tegra: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 18/21] ds1302: " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 19/21] Input: hp_sdc_rtc - " Andy Shevchenko
2018-02-20 21:43 ` [PATCH v2 20/21] mk68/mac: " Andy Shevchenko
2018-02-21 9:38 ` Geert Uytterhoeven
2018-02-21 14:04 ` Andy Shevchenko
2018-02-20 21:44 ` [PATCH v2 21/21] PM: " Andy Shevchenko
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=1519221748.10722.34.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=a.zummo@towertech.it \
--cc=akpm@linux-foundation.org \
--cc=alexandre.belloni@free-electrons.com \
--cc=arnd@arndb.de \
--cc=b.zolnierkie@samsung.com \
--cc=corbet@lwn.net \
--cc=dmitry.torokhov@gmail.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=gxt@mprc.pku.edu.cn \
--cc=jason.wessel@windriver.com \
--cc=joe@perches.com \
--cc=jonathanh@nvidia.com \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rasmus.villemoes@prevas.dk \
--cc=rjw@rjwysocki.net \
--cc=salyzyn@android.com \
--cc=thierry.reding@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome