Re: drivers/usb/misc/emi*.c have the biggest data objects in the whole tree - Kernel

This is a discussion on Re: drivers/usb/misc/emi*.c have the biggest data objects in the whole tree - Kernel ; On Fri, Sep 14, 2007 at 11:35:34AM +0100, Denys Vlasenko wrote: > Hi Tapio, > > You are the author of these files. Are you still maintaining them? > If not, do you know who is the current maintainer? > ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: drivers/usb/misc/emi*.c have the biggest data objects in the whole tree

  1. Re: drivers/usb/misc/emi*.c have the biggest data objects in the whole tree

    On Fri, Sep 14, 2007 at 11:35:34AM +0100, Denys Vlasenko wrote:
    > Hi Tapio,
    >
    > You are the author of these files. Are you still maintaining them?
    > If not, do you know who is the current maintainer?
    >
    > These two object files hold the biggest data objects in the whole Linux kernel
    > after lockdep:
    >
    > text data bss dec hex filename
    > 1258 160516 0 161774 277ee ./drivers/usb/misc/emi26.o
    > 1504 209296 0 210800 33770 ./drivers/usb/misc/emi62.o
    >
    > Basically, these are big arrays of the following structures:
    >
    > typedef struct _INTEL_HEX_RECORD
    > {
    > __u32 length;
    > __u32 address;
    > __u32 type;
    > __u8 data[MAX_INTEL_HEX_RECORD_LENGTH];
    > } INTEL_HEX_RECORD;
    >
    > I suggest the following optimizations:
    >
    > Change structure to
    >
    > typedef struct _INTEL_HEX_RECORD
    > {
    > __u8 type;
    > __u8 length;
    > __u16 address;
    > __u8 data[MAX_INTEL_HEX_RECORD_LENGTH];
    > } INTEL_HEX_RECORD __attribute__((__packed__));


    Only if you redo the whole firmware image too

    What is this really hurting? It's only relevant if you load the
    specific module, if you have this device type. It's a firmware blob,
    nothing really interesting at all.

    thanks,

    greg k-h
    -
    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/

  2. Re: drivers/usb/misc/emi*.c have the biggest data objects in the whole tree

    On Friday 28 September 2007 05:41, Greg KH wrote:
    > On Fri, Sep 14, 2007 at 11:35:34AM +0100, Denys Vlasenko wrote:
    > > Hi Tapio,
    > >
    > > You are the author of these files. Are you still maintaining them?
    > > If not, do you know who is the current maintainer?
    > >
    > > These two object files hold the biggest data objects in the whole Linux kernel
    > > after lockdep:
    > >
    > > text data bss dec hex filename
    > > 1258 160516 0 161774 277ee ./drivers/usb/misc/emi26.o
    > > 1504 209296 0 210800 33770 ./drivers/usb/misc/emi62.o
    > >
    > > Basically, these are big arrays of the following structures:
    > >
    > > typedef struct _INTEL_HEX_RECORD
    > > {
    > > __u32 length;
    > > __u32 address;
    > > __u32 type;
    > > __u8 data[MAX_INTEL_HEX_RECORD_LENGTH];
    > > } INTEL_HEX_RECORD;
    > >
    > > I suggest the following optimizations:
    > >
    > > Change structure to
    > >
    > > typedef struct _INTEL_HEX_RECORD
    > > {
    > > __u8 type;
    > > __u8 length;
    > > __u16 address;
    > > __u8 data[MAX_INTEL_HEX_RECORD_LENGTH];
    > > } INTEL_HEX_RECORD __attribute__((__packed__));

    >
    > Only if you redo the whole firmware image too


    I did. It wasn't hard.

    > What is this really hurting? It's only relevant if you load the
    > specific module


    By this logic, no space wastage in modules is worth fixing.
    --
    vda
    -
    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/

  3. Re: drivers/usb/misc/emi*.c have the biggest data objects in the whole tree

    On Fri, Sep 28, 2007 at 12:34:29PM +0100, Denys Vlasenko wrote:
    > On Friday 28 September 2007 05:41, Greg KH wrote:
    > > On Fri, Sep 14, 2007 at 11:35:34AM +0100, Denys Vlasenko wrote:
    > > > Hi Tapio,
    > > >
    > > > You are the author of these files. Are you still maintaining them?
    > > > If not, do you know who is the current maintainer?
    > > >
    > > > These two object files hold the biggest data objects in the whole Linux kernel
    > > > after lockdep:
    > > >
    > > > text data bss dec hex filename
    > > > 1258 160516 0 161774 277ee ./drivers/usb/misc/emi26.o
    > > > 1504 209296 0 210800 33770 ./drivers/usb/misc/emi62.o
    > > >
    > > > Basically, these are big arrays of the following structures:
    > > >
    > > > typedef struct _INTEL_HEX_RECORD
    > > > {
    > > > __u32 length;
    > > > __u32 address;
    > > > __u32 type;
    > > > __u8 data[MAX_INTEL_HEX_RECORD_LENGTH];
    > > > } INTEL_HEX_RECORD;
    > > >
    > > > I suggest the following optimizations:
    > > >
    > > > Change structure to
    > > >
    > > > typedef struct _INTEL_HEX_RECORD
    > > > {
    > > > __u8 type;
    > > > __u8 length;
    > > > __u16 address;
    > > > __u8 data[MAX_INTEL_HEX_RECORD_LENGTH];
    > > > } INTEL_HEX_RECORD __attribute__((__packed__));

    > >
    > > Only if you redo the whole firmware image too

    >
    > I did. It wasn't hard.


    Great, send me a patch then

    > > What is this really hurting? It's only relevant if you load the
    > > specific module

    >
    > By this logic, no space wastage in modules is worth fixing.


    No, that's not true. Be realistic here please.

    thanks,

    greg k-h
    -
    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/

+ Reply to Thread