[lkml]   [2003]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectAnnounce: modutils 2.4.25 is available
    Hash: SHA1

    Content-Type: text/plain; charset=us-ascii


    modutils-2.4.25.tar.gz Source tarball, includes RPM spec file
    modutils-2.4.25-1.src.rpm As above, in SRPM format
    modutils-2.4.25-1.i386.rpm Compiled with gcc 2.96 20000731,
    glibc 2.2.2.
    modutils-2.4.25-1.ia64.rpm Compiled with gcc 2.96-ia64-20000731,
    patch-modutils-2.4.25.gz Patch from modutils 2.4.24 to 2.4.25.

    Changelog extract

    * Add hppa and hppa64 to the list of architectures that have function
    * Add combined s390/s390x support. IBM.

    This version of modutils is almost identical to 2.4.23. The changes
    affect architectures that have function descriptors, i.e. ia64, ppc64,
    hppa, hppa64. It also adds support for combined s390/s390x utilities.

    For historical reasons, insmod and depmod treat modules with neither
    EXPORT_SYMBOL() nor EXPORT_NO_SYMBOLS() as exporting everything. This
    provides backwards compatibility with 2.0 kernels and some 2.2 modules.
    No new code should be relying on this behaviour and the feature has
    been removed in 2.5 kernels. Unfortunately some developers are still
    relying on this default behaviour, even for new code.

    When an architecture has function descriptors and uses EXPORT_SYMBOL()
    on a function, gcc generates a function descriptor and ksymtab contains
    the address of that descriptor. Without an explicit EXPORT_SYMBOL(),
    gcc does not generate a function descriptor and the exported symbol
    points to the start of the function body. Any attempt to call to that
    function tries to use the start of the function code as a descriptor
    and breaks spectacularly.

    To prevent this kernel breakage, I am making an incompatible change to
    modutils. It only affects ia64, ppc64, hppa and hppa64 users, and only
    if they are relying on the deprecated feature of all symbols being

    Users on these architectures must ensure that their modules still
    resolve and add EXPORT_SYMBOL() where necessary before doing a
    permanent upgrade to modutils 2.4.25. The simplest way to check is to
    build (but not install) modutils-2.4.25 then
    ./depmod/depmod -nae > /dev/null
    Any unresolved references that did not occur with modutils 2.4.23 need
    an explicit EXPORT_SYMBOL(). If this is too much bother, stay on
    modutils 2.4.23 and risk the kernel breakage.

    Other architectures can safely upgrade to 2.4.25 with no change, or
    they can stay on 2.4.23.

    If anybody fancies a janatorial task, configure modutils 2.4.25 with
    CFLAGS="-O2 -Wall -DHAS_FUNCTION_DESCRIPTORS" ./configure, build it
    then run ./depmod/depmod -nae > /dev/null. You can do that on any
    architecture to find kernel modules that still rely on exporting all

    No, I am not going to fudge modutils 2.4 to allow the continued default
    export of data symbols but not text symbols on architectures with
    function descriptors. It is too much extra work just to allow the
    continued use of a deprecated feature that has already been removed in
    2.5 kernels.

    Version: GnuPG v1.0.6 (GNU/Linux)
    Comment: Exmh version 2.1.1 10/15/1999

    -----END PGP SIGNATURE-----

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:34    [W:0.025 / U:2.364 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site