| Message ID | 20210208200903.28084-1-sakari.ailus@linux.intel.com |
|---|---|
| Headers | show |
| Series | Add %p4cc printk modifier for V4L2 and DRM fourcc codes | expand |
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). ... > +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). > + 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? > + /* 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). > + *p++ = ')'; > + *p = '\0'; > + > + return string(buf, end, output, spec); > +}
On Mon, Feb 8, 2021 at 9:20 PM Sakari Ailus <sakari.ailus@linux.intel.com> wrote: > > Instead of constructing the FourCC code manually, use the %p4cc printk > modifier to print it. Also leave a message to avoid using this function. > > The next step would be to convert the users to use %p4cc directly instead > and removing the function. > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > --- > drivers/gpu/drm/drm_fourcc.c | 16 +++------------- > 1 file changed, 3 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c > index 03262472059c..4ff40f2f27c0 100644 > --- a/drivers/gpu/drm/drm_fourcc.c > +++ b/drivers/gpu/drm/drm_fourcc.c > @@ -30,11 +30,6 @@ > #include <drm/drm_device.h> > #include <drm/drm_fourcc.h> > > -static char printable_char(int c) > -{ > - return isascii(c) && isprint(c) ? c : '?'; > -} > - > /** > * drm_mode_legacy_fb_format - compute drm fourcc code from legacy description > * @bpp: bits per pixels > @@ -134,17 +129,12 @@ EXPORT_SYMBOL(drm_driver_legacy_fb_format); > * drm_get_format_name - fill a string with a drm fourcc format's name > * @format: format to compute name of > * @buf: caller-supplied buffer > + * > + * Please use %p4cc printk format modifier instead of this function. I think would be nice if we could roll this out and outright delete this one here ... Quick git grep says there's not that many, and %p4cc is quite a bit shorter than what we have now. -Daniel > */ > const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf) > { > - snprintf(buf->str, sizeof(buf->str), > - "%c%c%c%c %s-endian (0x%08x)", > - printable_char(format & 0xff), > - printable_char((format >> 8) & 0xff), > - printable_char((format >> 16) & 0xff), > - printable_char((format >> 24) & 0x7f), > - format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little", > - format); > + snprintf(buf->str, sizeof(buf->str), "%p4cc", &format); > > return buf->str; > } > -- > 2.29.2 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Daniel, Thanks for the comments. On Tue, Feb 09, 2021 at 08:27:10AM +0100, Daniel Vetter wrote: > On Mon, Feb 8, 2021 at 9:20 PM Sakari Ailus > <sakari.ailus@linux.intel.com> wrote: > > > > Instead of constructing the FourCC code manually, use the %p4cc printk > > modifier to print it. Also leave a message to avoid using this function. > > > > The next step would be to convert the users to use %p4cc directly instead > > and removing the function. > > > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > --- > > drivers/gpu/drm/drm_fourcc.c | 16 +++------------- > > 1 file changed, 3 insertions(+), 13 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c > > index 03262472059c..4ff40f2f27c0 100644 > > --- a/drivers/gpu/drm/drm_fourcc.c > > +++ b/drivers/gpu/drm/drm_fourcc.c > > @@ -30,11 +30,6 @@ > > #include <drm/drm_device.h> > > #include <drm/drm_fourcc.h> > > > > -static char printable_char(int c) > > -{ > > - return isascii(c) && isprint(c) ? c : '?'; > > -} > > - > > /** > > * drm_mode_legacy_fb_format - compute drm fourcc code from legacy description > > * @bpp: bits per pixels > > @@ -134,17 +129,12 @@ EXPORT_SYMBOL(drm_driver_legacy_fb_format); > > * drm_get_format_name - fill a string with a drm fourcc format's name > > * @format: format to compute name of > > * @buf: caller-supplied buffer > > + * > > + * Please use %p4cc printk format modifier instead of this function. > > I think would be nice if we could roll this out and outright delete > this one here ... Quick git grep says there's not that many, and %p4cc > is quite a bit shorter than what we have now. Sounds good; I can submit patches for that but I think I'll do that once we have the %p4cc modifier in.
On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote: > 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: ... > > > + %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. But then the code suggests otherwise. Perhaps we need to extract skip_trailing_spaces() from strim() and use it here. ... > > > +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. Where? \xHH is quite well established format for escaping. Never heard about '(xx)' variant before this very series. > Note that neither DRM nor V4L2 currently has such fourcc codes currently. ... > > > + 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. :-) Yes, you can. The problem is that we agreed with others to improve readability by letting some lines to be longer, so the code can lie on one line rather be broken on two or more.
Hi Petr, Thanks for the comments. On Thu, Feb 11, 2021 at 06:14:28PM +0100, Petr Mladek wrote: > On Tue 2021-02-09 19:47:55, Sakari Ailus wrote: > > Hi Andy, > > > > On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote: > > > On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote: > > > > 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: > > > > > > ... > > > > > > > > > + %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. > > > > > > But then the code suggests otherwise. Perhaps we need to extract > > > skip_trailing_spaces() from strim() and use it here. > > > > But this wouldn't affect the result in this case, would it? > > Is there any existing implementation that would skip spaces, please? > > IMHO, this might just hide problems. We should show exactly what > is stored unless anyone explicitly ask for skipping that spaces. I discussed this with Hans and we concluded spaces shouldn't be dropped. Spaces can be present in the codes themselves in any case. > > > > > > > ... > > > > > > > > > +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. > > > > > > Where? \xHH is quite well established format for escaping. Never heard about > > > '(xx)' variant before this very series. > > > Mauro referred to FourCC codes while reviewing an earlier version of this, > > such as RGB(15). > > This is quite easy to parse. The problem is that it is not clear > whether it is hexa or decimal number. > > > Does \× imply only the next two characters are hexadecimal? I have to admit > > I don't remember seeting that, nor \x notation is common. > > Hmm, the /xyy format might be hard to parse. > > What about using the same approach as drm_get_format_name()? > I mean printing '?' when the character is not printable. > The exact value is printed later anyway. > > The advantage is that it will always printk 4 characters. "?" can be expanded by the shell. We (me and Hans) both though a dot (".") would be good. These aren't going to be present in valid fourcc codes in any case. > > > > > > Note that neither DRM nor V4L2 currently has such fourcc codes currently. > > > > > > ... > > > > > > > > > + 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). > > Ailus, please do not take this as a criticism of your patch. > I understand that it might have sounded like this but Andy did > not mean it. > > Andy prefers slightly longer lines over wrapping only few characters. > It makes sense to me. There are more people with the same opinion. > Even checkpatch.pl tolerates lines up to 100 characters these days. > > Of course, this is a subsystem specific preference. You did not have > any chance to know it. There is no need to fight over it. Fair enough; I can violate the coding style a little in v7.
On Fri 2021-02-12 13:28:56, Sakari Ailus wrote: > On Thu, Feb 11, 2021 at 06:14:28PM +0100, Petr Mladek wrote: > > On Tue 2021-02-09 19:47:55, Sakari Ailus wrote: > > > Hi Andy, > > > > > > On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote: > > > > On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote: > > > > > 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: > > > > > > > > > > > + %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). > > I discussed this with Hans and we concluded spaces shouldn't be dropped. > > Spaces can be present in the codes themselves in any case. Great! > > > > > > > > > > ... > > > > > > > > > > > +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. > > > > > > > > Where? \xHH is quite well established format for escaping. Never heard about > > > > '(xx)' variant before this very series. > > > > What about using the same approach as drm_get_format_name()? > > I mean printing '?' when the character is not printable. > > The exact value is printed later anyway. > > > > The advantage is that it will always printk 4 characters. > > "?" can be expanded by the shell. We (me and Hans) both though a dot (".") > would be good. These aren't going to be present in valid fourcc codes in > any case. The dot (".") looks fine to me. Best Regards, Petr