lkml.org 
[lkml]   [1998]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    Subject2.1.131: some quality thoughts
    (I'm not subscribed here)

    Hello,

    after upgrading my home system significantly, I was able to work on
    the 2.1.131 tree. Using CVS I have a few problems:

    /usr/src/linux/net/core is ignored by CVS standards. Shipping a
    ".cvsignore" in the kernel tree is not an optimal sulution, because
    the logic is inverted, and there's no ".cvsinclude" per concept.

    I know that it's ugly, but could "core" be renamed before 2.2 comes
    out? Possible candidated might be "netcore", "kern[el]", "nucleus",
    "base". A symbolic link could be added to tar archives to support the
    old name if necessary.

    I also noticed that CVS does not like it if you build in a
    checked-out tree: After that I couldn't "cvs diff" nor "cvs commit",
    because some files were missing beyond include/config in the CVS
    subdirectories. Maybe the Makefiles or Rules can be fixed to avoid
    that problem.

    Anotherthing with versioned symbols: Currently the SMP definition is
    passed as prefix to the genksyms program to prevent crashed due to
    incompatible binaries. IMHO other prefixes for the CPU type or memory
    alignment options (compilation flags) should be passed as well (I once
    had a crash loading i386 compiled modules into a Pentium compiled
    kernel; happens if you use distributions and recompile your kernel)

    Unfortunately genksyms just adds prefixes to the name. I haven't
    checked the sources, but it would be more reasonable if all the
    prefixes would be appended to the "mangled name", and then just go
    into the CRC computation. Thus you could add as many prefixes as you
    like without blowing up the symbol table size. If you think the digits
    are not significant, we could change to "base 2*26+10" (A-Za-z0-9)
    instead of simple digits to represent the CRC.

    I also think the makefile should at least output whether SMP is on or
    not when doing "make config". Also the Makefile could be smart enough
    to do "make mrproper" if necessary to compile after SMP is changed (my
    compilation failed even after a "make clean" when I switched to
    non-SMP. Someone said that "make mrproper" would do the trick).

    A few dependencies are not yet correct in the Makefile: E.g. when
    building versioned modules, compilation of serial.c failed (I hacked
    it!). After changing only serial.c and restarting make, loop.o was
    also recompiled, even that had been finished before...

    So long,
    Ulrich


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

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