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

[Luben Tuikov <ltuikov@yahoo.com>]

--- Andrew Morton <akpm@osdl.org> wrote:
> On Sat, 01 Jul 2006 00:46:15 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
> 
> > Andrew Morton wrote:
> > > Luben Tuikov <ltuikov@yahoo.com> wrote:
> > >>> 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.
> > > 
> > > OK, that's a reason.  Being able to map a kernel thread onto a particular
> > > device is useful.
> > 
> > But will it wind up this way, when the does-not-exist-yet-upstream code 
> > appears?
> > 
> > I would think it would make more sense to increase the size of the key 
> > task structure only when there are justified, merged users in the kernel.
> > 
> 
> Well yes - I assumed that would be happening fairly soon.  Luben?

Andrew,

If this patch is so much affecting Garzik, please drop it.

As to "merged users in the kernel" -- my code is GPL, and at one point
was in the -mm tree as maintained by yourself.

Currently it also implements a SAT-r08a complient SCSI/ATA Translation
Layer for a SAS Stack including SATA capabilities adjustment as advertized
by the protocol, NCQ, passthrough, etc, etc. (Garzik may see this as
objectionable as it is not "libata", but it cannot be due to architectural
hurdles.)

Anyway, kernel threads bear the name of STP/SATA bridge which is representable
in 16+1 ASCII chars (IEEE NAA Registered format identifier, 8 bytes), and thus
the last character (4 bits of the name) are chopped off in a 15+1 char array.

So in effect, a kernel thread can be (WW-) uniquely identified with the device
it services.

In the (near) future, I can see other protocols wanting TASK_COMM_LEN to be larger
to accomodate this (e.g. any protocol which allows for IEEE NAA names).

Thank you for your time,
    Luben

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