Tetsuo Handa wrote:
> Pavel Machek wrote:
> > > + * Please use this wrapper function which will be updated in the future
> > > to read
> > > + * @tsk->comm in a consistent way.
> > > + */
> > > +static inline int commcmp(const struct task_struct *tsk, const char
> > > *comm)
> > > +{
> > > +
Tetsuo Handa wrote:
Pavel Machek wrote:
+ * Please use this wrapper function which will be updated in the future
to read
+ * @tsk-comm in a consistent way.
+ */
+static inline int commcmp(const struct task_struct *tsk, const char
*comm)
+{
+ return strcmp(tsk-comm,
On Wed 2014-01-08 23:19:04, Tetsuo Handa wrote:
> Pavel Machek wrote:
> > > > > I'm not nacking this, just stating my view.
> > > >
> > > > And I believe Andrew clearly stated his view, on the very topic you
> > > > asked him on.
> > >
> > > I believe Andrew's view:
> > >
> > > On Sat,
Pavel Machek wrote:
> > > > I'm not nacking this, just stating my view.
> > >
> > > And I believe Andrew clearly stated his view, on the very topic you
> > > asked him on.
> >
> > I believe Andrew's view:
> >
> > On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > > On Sat, 28 Dec 2013
Pavel Machek wrote:
I'm not nacking this, just stating my view.
And I believe Andrew clearly stated his view, on the very topic you
asked him on.
I believe Andrew's view:
On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
On Sat, 28 Dec 2013 11:53:25 -0800 Joe
On Wed 2014-01-08 23:19:04, Tetsuo Handa wrote:
Pavel Machek wrote:
I'm not nacking this, just stating my view.
And I believe Andrew clearly stated his view, on the very topic you
asked him on.
I believe Andrew's view:
On Sat, 2013-12-28 at 12:08 -0800, Andrew
On Tue, Jan 7, 2014 at 6:56 PM, Pavel Machek wrote:
>> The additional cost of using current vs NULL is ~zero.
>
> The additional cost of current vs NULL is cca 8 bytes per caller. Test
> for NULL is cca 4 bytes, maybe 20 bytes total. I believe it is worth
> it.
It depends (typical answer ;-)
On
> > > I'm not nacking this, just stating my view.
> >
> > And I believe Andrew clearly stated his view, on the very topic you
> > asked him on.
>
> I believe Andrew's view:
>
> On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
>
On Tue, 2014-01-07 at 09:37 +0100, Pavel Machek wrote:
> On Mon 2014-01-06 17:03:55, Joe Perches wrote:
> > On Tue, 2014-01-07 at 01:16 +0100, Pavel Machek wrote:
> > > > > > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > > > > > []
> > > > > > > @@ -1232,7 +1248,7 @@ char *pointer(const char
On Mon 2014-01-06 17:03:55, Joe Perches wrote:
> On Tue, 2014-01-07 at 01:16 +0100, Pavel Machek wrote:
> > > > > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > > > > []
> > > > > > @@ -1232,7 +1248,7 @@ char *pointer(const char *fmt, char *buf,
> > > > > > char *end, void *ptr,
> > > > > >
On Mon 2014-01-06 17:03:55, Joe Perches wrote:
On Tue, 2014-01-07 at 01:16 +0100, Pavel Machek wrote:
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
[]
@@ -1232,7 +1248,7 @@ char *pointer(const char *fmt, char *buf,
char *end, void *ptr,
{
int default_width
On Tue, 2014-01-07 at 09:37 +0100, Pavel Machek wrote:
On Mon 2014-01-06 17:03:55, Joe Perches wrote:
On Tue, 2014-01-07 at 01:16 +0100, Pavel Machek wrote:
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
[]
@@ -1232,7 +1248,7 @@ char *pointer(const char *fmt, char *buf,
I'm not nacking this, just stating my view.
And I believe Andrew clearly stated his view, on the very topic you
asked him on.
I believe Andrew's view:
On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches j...@perches.com wrote:
On Tue, Jan 7, 2014 at 6:56 PM, Pavel Machek pa...@ucw.cz wrote:
The additional cost of using current vs NULL is ~zero.
The additional cost of current vs NULL is cca 8 bytes per caller. Test
for NULL is cca 4 bytes, maybe 20 bytes total. I believe it is worth
it.
It depends (typical answer
On Tue, 2014-01-07 at 01:16 +0100, Pavel Machek wrote:
> > > > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > > > []
> > > > > @@ -1232,7 +1248,7 @@ char *pointer(const char *fmt, char *buf, char
> > > > > *end, void *ptr,
> > > > > {
> > > > > int default_width = 2 * sizeof(void *) +
Hi!
> > > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > > []
> > > > @@ -1232,7 +1248,7 @@ char *pointer(const char *fmt, char *buf, char
> > > > *end, void *ptr,
> > > > {
> > > > int default_width = 2 * sizeof(void *) + (spec.flags & SPECIAL
> > > > ? 2 : 0);
> > > >
> > > > -
On Tue, 2014-01-07 at 06:41 +0900, Tetsuo Handa wrote:
> Joe Perches wrote:
> > On Mon, 2014-01-06 at 23:00 +0900, Tetsuo Handa wrote:
> > > Joe Perches wrote:
> > > > Is this really necessary?
> > > No problem. %pT[012] are simply optimization (reducing number of function
> > > arguments for
Joe Perches wrote:
> On Mon, 2014-01-06 at 23:00 +0900, Tetsuo Handa wrote:
> > Joe Perches wrote:
> > > Is this really necessary?
> > No problem. %pT[012] are simply optimization (reducing number of function
> > arguments for saving text size) and therefore I can drop them.
> > What about below
On Mon 2014-01-06 23:00:56, Tetsuo Handa wrote:
> Joe Perches wrote:
> > On Sun, 2014-01-05 at 12:15 +0900, Tetsuo Handa wrote:
> > > > Since my purpose is to make reading of task_struct->comm consistent,
> > > > %pT-like
> > > > extension is what I want for centralizing pointer dereferences.
> >
On Mon, 2014-01-06 at 23:00 +0900, Tetsuo Handa wrote:
> Joe Perches wrote:
> > Is this really necessary?
> No problem. %pT[012] are simply optimization (reducing number of function
> arguments for saving text size) and therefore I can drop them.
> What about below patch?
Hi Tetsuo. Just a nit.
Joe Perches wrote:
> On Sun, 2014-01-05 at 12:15 +0900, Tetsuo Handa wrote:
> > > Since my purpose is to make reading of task_struct->comm consistent,
> > > %pT-like
> > > extension is what I want for centralizing pointer dereferences.
> >
> > If we have no objections for %pT[C012] patch,
>
> I
Pavel Machek wrote:
> > + * Please use this wrapper function which will be updated in the future to
> > read
> > + * @tsk->comm in a consistent way.
> > + */
> > +static inline int commcmp(const struct task_struct *tsk, const char *comm)
> > +{
> > + return strcmp(tsk->comm, comm);
> > +}
>
>
Pavel Machek wrote:
+ * Please use this wrapper function which will be updated in the future to
read
+ * @tsk-comm in a consistent way.
+ */
+static inline int commcmp(const struct task_struct *tsk, const char *comm)
+{
+ return strcmp(tsk-comm, comm);
+}
Is this useful to
Joe Perches wrote:
On Sun, 2014-01-05 at 12:15 +0900, Tetsuo Handa wrote:
Since my purpose is to make reading of task_struct-comm consistent,
%pT-like
extension is what I want for centralizing pointer dereferences.
If we have no objections for %pT[C012] patch,
I still believe
On Mon, 2014-01-06 at 23:00 +0900, Tetsuo Handa wrote:
Joe Perches wrote:
Is this really necessary?
No problem. %pT[012] are simply optimization (reducing number of function
arguments for saving text size) and therefore I can drop them.
What about below patch?
Hi Tetsuo. Just a nit.
diff
On Mon 2014-01-06 23:00:56, Tetsuo Handa wrote:
Joe Perches wrote:
On Sun, 2014-01-05 at 12:15 +0900, Tetsuo Handa wrote:
Since my purpose is to make reading of task_struct-comm consistent,
%pT-like
extension is what I want for centralizing pointer dereferences.
If we have
Joe Perches wrote:
On Mon, 2014-01-06 at 23:00 +0900, Tetsuo Handa wrote:
Joe Perches wrote:
Is this really necessary?
No problem. %pT[012] are simply optimization (reducing number of function
arguments for saving text size) and therefore I can drop them.
What about below patch?
Hi
On Tue, 2014-01-07 at 06:41 +0900, Tetsuo Handa wrote:
Joe Perches wrote:
On Mon, 2014-01-06 at 23:00 +0900, Tetsuo Handa wrote:
Joe Perches wrote:
Is this really necessary?
No problem. %pT[012] are simply optimization (reducing number of function
arguments for saving text size)
Hi!
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
[]
@@ -1232,7 +1248,7 @@ char *pointer(const char *fmt, char *buf, char
*end, void *ptr,
{
int default_width = 2 * sizeof(void *) + (spec.flags SPECIAL
? 2 : 0);
- if (!ptr *fmt != 'K') {
On Tue, 2014-01-07 at 01:16 +0100, Pavel Machek wrote:
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
[]
@@ -1232,7 +1248,7 @@ char *pointer(const char *fmt, char *buf, char
*end, void *ptr,
{
int default_width = 2 * sizeof(void *) + (spec.flags SPECIAL
?
Hi!
> + * Please use this wrapper function which will be updated in the future to
> read
> + * @tsk->comm in a consistent way.
> + */
> +static inline int commcmp(const struct task_struct *tsk, const char *comm)
> +{
> + return strcmp(tsk->comm, comm);
> +}
Is this useful to something?
On Sun, 2014-01-05 at 12:15 +0900, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > Since my purpose is to make reading of task_struct->comm consistent,
> > %pT-like
> > extension is what I want for centralizing pointer dereferences.
>
> If we have no objections for %pT[C012] patch,
I still
On Sun, 2014-01-05 at 12:15 +0900, Tetsuo Handa wrote:
Tetsuo Handa wrote:
Since my purpose is to make reading of task_struct-comm consistent,
%pT-like
extension is what I want for centralizing pointer dereferences.
If we have no objections for %pT[C012] patch,
I still believe emitting
Hi!
+ * Please use this wrapper function which will be updated in the future to
read
+ * @tsk-comm in a consistent way.
+ */
+static inline int commcmp(const struct task_struct *tsk, const char *comm)
+{
+ return strcmp(tsk-comm, comm);
+}
Is this useful to something? Printing
Tetsuo Handa wrote:
> Since my purpose is to make reading of task_struct->comm consistent, %pT-like
> extension is what I want for centralizing pointer dereferences.
If we have no objections for %pT[C012] patch, I'd like to propose a counterpart
patch for users reading/copying task_struct->comm
Tetsuo Handa wrote:
Since my purpose is to make reading of task_struct-comm consistent, %pT-like
extension is what I want for centralizing pointer dereferences.
If we have no objections for %pT[C012] patch, I'd like to propose a counterpart
patch for users reading/copying task_struct-comm for
I'm planning to convert task_struct->comm to use RCU so that they always get
consistent result. Inconsistent result (e.g. trailing '\0' byte is emitted when
printing string argument) is caused by breaking a rule that the string argument
must not change during the function when it is passed as
On Fri, Jan 3, 2014 at 9:39 AM, Joe Perches wrote:
> On Fri, 2014-01-03 at 09:08 -0800, Kees Cook wrote:
>> I'm on board with the idea of embedding comm/pid/whatever,
>
> I still think the space reduction isn't worth the
> complication.
>
>> but I
>> either missed or do not understand why a
On Fri, 2014-01-03 at 09:08 -0800, Kees Cook wrote:
> I'm on board with the idea of embedding comm/pid/whatever,
I still think the space reduction isn't worth the
complication.
> but I
> either missed or do not understand why a second format-start character
> is being added. I think this will
On Wed, Jan 1, 2014 at 8:49 PM, Tetsuo Handa
wrote:
> From: Tetsuo Handa
> Date: Thu, 2 Jan 2014 13:37:14 +0900
> Subject: [PATCH v3] lib/vsprintf: support built-in tokens
>
> The vast majority of ->comm accesses are accessing current->comm, for
> debug reasons. I'm counting 350-odd sites. At
On Wed, Jan 1, 2014 at 8:49 PM, Tetsuo Handa
penguin-ker...@i-love.sakura.ne.jp wrote:
From: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Date: Thu, 2 Jan 2014 13:37:14 +0900
Subject: [PATCH v3] lib/vsprintf: support built-in tokens
The vast majority of -comm accesses are accessing
On Fri, 2014-01-03 at 09:08 -0800, Kees Cook wrote:
I'm on board with the idea of embedding comm/pid/whatever,
I still think the space reduction isn't worth the
complication.
but I
either missed or do not understand why a second format-start character
is being added. I think this will
On Fri, Jan 3, 2014 at 9:39 AM, Joe Perches j...@perches.com wrote:
On Fri, 2014-01-03 at 09:08 -0800, Kees Cook wrote:
I'm on board with the idea of embedding comm/pid/whatever,
I still think the space reduction isn't worth the
complication.
but I
either missed or do not understand why a
I'm planning to convert task_struct-comm to use RCU so that they always get
consistent result. Inconsistent result (e.g. trailing '\0' byte is emitted when
printing string argument) is caused by breaking a rule that the string argument
must not change during the function when it is passed as const
Hi!
> > > > #define PRINTK_PID "\002"
> > > > #define PRINTK_TASK_ID "\003" /* "comm:pid" */
> > > >
> > > > printk(PRINTK_TASK_ID ": hair on fire\n");
> > > >
> > > > It's certainly compact. I doubt if there's any existing code which
> > > > deliberately prints control chars?
> >
Hi!
#define PRINTK_PID \002
#define PRINTK_TASK_ID \003 /* comm:pid */
printk(PRINTK_TASK_ID : hair on fire\n);
It's certainly compact. I doubt if there's any existing code which
deliberately prints control chars?
But the rest looks OK to me.
Joe Perches wrote:
> On Wed, 2014-01-01 at 19:02 +0900, Tetsuo Handa wrote:
> > Joe Perches wrote:
> > > > This choice (i.e. reserve only '\xFF') is more resource economy than my
> > > > previous choice (i.e. reserve '\x7F' to '\xFF') at the cost of wasting
> > > > only
> > > > one byte compared
btw: Those -6.6 field width uses really are just for debugging
and I think should be removed. I didn't notice any other uses of
field widths and current->. Are there any?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Wed, 2014-01-01 at 19:02 +0900, Tetsuo Handa wrote:
> Joe Perches wrote:
> > > This choice (i.e. reserve only '\xFF') is more resource economy than my
> > > previous choice (i.e. reserve '\x7F' to '\xFF') at the cost of wasting
> > > only
> > > one byte compared to my previous choice.
> >
> >
Joe Perches wrote:
> > This choice (i.e. reserve only '\xFF') is more resource economy than my
> > previous choice (i.e. reserve '\x7F' to '\xFF') at the cost of wasting only
> > one byte compared to my previous choice.
>
> I supposed that's better.
>
> Is there a particularly utility/reason to
Joe Perches wrote:
This choice (i.e. reserve only '\xFF') is more resource economy than my
previous choice (i.e. reserve '\x7F' to '\xFF') at the cost of wasting only
one byte compared to my previous choice.
I supposed that's better.
Is there a particularly utility/reason to use 0xff
On Wed, 2014-01-01 at 19:02 +0900, Tetsuo Handa wrote:
Joe Perches wrote:
This choice (i.e. reserve only '\xFF') is more resource economy than my
previous choice (i.e. reserve '\x7F' to '\xFF') at the cost of wasting
only
one byte compared to my previous choice.
I supposed
btw: Those -6.6 field width uses really are just for debugging
and I think should be removed. I didn't notice any other uses of
field widths and current-value. Are there any?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Joe Perches wrote:
On Wed, 2014-01-01 at 19:02 +0900, Tetsuo Handa wrote:
Joe Perches wrote:
This choice (i.e. reserve only '\xFF') is more resource economy than my
previous choice (i.e. reserve '\x7F' to '\xFF') at the cost of wasting
only
one byte compared to my previous
On Wed, 2014-01-01 at 14:34 +0900, Tetsuo Handa wrote:
> I think we want formatting directive support because we have users shown
> below.
>
> fs/afs/internal.h: printk("[%-6.6s] "FMT"\n", current->comm
> ,##__VA_ARGS__)
> fs/cachefiles/internal.h: printk(KERN_DEBUG "[%-6.6s]
Joe Perches wrote:
> > 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
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,
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.
Joe Perches wrote:
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
On Wed, 2014-01-01 at 14:34 +0900, Tetsuo Handa wrote:
I think we want formatting directive support because we have users shown
below.
fs/afs/internal.h: printk([%-6.6s] FMT\n, current-comm
,##__VA_ARGS__)
fs/cachefiles/internal.h: printk(KERN_DEBUG [%-6.6s] FMT\n,
Joe Perches wrote:
> I get:
>
> $ grep-2.5.4 -rP --include=*.[ch] -oh \
>
> "\b(?:printk|[a-z_]+_(?:printk|emerg|alert|crit|err|warn|notice|info|debug|dbg))[^;]*\bcurrent->[\w_]+"
> * | \
> grep -P -oh "\bcurrent->[\w_]+"| sort | uniq -c | sort -rn
> 380 current->pid
> 267
On Sun, 2013-12-29 at 21:13 +0900, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > Joe Perches wrote:
> > > On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > > > On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
> > > >
> > > > > > > #define PRINTK_PID "\002"
> > > > > > >
On Sun, 2013-12-29 at 21:13 +0900, Tetsuo Handa wrote:
Tetsuo Handa wrote:
Joe Perches wrote:
On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches j...@perches.com wrote:
#define PRINTK_PID \002
#define
Joe Perches wrote:
I get:
$ grep-2.5.4 -rP --include=*.[ch] -oh \
\b(?:printk|[a-z_]+_(?:printk|emerg|alert|crit|err|warn|notice|info|debug|dbg))[^;]*\bcurrent-[\w_]+
* | \
grep -P -oh \bcurrent-[\w_]+| sort | uniq -c | sort -rn
380 current-pid
267 current-comm
We also
Tetsuo Handa wrote:
> Joe Perches wrote:
> > On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > > On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
> > >
> > > > > > #define PRINTK_PID "\002"
> > > > > > #define PRINTK_TASK_ID "\003" /* "comm:pid" */
> >
> > > > > >
> > > >
Tetsuo Handa wrote:
Joe Perches wrote:
On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches j...@perches.com wrote:
#define PRINTK_PID \002
#define PRINTK_TASK_ID \003 /* comm:pid */
On Sun, 2013-12-29 at 09:32 +0900, Tetsuo Handa wrote:
> Joe Perches wrote:
> > On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > > On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
> > >
> > > > > > #define PRINTK_PID "\002"
> > > > > > #define PRINTK_TASK_ID "\003" /*
Joe Perches wrote:
> On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
> >
> > > > > #define PRINTK_PID "\002"
> > > > > #define PRINTK_TASK_ID "\003" /* "comm:pid" */
>
> > > > >
> > > > > printk(PRINTK_TASK_ID ":
On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
>
> > > > #define PRINTK_PID "\002"
> > > > #define PRINTK_TASK_ID "\003" /* "comm:pid" */
> > > >
> > > > printk(PRINTK_TASK_ID ": hair on fire\n");
> > > >
> > > >
On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
> > > #define PRINTK_PID "\002"
> > > #define PRINTK_TASK_ID "\003" /* "comm:pid" */
> > >
> > > printk(PRINTK_TASK_ID ": hair on fire\n");
> > >
> > > It's certainly compact. I doubt if there's any existing code which
> > >
On Sat, 2013-12-28 at 20:25 +0100, Geert Uytterhoeven wrote:
> On Sat, Dec 28, 2013 at 8:25 PM, Andrew Morton
> wrote:
> >> Is any of the "\x" (backslash + character) unused and thus available?
> >
> > I guess control characters would work.
> >
> > #define PRINTK_COMM "\001"
>
> Not that
On Sat, Dec 28, 2013 at 8:25 PM, Andrew Morton
wrote:
>> Is any of the "\x" (backslash + character) unused and thus available?
>
> I guess control characters would work.
>
> #define PRINTK_COMM "\001"
Not that one, cfr. include/linux/kern_levels.h ;-)
> #define PRINTK_PID "\002"
>
On Sat, 28 Dec 2013 19:57:50 +0100 Geert Uytterhoeven
wrote:
> > If we introduce a character which compiler does not know that follows the %
> > character, compiler would be confused when checking type of corresponding
> > argument.
> >
> >> I wonder if there's some way in which we can invent a
On Sat, Dec 28, 2013 at 4:43 AM, Tetsuo Handa
wrote:
> Andrew Morton wrote:
>> which is painful, so we also provide the new vsprintf token as a
>> convenience:
>>
>> pr_warn("%|: hair on fire\n");
>>
>> but I don't know what we can use in place of %|.
>
> We are using %pEXTENSION where
On Sat, Dec 28, 2013 at 4:43 AM, Tetsuo Handa
penguin-ker...@i-love.sakura.ne.jp wrote:
Andrew Morton wrote:
which is painful, so we also provide the new vsprintf token as a
convenience:
pr_warn(%|: hair on fire\n);
but I don't know what we can use in place of %|.
We are using
On Sat, 28 Dec 2013 19:57:50 +0100 Geert Uytterhoeven ge...@linux-m68k.org
wrote:
If we introduce a character which compiler does not know that follows the %
character, compiler would be confused when checking type of corresponding
argument.
I wonder if there's some way in which we can
On Sat, Dec 28, 2013 at 8:25 PM, Andrew Morton
a...@linux-foundation.org wrote:
Is any of the \x (backslash + character) unused and thus available?
I guess control characters would work.
#define PRINTK_COMM \001
Not that one, cfr. include/linux/kern_levels.h ;-)
#define PRINTK_PID
On Sat, 2013-12-28 at 20:25 +0100, Geert Uytterhoeven wrote:
On Sat, Dec 28, 2013 at 8:25 PM, Andrew Morton
a...@linux-foundation.org wrote:
Is any of the \x (backslash + character) unused and thus available?
I guess control characters would work.
#define PRINTK_COMM \001
Not
On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches j...@perches.com wrote:
#define PRINTK_PID \002
#define PRINTK_TASK_ID \003 /* comm:pid */
printk(PRINTK_TASK_ID : hair on fire\n);
It's certainly compact. I doubt if there's any existing code which
deliberately
On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches j...@perches.com wrote:
#define PRINTK_PID \002
#define PRINTK_TASK_ID \003 /* comm:pid */
printk(PRINTK_TASK_ID : hair on fire\n);
It's certainly
Joe Perches wrote:
On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches j...@perches.com wrote:
#define PRINTK_PID \002
#define PRINTK_TASK_ID \003 /* comm:pid */
printk(PRINTK_TASK_ID : hair on fire\n);
On Sun, 2013-12-29 at 09:32 +0900, Tetsuo Handa wrote:
Joe Perches wrote:
On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches j...@perches.com wrote:
#define PRINTK_PID \002
#define PRINTK_TASK_ID \003 /* comm:pid */
Andrew Morton wrote:
> which is painful, so we also provide the new vsprintf token as a
> convenience:
>
> pr_warn("%|: hair on fire\n");
>
> but I don't know what we can use in place of %|.
We are using %pEXTENSION where EXTENSION is [A-Za-z0-9]* because compiler does
not need to
On Wed, 25 Dec 2013 21:37:33 +0900 Tetsuo Handa
wrote:
> Some examples for converting direct ->comm users are shown below.
>
> pr_info("comm=%s\n", p->comm);=> pr_info("comm=%pTC\n", p);
> pr_info("%s[%u]\n", p->comm, p->pid); => pr_info("%pT0\n", p);
>
On Wed, 25 Dec 2013 21:37:33 +0900 Tetsuo Handa
penguin-ker...@i-love.sakura.ne.jp wrote:
Some examples for converting direct -comm users are shown below.
pr_info(comm=%s\n, p-comm);= pr_info(comm=%pTC\n, p);
pr_info(%s[%u]\n, p-comm, p-pid); = pr_info(%pT0\n,
Andrew Morton wrote:
which is painful, so we also provide the new vsprintf token as a
convenience:
pr_warn(%|: hair on fire\n);
but I don't know what we can use in place of %|.
We are using %pEXTENSION where EXTENSION is [A-Za-z0-9]* because compiler does
not need to understand what
On Wed, 2013-12-25 at 21:37 +0900, Tetsuo Handa wrote:
> This patch introduces %pTC format specifier for reading task_struct->comm
> and %pT0 %pT1 %pT2 format specifiers for reading task_struct->comm and
> task_struct->pid.
[]
> pr_info("comm=%s\n", p->comm);=>
On Wed, 2013-12-25 at 21:37 +0900, Tetsuo Handa wrote:
This patch introduces %pTC format specifier for reading task_struct-comm
and %pT0 %pT1 %pT2 format specifiers for reading task_struct-comm and
task_struct-pid.
[]
pr_info(comm=%s\n, p-comm);= pr_info(comm=%pTC\n, p);
>From 545dae06c6690a0c937e082ed984f828a2ea7aa2 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 25 Dec 2013 18:16:17 +0900
Subject: [PATCH] lib/vsprintf: add %pT[C012] format specifier
Since task_struct->comm can be modified by other threads while the current
thread is r
From 545dae06c6690a0c937e082ed984f828a2ea7aa2 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Date: Wed, 25 Dec 2013 18:16:17 +0900
Subject: [PATCH] lib/vsprintf: add %pT[C012] format specifier
Since task_struct-comm can be modified by other threads while
90 matches
Mail list logo
