lkml.org 
[lkml]   [1998]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patches in this message
    /
    Date
    From
    SubjectFlavours - was: Re: [IDEA] Developers: your opinion badly needed ! (Was: [PATCH] /proc/config.gz)
    Hi

    The following is the file /usr/doc/kernel-package/Flavours from the Debian
    kernel-package. I think it addresses all the issues raised in this thread.
    --

    Robbie Murray

    Multiple flavours of the same kernel version
    ======== ======== == === ==== ====== =======

    There is an expressed need from people to have several
    alternative flavors of a single kernel version around. It is
    certainly useful to have a backup flavour of a kernel version around
    when one is experimenting with device driver variations (it may not
    be possible to run a different version of a kernel and hence have
    that as a backup).

    Unfortunately, this is more complicated than it initially
    appears, since the presence of possibly incompatible modules has to
    be addressed.

    Firstly, the modules from different flavours have to be
    installed in separate directories, the modutils have to be made aware
    of this alternative dorectory, and also, the kernel (and klogd)
    should be able to load the right set of symbols from a System.map
    file (which are different enough in different flavours that klogd
    refuses to load the wrong one).

    The proper way to address this may well be to modify the
    kernel version in some fashion (Note: this would involve modifying
    the kernel source's top level Makefile). Unfortunately, SUBLEVEL
    needs to stay numeric (and under 255, as far as I can tell), so it is
    a wee bit more complex than just modifying the SUBLEVEL variable.

    The solution seems to be to add a FLAVOUR field to the end of
    UTS_RELEASE, which uname then reads properly. As of 2.1.47, this
    variable is used purely for output purposes (nothing seems to parse
    it).

    This way, the user has to modify the kernel Makefile (an sample
    patch is provided below) to read, say, "FLAVOUR := speed_hack", and
    the kernel would be installed as /boot/vmlinuz-2.0.30-speed_hack, the
    modules would be installed under /lib/modules/2.0.30-speed_hack,
    uname -r would report the version as 2.0.30-speed_hack.

    There is a patch appended to the bottom of this message that
    would allow klogd to discover the new System.map file, and to not
    choke on the non-numeric kernel version.

    The patch provided below is from the Makefile for 2.1.47
    kernel, and may not apply cleanly on other Makefiles. It is
    recommended that you use it purely as a guideline, and modify the
    Makefile manually.

    This effort has been based on the ideas and work of Bill
    Mitchell <mitchell@mozcom.com> and Noel Maddy <ncm@biostat.hfh.edu>.

    ======================================================================
    --- Makefile.dist Mon Aug 4 12:18:57 1997
    +++ Makefile Mon Aug 4 12:24:55 1997
    @@ -2,6 +2,22 @@
    PATCHLEVEL = 1
    SUBLEVEL = 47

    +# This is an example only: Uncomment the FLAVOUR line below and name
    +# this flavour.
    +#
    +# If you want to have more than one kernel configuration per kernel
    +# version, set FLAVOUR -- it will be appended to UTS_RELEASE in
    +# version.h (separated by a hyphen)
    +#
    +#FLAVOUR = speed_hack
    +
    +ifneq ($(strip $(FLAVOUR)),)
    +INT_FLAV := -$(FLAVOUR)
    +else
    +INT_FLAV :=
    +endif
    +
    +
    ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/)

    #
    @@ -244,7 +260,7 @@
    @mv -f .ver $@

    include/linux/version.h: ./Makefile
    - @echo \#define UTS_RELEASE \"$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)\" > .ver
    + @echo \#define UTS_RELEASE \"$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(INT_FLAV)\" > .ver
    @echo \#define LINUX_VERSION_CODE `expr $(VERSION) \\* 65536 + $(PATCHLEVEL) \\* 256 + $(SUBLEVEL)` >> .ver
    @mv -f .ver $@

    @@ -289,7 +305,7 @@

    modules_install:
    @( \
    - MODLIB=/lib/modules/$(VERSION).$(PATCHLEVEL).$(SUBLEVEL); \
    + MODLIB=/lib/modules/$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(INT_FLAV); \
    cd modules; \
    MODULES=""; \
    inst_mod() { These="`cat $$1`"; MODULES="$$MODULES $$These"; \
    ______________________________________________________________________

    ______________________________________________________________________
    From: Yann Dirson <ydirson@a2points.com>

    Ah, there still were some minor corrections to do. Here's my final
    version (compiled fine with glibc 2.0.6, but had to replace
    <sys/module.h> with <linux/module.h> in ksym_mod.c).

    kern.log now says:

    ====
    Mar 24 11:18:52 bylbo kernel: klogd 1.3-3, log source = /proc/kmsg started.
    Mar 24 11:18:53 bylbo kernel: Loaded 2589 symbols from /boot/System.map-2.0.33-std.
    Mar 24 11:18:53 bylbo kernel: Symbols match kernel version 2.0.33-std.
    ====
    ====
    --- ksym.c.orig Mon Mar 23 23:23:03 1998
    +++ ksym.c Tue Mar 24 11:18:09 1998
    @@ -105,7 +105,7 @@

    static int num_syms = 0;
    static int i_am_paranoid = 0;
    -static char vstring[12];
    +static char vstring[65]; /* see /usr/include/linux/utsname.h */
    static struct sym_table *sym_array = (struct sym_table *) 0;

    static char *system_maps[] =
    @@ -438,7 +438,7 @@


    {
    - auto int vnum,
    + auto int vnum, kvnum,
    major,
    minor,
    patch;
    @@ -458,42 +458,41 @@


    /*
    - * Since the symbol looks like a kernel version we can start
    - * things out by decoding the version string into its component
    - * parts.
    + * Get the numeric code from the system map.
    */
    vnum = atoi(version + strlen(prefix));
    - major = vnum / 65536;
    - vnum -= (major * 65536);
    - minor = vnum / 256;
    - patch = vnum - (minor * 256);
    - if ( debugging )
    - fprintf(stderr, "Version string = %s, Major = %d, " \
    - "Minor = %d, Patch = %d.\n", version +
    - strlen(prefix), major, minor, \
    - patch);
    - sprintf(vstring, "%d.%d.%d", major, minor, patch);

    /*
    - * We should now have the version string in the vstring variable in
    - * the same format that it is stored in by the kernel. We now
    - * ask the kernel for its version information and compare the two
    - * values to determine if our system map matches the kernel
    - * version level.
    + * We now ask the kernel for its version information and
    + * compare the two values to determine if our system map
    + * matches the kernel version level.
    */
    if ( uname(&utsname) < 0 )
    {
    Syslog(LOG_ERR, "Cannot get kernel version information.");
    return(0);
    }
    +
    + if ( sscanf (utsname.release, "%d.%d.%d", &major, &minor, &patch) < 3 )
    + {
    + Syslog(LOG_ERR, "Kernel send bogus release string `%s'.",
    + utsname.release);
    + return(0);
    + }
    +
    + /* Compute the version code from data sent by the kernel */
    + kvnum = (major << 16) | (minor << 8) | patch;
    +
    if ( debugging )
    - fprintf(stderr, "Comparing kernel %s with symbol table %s.\n",\
    - utsname.release, vstring);
    + fprintf(stderr, "Comparing kernel %s with symbol table 0x%6x.\n",\
    + utsname.release, vnum);

    /* Failure. */
    - if ( strcmp(vstring, utsname.release) != 0 )
    + if ( vnum != kvnum )
    return(-1);

    + strcpy (vstring, utsname.release);
    +
    /* Success. */
    return(1);
    }
    ====
    ______________________________________________________________________


    Old solution; that does not work cleanly:

    One can edit /etc/init.d/syslogd (or however you start klogd)
    like so (this is from the Debian init.d directory)
    ----------------------------------------------------------------------
    # Use KLOGD="-k /boot/System.map-$(uname -r)" to specify System.map
    #
    KLOGD="-k /boot/System.map-$(uname -r)"
    ....
    .... /sbin/klogd $KLOGD
    ----------------------------------------------------------------------
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

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