Messages in this thread | | | Date | Mon, 27 Jan 2003 00:12:32 +0100 | From | Christian Zander <> | Subject | Re: 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/
| |