On Sun, 1 Feb 2004, Bill Davidsen wrote: > > What didn't you like about Jakob's patch which avoids the 64 byte size > penalty? What size penalty? The data has to be allocated somewhere, and on the stack is simply not acceptable. So there can be no size penalty. Yes, the text size of the binary is slightly bigger, because a "static const" ends up in the ro-section, but that's _purely_ an accounting thing. It has to be somewhere, be it .text, .data or .bss. Who would ever care where it is? Having it in .ro means that there are no initialization issues, and a compressed kernel compresses the zero bytes better than having init-time code to initialize the array (or, worse, doing it over and over at run-time). So where does this size penalty idea come from? In short: "static const" is correct. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo _at_ vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Follow-Ups: References:
- Re: [CRYPTO]: Miscompiling sha256.c by gcc 3.2.3 and arch pentium3,4James Morris
- Re: [CRYPTO]: Miscompiling sha256.c by gcc 3.2.3 and archpentium3,4David S. Miller
- Re: [CRYPTO]: Miscompiling sha256.c by gcc 3.2.3 and arch pentium3,4Bill Davidsen
- Prev by Date: Re: More waitpid issues with CLONE_DETACHED/CLONE_THREAD
- Next by Date: Re: ACPI -- Workaround for broken DSDT
- Previous by thread: Re: [CRYPTO]: Miscompiling sha256.c by gcc 3.2.3 and arch pentium3,4
- Next by thread: Re: [CRYPTO]: Miscompiling sha256.c by gcc 3.2.3 and arch pentium3,4
- Indexes:[Main][Thread]