All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Petr Mladek <pmladek@suse.com>,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Joe Perches <joe@perches.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
Date: Tue, 9 Feb 2021 11:20:32 +0200	[thread overview]
Message-ID: <20210209092032.GC32460@paasikivi.fi.intel.com> (raw)
In-Reply-To: <CAHp75VciFMKrWM2zJZ6dppuL5M-7BLPGQfcnzkd9pQzY1bRWsQ@mail.gmail.com>

Hi Andy,

On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by fourccs. The fourcc encoding is the same for both
> > so the same implementation can be used.
> 
> Thank you for an update with the examples how current users will be
> converted. Below review is based on the users I had seen so far and
> assumptions made in this code. I see that it's tagged by maintainers,
> but I can't help to comment again on this. In any case the decision is
> up to them.
> 
> ...
> 
> > +V4L2 and DRM FourCC code (pixel format)
> > +---------------------------------------
> > +
> > +::
> > +
> > +       %p4cc
> > +
> > +Print a FourCC code used by V4L2 or DRM, including format endianness and
> > +its numerical value as hexadecimal.
> > +
> > +Passed by reference.
> > +
> > +Examples::
> > +
> > +       %p4cc   BG12 little-endian (0x32314742)
> 
> This misses examples of the (strange) escaping cases and wiped
> whitespaces to make sure everybody understands that 'D 12' will be the
> same as 'D1 2' (side note: which I disagree on, perhaps something
> should be added into documentation why).

The spaces are expected to be at the end only. I can add such example if
you like. There are no fourcc codes with spaces in the middle in neither
V4L2 nor DRM, and I don't think the expectation is to have them either.

> 
> ...
> 
> > +static noinline_for_stack
> > +char *fourcc_string(char *buf, char *end, const u32 *fourcc,
> > +                   struct printf_spec spec, const char *fmt)
> > +{
> 
> > +       char output[sizeof("(xx)(xx)(xx)(xx) little-endian (0x01234567)")];
> 
> Do we have any evidence / document / standard that the above format is
> what people would find good? From existing practices (I consider other
> printings elsewhere and users in this series) I find '(xx)' form for
> hex numbers is weird. The standard practice is to use \xHH (without
> parentheses).

Earlier in the review it was proposed that special handling of codes below
32 should be added, which I did. Using the parentheses is apparently an
existing practice elsewhere.

Note that neither DRM nor V4L2 currently has such fourcc codes currently.

> 
> > +       char *p = output;
> > +       unsigned int i;
> > +       u32 val;
> > +
> > +       if (fmt[1] != 'c' || fmt[2] != 'c')
> > +               return error_string(buf, end, "(%p4?)", spec);
> > +
> > +       if (check_pointer(&buf, end, fourcc, spec))
> > +               return buf;
> > +
> > +       val = *fourcc & ~BIT(31);
> > +
> > +       for (i = 0; i < sizeof(*fourcc); i++) {
> > +               unsigned char c = val >> (i * 8);
> 
> ...
> 
> > +               /* Weed out spaces */
> > +               if (c == ' ')
> > +                       continue;
> 
> None of the existing users does that. Why?

The existing instances of printing fourcc codes in V4L2 are scattered
around with priority on implementation simplicity. As we have a single
simplementation here, I'm not really worried about that.

> 
> > +               /* Print non-control ASCII characters as-is */
> > +               if (isascii(c) && isprint(c)) {
> > +                       *p++ = c;
> > +                       continue;
> > +               }
> > +
> > +               *p++ = '(';
> > +               p = hex_byte_pack(p, c);
> > +               *p++ = ')';
> > +       }
> > +
> > +       strcpy(p, *fourcc & BIT(31) ? " big-endian" : " little-endian");
> > +       p += strlen(p);
> > +
> > +       *p++ = ' ';
> > +       *p++ = '(';
> 
> > +       p = special_hex_number(p, output + sizeof(output) - 2, *fourcc,
> > +                              sizeof(u32));
> 
> This is perfectly one line (in this file we have even longer lines).

Sure, you can do that, and I can then review your patch and point to the
coding style documentation. :-)

> 
> > +       *p++ = ')';
> > +       *p = '\0';
> > +
> > +       return string(buf, end, output, spec);
> > +}
> 

-- 
Kind regards,

Sakari Ailus

WARNING: multiple messages have this Message-ID (diff)
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Joe Perches <joe@perches.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
Date: Tue, 9 Feb 2021 11:20:32 +0200	[thread overview]
Message-ID: <20210209092032.GC32460@paasikivi.fi.intel.com> (raw)
In-Reply-To: <CAHp75VciFMKrWM2zJZ6dppuL5M-7BLPGQfcnzkd9pQzY1bRWsQ@mail.gmail.com>

Hi Andy,

On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by fourccs. The fourcc encoding is the same for both
> > so the same implementation can be used.
> 
> Thank you for an update with the examples how current users will be
> converted. Below review is based on the users I had seen so far and
> assumptions made in this code. I see that it's tagged by maintainers,
> but I can't help to comment again on this. In any case the decision is
> up to them.
> 
> ...
> 
> > +V4L2 and DRM FourCC code (pixel format)
> > +---------------------------------------
> > +
> > +::
> > +
> > +       %p4cc
> > +
> > +Print a FourCC code used by V4L2 or DRM, including format endianness and
> > +its numerical value as hexadecimal.
> > +
> > +Passed by reference.
> > +
> > +Examples::
> > +
> > +       %p4cc   BG12 little-endian (0x32314742)
> 
> This misses examples of the (strange) escaping cases and wiped
> whitespaces to make sure everybody understands that 'D 12' will be the
> same as 'D1 2' (side note: which I disagree on, perhaps something
> should be added into documentation why).

The spaces are expected to be at the end only. I can add such example if
you like. There are no fourcc codes with spaces in the middle in neither
V4L2 nor DRM, and I don't think the expectation is to have them either.

> 
> ...
> 
> > +static noinline_for_stack
> > +char *fourcc_string(char *buf, char *end, const u32 *fourcc,
> > +                   struct printf_spec spec, const char *fmt)
> > +{
> 
> > +       char output[sizeof("(xx)(xx)(xx)(xx) little-endian (0x01234567)")];
> 
> Do we have any evidence / document / standard that the above format is
> what people would find good? From existing practices (I consider other
> printings elsewhere and users in this series) I find '(xx)' form for
> hex numbers is weird. The standard practice is to use \xHH (without
> parentheses).

Earlier in the review it was proposed that special handling of codes below
32 should be added, which I did. Using the parentheses is apparently an
existing practice elsewhere.

Note that neither DRM nor V4L2 currently has such fourcc codes currently.

> 
> > +       char *p = output;
> > +       unsigned int i;
> > +       u32 val;
> > +
> > +       if (fmt[1] != 'c' || fmt[2] != 'c')
> > +               return error_string(buf, end, "(%p4?)", spec);
> > +
> > +       if (check_pointer(&buf, end, fourcc, spec))
> > +               return buf;
> > +
> > +       val = *fourcc & ~BIT(31);
> > +
> > +       for (i = 0; i < sizeof(*fourcc); i++) {
> > +               unsigned char c = val >> (i * 8);
> 
> ...
> 
> > +               /* Weed out spaces */
> > +               if (c == ' ')
> > +                       continue;
> 
> None of the existing users does that. Why?

The existing instances of printing fourcc codes in V4L2 are scattered
around with priority on implementation simplicity. As we have a single
simplementation here, I'm not really worried about that.

> 
> > +               /* Print non-control ASCII characters as-is */
> > +               if (isascii(c) && isprint(c)) {
> > +                       *p++ = c;
> > +                       continue;
> > +               }
> > +
> > +               *p++ = '(';
> > +               p = hex_byte_pack(p, c);
> > +               *p++ = ')';
> > +       }
> > +
> > +       strcpy(p, *fourcc & BIT(31) ? " big-endian" : " little-endian");
> > +       p += strlen(p);
> > +
> > +       *p++ = ' ';
> > +       *p++ = '(';
> 
> > +       p = special_hex_number(p, output + sizeof(output) - 2, *fourcc,
> > +                              sizeof(u32));
> 
> This is perfectly one line (in this file we have even longer lines).

Sure, you can do that, and I can then review your patch and point to the
coding style documentation. :-)

> 
> > +       *p++ = ')';
> > +       *p = '\0';
> > +
> > +       return string(buf, end, output, spec);
> > +}
> 

-- 
Kind regards,

Sakari Ailus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2021-02-09  9:25 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08 20:09 [PATCH v6 0/3] Add %p4cc printk modifier for V4L2 and DRM fourcc codes Sakari Ailus
2021-02-08 20:09 ` Sakari Ailus
2021-02-08 20:09 ` [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs Sakari Ailus
2021-02-08 20:09   ` Sakari Ailus
2021-02-08 20:43   ` Andy Shevchenko
2021-02-08 20:43     ` Andy Shevchenko
2021-02-08 20:58     ` Andy Shevchenko
2021-02-08 20:58       ` Andy Shevchenko
2021-02-09 10:01       ` Andy Shevchenko
2021-02-09 10:01         ` Andy Shevchenko
2021-02-09  9:20     ` Sakari Ailus [this message]
2021-02-09  9:20       ` Sakari Ailus
2021-02-09  9:58       ` Andy Shevchenko
2021-02-09  9:58         ` Andy Shevchenko
2021-02-09 17:47         ` Sakari Ailus
2021-02-09 17:47           ` Sakari Ailus
2021-02-11 17:14           ` Petr Mladek
2021-02-11 17:14             ` Petr Mladek
2021-02-12 11:28             ` Sakari Ailus
2021-02-12 11:28               ` Sakari Ailus
2021-02-12 12:06               ` Petr Mladek
2021-02-12 12:06                 ` Petr Mladek
2021-02-08 20:09 ` [PATCH v6 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes Sakari Ailus
2021-02-08 20:09   ` Sakari Ailus
2021-02-11 16:31   ` Petr Mladek
2021-02-11 16:31     ` Petr Mladek
2021-02-12 10:01     ` Sakari Ailus
2021-02-12 10:01       ` Sakari Ailus
2021-02-08 20:09 ` [PATCH v6 3/3] drm/fourcc: Switch to %p4cc format modifier Sakari Ailus
2021-02-08 20:09   ` Sakari Ailus
2021-02-09  7:27   ` Daniel Vetter
2021-02-09  7:27     ` Daniel Vetter
2021-02-09  9:03     ` Sakari Ailus
2021-02-09  9:03       ` Sakari Ailus

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=20210209092032.GC32460@paasikivi.fi.intel.com \
    --to=sakari.ailus@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hverkuil@xs4all.nl \
    --cc=jani.nikula@linux.intel.com \
    --cc=joe@perches.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mchehab@kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@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.