On Tue, 2013-12-31 at 15:53 +0900, Tetsuo Handa wrote:
> Joe Perches wrote:
> > Also I prefer using ASCII SUB (26 \x1a \032 ^z) or maybe
> > PU1 - 145 or PU2 - 146, as an initiator byte as it takes
> > up much less of the control word space instead of using
> > multiple values like \x80, \x81, \x82, etc. Using an
> > initiator byte seems more extensible too.
>
> My format and rules are:
>
> #define EMBED_FORMAT "0x7F"
> #define EMBED_CURRENT_COMM "0x80"
> #define EMBED_CURRENT_PID "0x81"
>
> We need to use EMBED_FORMAT prefix only when you want to specify one (or
> more) of flags, field width and precision options. That is,
>
> pr_info("%s(%d)\n", current->comm, current->pid);
> => pr_info(EMBED_CURRENT_COMM "(" EMBED_CURRENT_PID ")\n");
>
> pr_info("[%-6.6s]\n", current->comm);
> => pr_info(EMBED_FORMAT "-6.6" EMBED_CURRENT_COMM "\n");
>
> But I can't imagine what your format and rules are because
>
> #define CURRENT_SUB "\032"
> #define CURRENT_SUB_ASCII '\032'
>
> are ' ' character which is also used within the format string.
> Also, if you assign one of ('0' to '9', '-', '.') for variable name like
>
> #define CURRENT_ID CURRENT_SUB "1"
> #define CURRENT_COMM CURRENT_SUB "2"
>
> you will need a separating byte in order to distinguish end of
> flags, field width and precision options.
The goal of a single leading char is simply resource
economy. Using fewer chars from the available pool may be
better than using more. Using a couple more bytes in the
format string doesn't seem an excessive overhead.
> Please describe your format and rules (e.g. what byte starts a built-in token;
> what bytes are used for representing variable name, what separates flags,
> field
> width and precision options from variable name if these options are specified,
> what byte terminates a built-in token) using examples below.
>
> pr_info("%s(%d)\n", current->comm, current->pid);
pr_info(CURRENT_COMM "(" CURRENT_PID ")\n");
> pr_info("[%-6.6s]\n", current->comm);
I think using formatting controls for field widths and
such shouldn't be supported but if it is, then using yet
another macro form like below is possible
either:
#define CURRENT_COMM_FORMAT(fmt) \
CURRENT_SUB fmt "2"
or
#define CURRENT_COMM_FORMATTED(fmt) \
CURRENT_SUB __stringify(fmt) "2"
So maybe,
pr_info(CURRENT_COMM_FORMAT("-6.6") "\n");
or
pr_info(CURRENT_COMM_FORMATTED(-6.6) "\n");
depending on taste could work.
"2" would need changing to something like "t2" so any
leading format directives like field width and precision
could be done properly.
In other words: using a separating byte may be necessary if
some formatting directive support is required.
This wouldn't/couldn't work with formats where field length
is specified via "*" with a separate int.
Perhaps that's a good enough reason not to support using
format directives.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
