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:
quoted
Hi Andy,
On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
quoted
On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
quoted
On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
quoted
On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus
[off-list ref] wrote:
...
quoted
quoted
quoted
+ %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.
quoted
quoted
...
quoted
quoted
quoted
+static noinline_for_stack
+char *fourcc_string(char *buf, char *end, const u32 *fourcc,
+ struct printf_spec spec, const char *fmt)
+{
quoted
+ 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.
quoted
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.
quoted
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.
quoted
quoted
quoted
Note that neither DRM nor V4L2 currently has such fourcc codes currently.
...
quoted
quoted
quoted
+ 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.
--
Kind regards,
Sakari Ailus