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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.