04 Dec, 2008

2 commits

  • This adds an "override" keyword for use in *.symvers / *.symref files.
    When a symbol is overridden, the symbol's old definition will be used for
    computing checksums instead of the new one, preserving the previous
    checksum. (Genksyms will still warn about the change.)

    This is meant to allow distributions to hide minor actual as well as fake
    ABI changes. (For example, when extra type information becomes available
    because additional headers are included, this may change checksums even
    though none of the types used have actully changed.)

    This approach also allows to get rid of "#ifdef __GENKSYMS__" hacks in the
    code, which are currently used in some vendor kernels to work around
    checksum changes.

    Signed-off-by: Andreas Gruenbacher
    Cc: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Sam Ravnborg

    Andreas Gruenbacher
     
  • Sometimes it is preferable to avoid changes of exported symbol checksums
    (to avoid breaking externally provided modules). When a checksum change
    occurs, it can be hard to figure out what caused this change: underlying
    types may have changed, or additional type information may simply have
    become available at the point where a symbol is exported.

    Add a new --reference option to genksyms which allows it to report why
    checksums change, based on the type information dumps it creates with the
    --dump-types flag. Genksyms will read in such a dump from a previous run,
    and report which symbols have changed (and why).

    The behavior can be controlled for an entire build as follows: If
    KBUILD_SYMTYPES is set, genksyms uses --dump-types to produce *.symtypes
    dump files. If any *.symref files exist, those will be used as the
    reference to check against. If KBUILD_PRESERVE is set, checksum changes
    will fail the build.

    Signed-off-by: Andreas Gruenbacher
    Cc: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Sam Ravnborg

    Andreas Gruenbacher
     

25 Jun, 2006

1 commit

  • Here is a patch that adds a new -T option to genksyms for generating dumps of
    the type definition that makes up the symbol version hashes. This allows to
    trace modversion changes back to what caused them. The dump format is the
    name of the type defined, followed by its definition (which is almost C):

    s#list_head struct list_head { s#list_head * next , * prev ; }

    The s#, u#, e#, and t# prefixes stand for struct, union, enum, and typedef.
    The exported symbols do not define types, and thus do not have an x# prefix:

    nfs4_acl_get_whotype int nfs4_acl_get_whotype ( char * , t#u32 )

    The symbol type defintion of a single file can be generated with:

    make fs/jbd/journal.symtypes

    If KBUILD_SYMTYPES is defined, all the *.symtypes of all object files that
    export symbols are generated.

    The single *.symtypes files can be combined into a single file after a kernel
    build with a script like the following:

    for f in $(find -name '*.symtypes' | sort); do
    f=${f#./}
    echo "/* ${f%.symtypes}.o */"
    cat $f
    echo
    done \
    | sed -e '\:UNKNOWN:d' \
    -e 's:[,;] }:}:g' \
    -e 's:\([[({]\) :\1:g' \
    -e 's: \([])},;]\):\1:g' \
    -e 's: $::' \
    $f \
    | awk '
    /^.#/ { if (defined[$1] == $0) {
    print $1
    next
    }
    defined[$1] = $0
    }
    { print }
    '

    When the kernel ABI changes, diffing individual *.symtype files, or the
    combined files, against each other will show which symbol changes caused the
    ABI changes. This can save a tremendous amount of time.

    Dump the types that make up modversions

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Sam Ravnborg

    Andreas Gruenbacher
     

13 Mar, 2006

1 commit

  • o remove all inlines
    o declare everything static which is only used by genksyms.c
    o delete unused functions
    o delete unused variables
    o delete unused stuff in genksyms.h
    o properly ident genksyms.h

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds