[i2c] [PATCH] Lifebook apanel driver
Stephen Hemminger
shemminger at osdl.org
Wed Jan 10 21:44:28 CET 2007
On Wed, 10 Jan 2007 21:26:48 +0100
Jean Delvare <khali at linux-fr.org> wrote:
> Hi Stephen,
>
> On Wed, 10 Jan 2007 11:50:59 -0800, Stephen Hemminger wrote:
> > On Wed, 10 Jan 2007 09:22:09 +0100 Jean Delvare wrote:
> > > Why isn't this structure dynamically allocated as all other i2c chip
> > > drivers do? This is a requiement if you ever need to support more than
> > > one device on a given system, and this is also much nicer IMHO.
> >
> > There can only be one of these devices just like there can only be a single
> > i801 adapter (similar to wistron buttons). Likewise the whole discovery process
> > is tied up with looking at the BIOS to see what is there, and the hardware
> > chips involved.
>
> This is true at the moment, but might as well change in the future.
>
> > Because of all this, it makes more sense to skip the allocation and have smaller code.
>
> Actually, not really, which is why I was asking. OK, you have smaller
> code, i.e. a smaller .text section, however, the static struct
> apanel ends up in the .data section, and it's not exactly small:
> approximatively 500 bytes on x86. The dynamic allocation and free code
> takes like 50 bytes, so that's still a net benefit of ~450 bytes, or
> 10% of the driver binary size.
>
> Your driver:
> text data bss dec hex filename
> 2823 1472 56 4351 10ff drivers/input/misc/apanel.o
> With my (untested) patch below:
> text data bss dec hex filename
> 2879 968 56 3903 f3f drivers/input/misc/apanel.o
>
> But well that's your driver, your decision.
>
> * * * * *
>
> Allocate the device structure dynamically, this cuts 10% of the driver
> binary size.
>
The memory ends up coming out of heap, and it ends up getting rounded up.
--
Stephen Hemminger <shemminger at osdl.org>
More information about the i2c
mailing list