Re: [PATCH] sched.h: increment TASK_COMM_LEN to 20 bytes

[Luben Tuikov]

--- Andrew Morton <akpm@xxxxxxxx> wrote:
> Luben Tuikov <ltuikov@xxxxxxxxx> wrote:
> >
> > It is 4 byte aligned anyway.
> 
> That's a 64-bitism.  And 32-bit machines are more space-sensitive.

I see.
 
> >  This way we can use
> > up to 19+1 chars.
> > 
> > Signed-off-by: Luben Tuikov <ltuikov@xxxxxxxxx>
> > ---
> >  include/linux/sched.h |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index 18f12cb..3fc11bc 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -154,7 +154,7 @@ #define set_current_state(state_value)		
> >  	set_mb(current->state, (state_value))
> >  
> >  /* Task command name length */
> > -#define TASK_COMM_LEN 16
> > +#define TASK_COMM_LEN 20
> 
> So this is basically "increase size of comm[] by 4 bytes, happens to be
> zero-cost on 64-bit machines".

Yes.

> We do occasionally hit task_struct.comm[] truncation, when people use
> "too-long-a-name%d" for their kernel thread names.  But we seem to manage.

It would be especially helpful if you want to name a task thread
the NAA IEEE Registered name format (16 chars, globally unique), for things
like FC, SAS, etc.  This way you can identify the task thread with
the device bearing the NAA IEEE name.

Currently just last character is cut off, since TASK_COMM_LEN is 15+1.

I think incrementing it would be a good thing, plus other things
may want to represent 8 bytes as a character array to be the name
of a task thread.

    Luben
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/