Received: by 10.223.185.116 with SMTP id b49csp861078wrg; Wed, 21 Feb 2018 08:05:54 -0800 (PST) X-Google-Smtp-Source: AH8x226ySFIJmAlzi64x3tjiW8VH5nD444dOjYGV971RJSD2AWJAyFPNnUCMNlx4r2N4aVkh7dhm X-Received: by 10.99.110.199 with SMTP id j190mr3097865pgc.404.1519229153881; Wed, 21 Feb 2018 08:05:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519229153; cv=none; d=google.com; s=arc-20160816; b=WW+ynJEs+6IuOlWP64QZelQVJBtxLKsWDFcVQq6ULqVzurzRTaKZUynCKlBQv3Rr6P nR+yTSeDagrtw9TX9SiKeLIIPVxwc134eXmnHue5HnbIErnRZhJeOKmVo8hqj+R106tf vZty50xGTL+OqaEsmrbx7DOYzNhPlPYUoxpDdF6ruBJjENm1490ivkdFh3kisIAkGaxn DRwZArG2k76nlxtCxzbwE10xTfyuyFlzx+ioAImld5MMRon4Tuojj/yQMftdeKU52xdz jokGRo2jruGi1h+V0p/2fEDxldrgrl50xfYeoZKzVOWA2WUktmNKlHge9keW1tKkJo72 JR+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=nyry8D6VODopZw4Fo17o6UjP+FpdW6fDiChatjVgQ/0=; b=sCxaqEG9wgrC/FV+0whK4v7bDUrGDudPgbUVERXGy+OWF6PWUrg9j0CfHXutTzvBX1 H3UpN0qyNKT1j8YOqBb0t9cpWpPPi8ZAX/UnnXgEYVmhmzMYmlklTeM4WgM7+fz0JfVv /nbARLzm4VjULJ8yLJ8zqTSxIRP9dIieBTqCgdNGmBPOgDKttTB7xCDLqRj/dxOmsj6L PuD0lfpq+baOvCoZUjPUAk9PvpCvd+ALuziaxPFNew7XHbUe3+MMc56ZdIxpleDHMhqz JgqvsjfQl2E1mi88zIQ5YITqD2xWJnHD/6Um0Oe6Wo6iVPPBy/GXR/yFQGebKLLBeb29 RQ+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=haUPVwEM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w7si1368293pgs.639.2018.02.21.08.05.39; Wed, 21 Feb 2018 08:05:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=haUPVwEM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753405AbeBUJdy (ORCPT + 99 others); Wed, 21 Feb 2018 04:33:54 -0500 Received: from mail-qk0-f174.google.com ([209.85.220.174]:33835 "EHLO mail-qk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753123AbeBUJdw (ORCPT ); Wed, 21 Feb 2018 04:33:52 -0500 Received: by mail-qk0-f174.google.com with SMTP id l206so1142996qke.1; Wed, 21 Feb 2018 01:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nyry8D6VODopZw4Fo17o6UjP+FpdW6fDiChatjVgQ/0=; b=haUPVwEMYck3DXxWhpqIF/vea4Anys3PQjYB05uAgR9JT90W3sXxrzEEp0pPpnVo7u N01IWCp5Thu3plmuRoF15dIqS+u/DbVTIz1H+wfjbCB1W98wVNecKJKbMFoNLBTQHHM7 IUochKIWuypgjvG/pvzEBmuZreJ19Yxe1u+mfH7kwfS3bfbsTIvAYjg+Fc4EsYGsvxD+ gh6SGqsbsqcxnhNSsO0/nM9vV3RkVlVKEVTgVxx3i9cO/BUqwL6IsIt1gEvQhzn7KhIl kX0LrdS5MrLITNYgH5S6ZFr0sCwWPzLilGapp0FN26o160CqzdDhNhuDFYnwhom9wQ0Z 43cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nyry8D6VODopZw4Fo17o6UjP+FpdW6fDiChatjVgQ/0=; b=hGePry1jSHvjeEZQ0Mox0N07YG9wwKAA04m+xr+IrHg2VWTJct7/nPGvqhv4adlE8h si7fXKjR7CpKeDwNGr2Ef+J8lQXVyhHOuFvbT1gFm8xQIQlB4OfNAJ2R/Khp+x4y5sF7 ulqFMEwGexqlA/C/OhlMnrBoNy/JnE2BjrAUPWTg9z4juIBjLno5gXdRm7xpoTggD+8e 9Qeuj9pgH2mnC/kBJyWbkAITx+wCYEhZBtQR8LcGqeTUSHFEXY4x1hSTeZ3gccUwuenY jtvXwXtMxxtWwNuOok/HabFlZ40ovT+XV/GJyJ2YKnPWxvVNV8ywZvQER5bcMpeApUHq hRrw== X-Gm-Message-State: APf1xPB3RhJrwV7ivsvsC0s8eIUx4dPQDRKMwB3x3ZF43gxocg3/ftWZ 2GYF/3O7Xwfl7C+pKoyQLZwGWBTt+rEGlIQSenY= X-Received: by 10.55.60.2 with SMTP id j2mr4223238qka.89.1519205631636; Wed, 21 Feb 2018 01:33:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.47.219 with HTTP; Wed, 21 Feb 2018 01:33:51 -0800 (PST) In-Reply-To: <20180220214400.66749-2-andriy.shevchenko@linux.intel.com> References: <20180220214400.66749-1-andriy.shevchenko@linux.intel.com> <20180220214400.66749-2-andriy.shevchenko@linux.intel.com> From: Geert Uytterhoeven Date: Wed, 21 Feb 2018 10:33:51 +0100 X-Google-Sender-Auth: vjoSOjTJFSVAkmJeD_F6yIc47AE Message-ID: Subject: Re: [PATCH v2 01/21] lib/vsprintf: Print time and date in human readable format via %pt To: Andy Shevchenko Cc: Rasmus Villemoes , Greg Kroah-Hartman , Andrew Morton , Linux Kernel Mailing List , Alessandro Zummo , Alexandre Belloni , linux-rtc@vger.kernel.org, Arnd Bergmann , Joe Perches , Mark Salyzyn , Bartlomiej Zolnierkiewicz , Dmitry Torokhov , Guan Xuetao , Ingo Molnar , Jason Wessel , Jonathan Corbet , Jonathan Hunter , Krzysztof Kozlowski , "Rafael J. Wysocki" , Thierry Reding Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andy, On Tue, Feb 20, 2018 at 10:43 PM, Andy Shevchenko 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? > --- 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? > + %pt[R][dt] What's the purpose of this? > + > + 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? > + > +For printing date and time as represented by struct rtc_time structure in > +human readable format. > @@ -1443,6 +1458,132 @@ char *address_val(char *buf, char *end, const void *addr, const char *fmt) > return special_hex_number(buf, end, num, size); > } > > +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. > + buf++; > + > + if (unlikely(v && (unsigned int)tm->tm_mon > 11)) > + buf = string(buf, end, "**", default_str_spec); > + else > + buf = number(buf, end, mon, default_dec02_spec); > + > + if (buf < end) > + *buf = '-'; > + buf++; > + > + if (unlikely(v && (unsigned int)tm->tm_mday > 31)) > + buf = string(buf, end, "**", default_str_spec); > + else > + buf = number(buf, end, tm->tm_mday, default_dec02_spec); > + > + return buf; > +} > + > +static noinline_for_stack > +char *time_str(char *buf, char *end, const struct rtc_time *tm, bool v, bool r) > +{ > + if (unlikely(v && (unsigned int)tm->tm_hour > 24)) > + buf = string(buf, end, "**", default_str_spec); > + else > + buf = number(buf, end, tm->tm_hour, default_dec02_spec); > + > + if (buf < end) > + *buf = ':'; Likewise. > + buf++; > + > + if (unlikely(v && (unsigned int)tm->tm_min > 59)) > + buf = string(buf, end, "**", default_str_spec); > + else > + buf = number(buf, end, tm->tm_min, default_dec02_spec); > + > + if (buf < end) > + *buf = ':'; > + buf++; > + > + if (unlikely(v && (unsigned int)tm->tm_sec > 59)) > + buf = string(buf, end, "**", default_str_spec); > + else > + buf = number(buf, end, tm->tm_sec, default_dec02_spec); > + > + return buf; > +} > + > +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; } Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds