lkml.org 
[lkml]   [2003]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: no version magic, tainting kernel.
    On Sun, Jan 26, 2003 at 03:46:30PM -0600, Kai Germaschewski wrote:
    >
    > That's not true. For example, how would an old external build system
    > magically starting to compile modules as .ko without updating? How
    > would it have added -DKBUILD_BASENAME and -DKBUILD_MODNAME, which
    > are required by the new module code. And, how did they avoid subtle
    > breakage like not giving the same switches on the command line?
    > (This list goes on...)
    >

    I hear you, but these changes were easy enough to adapt to.

    > Also, it's not true that they've been broken deliberately. As work
    > progresses, breakage occurs, that's just a fact of live. However,
    > introduction of __vermagic was not introduced in order to make live
    > for maintainers of external modules harder, it was introduced since
    > loading modules compiled with gcc3 into a kernel compiled with gcc2
    > caused crashes for people.
    >

    Well, in this specific case an alternate solution was proposed that
    would have solved any of the potential problems pointed out.

    > Okay, you have a point here, there's still a bug. vermagic.o will be
    > rebuilt when the version changes or any of the recorded config
    > options change, but it doesn't pick up changes in the compiler
    > version, if the new gcc has the same name.
    >
    > That's a bug for internal use as well, the patch below fixes it.
    >

    Fair enough.

    > o One thing I do not understand at all: What is the problem with
    > using the internal build system? It makes maintainance of external
    > modules much easier than keeping track of what happens in the kernel
    > and patching a private solution all the time.
    >

    My primary concern is compatibility with those kernels that do not use
    kbuild or a different version of it. Ideally, one would want to use
    the same build system for all possible kernel versions rather than use
    Makefiles that attempt to pick the best choice. I guess I'm convinced
    that the latter is the "best" solution to dealing with this problem at
    this point, and I can live with that.

    What's the most reliable way to tell if kbuild is available, and what
    differences among kbuild versions will one have to look out for?

    > I don't even see any license issues, first of all you don't even
    > distribute it, the user who's building the module will already
    > have it along with his kernel source. And if you're using it to
    > compile (possibly binary) modules you want to distribute, you can
    > just use it just like gcc without any further obligations, so no
    > problem there either. (IANAL, of course)
    >

    I don't see any problems with kbuild, I was referring to vermagic.c.

    --
    christian zander
    zander@minion.de
    -
    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/

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