[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