Messages in this thread | | | Subject | Re: New information on the CIPE problem (compiler conflicts) | Date | Sat, 18 Mar 2000 14:29:06 +0100 | From | Olaf Titz <> |
| |
> I am sorry, gentlemen, but you have to compile all the kernel > with uniform options and with one flavor of compiler, if this choice > really introduces difference in structures: that's right fix.
The problem is that if we let all these subtle differences through means we don't even have a well-defined kernel-module ABI unless everything was compiled at once. Consequently we can forget about externally compiled modules at all.
I've always had the impression that some perhaps important people fail to see the need for modules, much more for external modules. It would be a very unfortunate side-effect of the new crypto regulations if those people now say, "it's okay, you can integrate everything into the kernel and the last reason for us to tolerate modules is gone". That would not be good for development on (sometimes big) projects like ALSA or lm-sensors.
Such projects depend on the ability to compile external modules, and that depends on an ABI that doesn't change while running(*). Because some things have to be reproduced exactly, there must be a means of _knowing_ them exactly. This works for the config options (sort of - MODVERSIONS or similar functionality really ought to be non-optional), but we already have to jump through much too many hoops to reproduce the compiler options command line - the "make dep" procedure of the kernel should write a Makefile fragment in the include tree which can be used by every module, and if that includes checking compiler versions and binutils versions down to the 10h decimal place, let's record this too.
I'd rather prefer we draft a complete definition on what comprises the kernel-module ABI, and what it allowed to change it, with the latter list as short as possible, and a fixed procedure for compiling modules.
Olaf
(*) yes, if it changes just from updating a tool (compiler) while running this is "change while running" in my book.
- 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/
| |