Weekly Edition
Return to the Kernel page
| |||||||||||||
|
| |||||||||||||
The return of modversions
Perhaps the biggest bit of unfinished work with the new kernel module
loader is the module versioning support. Module versioning is an attempt
to make binary loadable modules work with multiple kernel versions. It
works by attaching a checksum to each exported kernel symbol; the checksum
is calculated from the prototype or declaration of the symbol. As long as
the checksums in a module match those in the running kernel, it is assumed
that the module can be safely loaded. Kernel hackers tend not to use
module versioning, which explains why it took so long to get this feature
fixed. Production kernels shipped by distributors need this feature,
however; otherwise it is essentially impossible for vendors to support
binary-only modules.
Kai Germaschewski has posted a modversions implementation which works with recent 2.5 kernels. The underlying idea is essentially the same as that found in previous implementations, but the implementation is entirely different. The old scheme used the genksyms program to generate the checksums, and to create a bunch of include files (ending in .ver) which redefined the exported kernel names to include those checksums. The effect was to create a bunch of preprocessor definitions like:
#define printk printk_R1b7d4074 (The actual definitions were a little more complicated). Loadable modules would thus be built to call printk_R1b7d4074() instead of printk(). The names were stored in that form in the kernel symbol table, so the insmod program simply needed to look for a direct match. If the interface had changed, the names would not match, and the module would refuse to load. The new implementation does away with the include files. It does still use genksyms, but the output is reprocessed into a set of structure declarations. One structure (containing the symbol name and its checksum) is created for each symbol used by the module; the array of structures is then linked into the module in a special section. When a module is loaded into the kernel, the checksums are used to verify compatibility, and the special section can be discarded. Among other things, this approach makes it easier to force the loading of a module with mismatched symbols, should anybody be unwise enough to attempt such a thing. (Log in to post comments)
The return of modversions Posted Jan 30, 2003 18:45 UTC (Thu) by Ross (subscriber, #4065) [Link] Does this means that versioned modules and non-versioned modules will be identical except for the table of symbol versions?If so, this is going to be really nice. People won't be forced to use a kernel compiled with modversions just because they are using a binary-only module with symbol versions. Nor will distribution kernels be unable to load unversioned modules.
The return of modversions Posted Jan 31, 2003 0:55 UTC (Fri) by TheOneKEA (subscriber, #615) [Link] I hope is the way it's implemented. That way you can add a kernel config option (CONFIG_MODVERSIONS_ALLOW_IGNORE) that will let you run insmod with, say, the --strip-modversions option, so that versioned modules could be used with unversioned kernels.LYS, it would make one of nVidia's headaches go away, and it would make distro building much easier.
The return of modversions Posted Feb 2, 2003 3:50 UTC (Sun) by wolfrider (guest, #3105) [Link] >> Among other things, this approach makes it easier to force the loading of a module with mismatched symbols, should anybody be unwise enough to attempt such a thing.--Is it just me, or does this strike anyone else as a potential problem? 1. Root is the only one that can/should load modules --Please feel free to correct / educate me here...
The return of modversions Posted Feb 2, 2003 5:05 UTC (Sun) by Ross (subscriber, #4065) [Link] Sometimes you know that a version mismatch doesn't matter. Yes, it is rare... it is much more likely that a version mismatch would cause unpredictable problems. But since root is the only one that can do this I don't see any problem. It is nice to get a warning if you do it by accident, but I hate arbitrary restrictions on root.
The return of modversions Posted Feb 5, 2003 15:52 UTC (Wed) by mwilck (guest, #1966) [Link] > Production kernels shipped by distributors need this feature, however;> otherwise it is essentially impossible for vendors to supportbinary-only > modules. A RedHat-centric point of view. SuSE/UnitedLinux does not use modversions (I don't think they SuSE ever has). Binary modules usually come with a wrapper that is available as source code and completely encapsulates the binary part. That is, from the modversioning point of view, there is no difference between a native kernel module and a "binary" module. What makes binary modules incompatible between RedHat kernels is the kernel release compiled into the version string. Yes, it can be circumvented with insmod -f, but who would use that in a production system? Btw the release in the version string is a good thing; it is nice to know your kernel exactly just by an "uname -r". Always talking of production systems here.
The return of modversions Posted Feb 6, 2003 21:51 UTC (Thu) by mmarq (guest, #2332) [Link] Is it possible or not to use an API/ABI(in kernel space) kind of interface for the kernel drivers "problem"?????? Is it incompatible with the structure of the kernel, or the modular ELF data format???????? IMHO a kernel LSB kind of interface, is the thing that makes most sense and is most missed in the kernel... If i sayed something stupic, then is stupid or not that, when something more deep changes in the kernel you have to fix all the drivers, mostly for hardware that have not changed!!!!...and if you consider a development serie takes 2 years, than it probably means that in 50% of the cases you are fixing drivers for hardware that is no longer produced for at least 1 year!!!???? This is the worst case of ineficiency that i have ever saw in IT industry!!!!
regular ABI vs modversions Posted Feb 7, 2003 1:04 UTC (Fri) by giraffedata (subscriber, #1954) [Link] I think you're proposing that instead of having complicated, imperfect mechanisms to be sure your base kernel has the same printk() that your loadable module expects, just have one standard, documented printk().It goes to the heart of Linux philosophy that there are many variations of Linux available and even within one development stream, developers do not constrain themselves with backward compatibility. Linux is not like commercial software products. I have a great anecdote about the difference. I developed a filesystem driver as a loadable kernel module for Linux and an equivalent one for AIX. With Linux, I had to do some nontrivial recoding several times to make it work with the latest 2.4 kernel or with someone else's variation on 2.4. With AIX, I loaded the module that was written for, compiled for, and tested on an AIX 4.3.3 32 bit UP system into an AIX 5.1 64 bit MP system. It worked fine. AIX 5.1 has a lot of improvements over 4.3.3 in the filesystem driver interface, but none of them broke binary compatibility. This and related issues mean there will probably be a lot more people using the AIX implementation of this technology than the Linux one. --
regular ABI vs modversions Posted Feb 8, 2003 1:08 UTC (Sat) by mmarq (guest, #2332) [Link] Without wanting to quote any part we can assume that you thing that some kind of well documented "compatibility" interface is not only possible but also very desirable!...Also, i belive that you can agree with me that, this some how burocratic big work mean that you have to restrict a bit how the kernel is developed!... "that is why Linux is not like a commercial software product"... you can go absolutely wild with the changes implemented!!!... BUT IN THE END THERE IS POSSIBLY NO ALTERNATIVE TO THIS TRADEOFF OF SOME DEVELOPING RESTRICTIONS FOR STANDARDS Even that stubborn maniac "big" person, RMS(someone who we have many things to thank for:- [now i'm gonna be flamed to smoke])have learned by now that there is no effective way to control the "hardware industry"...is like playing chicken with high speed vehicles, and the hardware industry due to various reasons including its nature, has no way for turning!... The danger for Linux due to his wilderness, is of running almost everywhere now, to running almost nowhere in some distant forseenable future... it adapts and overcome or it dies... it is clear that the MS Palladium project is "whoped" to function like one big of many among others of hardware platform lock up attempts. Cutting on the politics, and to tell you the true, my original idea was that "most if not all" of hardware drivers in linux kernel could adopt some form of I2O model, that is already in kernel(no need for brand new design at all), but without the need for special hardware,...and most likely also without the need for loadable kernel modules for the actual "low level in kernel space" hardware driver. The I2O model that is somehow well documented, is "independent" of hardware platform and OS implementation, and is the most advanced driver model that i ever saw in a technical paper, and in such a way, that the same driver could be used in LINUX, AIX, AS390, SOLARIS, HP-UX, (you name it), only need a recompile!!! NO WONDER that microsoft and Intel wore among the original prime backers, that suddenely drop it in the deep ocean!...the much cheaper WINTEL model was about to conquer the world!!! IMHO that with a I2O model, a corporation like IBM can have a high degree of sucess in the integration parts (Mobos, Graphics and Network adapters,.. etc), even wihtout a x86 compatible platform (use Linux anyway)...and wihtout the need to sell it's Hard Disk division,...as it seems!!!
regular ABI vs modversions Posted Feb 9, 2003 3:00 UTC (Sun) by mmarq (guest, #2332) [Link] Well, about the I2O idea i dont have real code, only some simple "sketches"!!...very soon the "thing" revealed itself as being way,...way over my head, even considering going heavy on cut and paste, and even considering that the idea was to use the already in kernel I2O implementation, and build a simple virtual machine "under the kernel" to simulate a central IOP, (I/O Processor) as specified in V2_spec in www.inteligent_IO.com!!!...But i,m pretty sure that the IBM Almaden Research Center has the talent, and perhaps the will to invest in such a feat. ...althoug, and since the 2.5 model has evolved for grouping devices into classes, why not???...document into standars the "alwoed" calls involved, per classes, and in such a way that the printk()(example)will always be what a loadable module could expect, and avoid since the use of schemes like modversions.
|
|
||||||||||||