Messages in this thread | | | Date | Sat, 8 Jul 2006 17:48:12 -0700 (PDT) | From | Luben Tuikov <> | Subject | Re: [PATCH] sched.h: increment TASK_COMM_LEN to 20 bytes |
| |
--- Jeff Garzik <jeff@garzik.org> wrote: > Your patch increases the size of a key data structure -- task struct -- > for all users on all platforms, even when there are _no_ users currently > in the kernel. > > It is thus wasted space, for all users on all platforms. > > Linux development doesn't work like this. We don't know the future, > until it happens.
:-) I love your logic... Can I quote you on this?
Your thinking: "We don't know the future, until it happens", leaves you unprepared for that future when it actually happens.
> Thus, this patch is appropriate when there are real users in the kernel, > and not before.
Impeccable logic, wouldn't you say?
How would you know that there will _not_ be any users unless you give them the opportunity to use it?
Your logic is not only the chicken-and-the-egg problem but is also the classical example in political history: Since there are no current users of "facility X", don't give it to the people.
How would you know? How? When it is not available in the first place?
I know subsystems' developers go through _great_ strives to keep the kernel thread names to fit 15+1 chars.* This is why you don't see any "users".
If TASK_COMM_LEN _were_ 19+1 chars, I bet you users of that facility will spring up.
Luben
* At least that was the case for me 6 years ago when developing iSCSI code... Those iSCSI threads can certainly make use of something larger than 15+1 chars. And it's not only iSCSI. You have to keep an _open mind_ to the future.
- 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/
| |