LWN: Comments on "The return of modversions"

regular ABI vs modversions

mmarq — Sun, 09 Feb 2003 03:00:07 +0000

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.

regular ABI vs modversions

mmarq — Sat, 08 Feb 2003 01:08:49 +0000

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

giraffedata — Fri, 07 Feb 2003 01:04:02 +0000

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.

--
Bryan Henderson
IBM Almaden Research Center
San Jose CA
bryanh@almaden.ibm.com

The return of modversions

mmarq — Thu, 06 Feb 2003 21:51:35 +0000

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????????

If anyone can answer to this all, i'll be much aprecited.

The problem is, i think:!!
Why use an intermediary structure scheme, to bypass the GPL limitations, to call (example) printk() when you can call it directly???!!!.
Better!!... if you allow, any way, to use a specific interface to use kernel symbols why not group these in well documentaded API/ABI, that can be used for binary and or source modules???

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!!!!

The return of modversions

mwilck — Wed, 05 Feb 2003 15:52:29 +0000

> 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

Ross — Sun, 02 Feb 2003 05:05:54 +0000

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

wolfrider — Sun, 02 Feb 2003 03:50:54 +0000

>> 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
2. Modules with mismatched symbols act unpedictably(?)
3. This fix sounds like modules will have (at least a temporary) higher memory-usage requirement than 2.4.

--Please feel free to correct / educate me here...

The return of modversions

TheOneKEA — Fri, 31 Jan 2003 00:55:08 +0000

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

Ross — Thu, 30 Jan 2003 18:45:58 +0000

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.