| |||||||||||||
regular ABI vs modversionsregular ABI vs modversionsPosted Feb 7, 2003 1:04 UTC (Fri) by giraffedata (subscriber, #1954)In reply to: The return of modversions by mmarq Parent article: The return of modversions 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. --
(Log in to post comments)
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.
|
|||||||||||||