On Wed, Dec 26, 2007 at 04:01:22PM -0500, Bit wrote: > Luciano Rocha wrote: > > On Wed, Dec 26, 2007 at 12:48:52PM -0500, Bit wrote: > > > >> Thanks to both of you for the reply. Good information, but that still > >> doesn't really answer my question. I'm more interested in the technical > >> side of things. What I really want to understand boils down to this: > >> > >> Why is it that in Windows I can install ATI drivers once and never worry > >> about it again, while in Linux I may have to *reinstall* the drivers at a > >> later date after a system update to get my card working with them again? > >> Experience has proven to me that in Windows I can install the ATI drivers > >> once, leave those same drivers on there for eternity, update the system > >> over and over with Automatic Updates, and never worry about it breaking > >> my video card. In Linux, every time I see a kernel update, I've learned > >> to be braced for impact and just be ready with my ATI drivers to > >> reinstall to get my card working again. I've never understood this. I'd > >> like a technical explanation for why this is so. > >> > >> > > > > Linux doesn't have a stable ABI (for drivers, userland is a different > > thing), but Windows does. > > > > That means that drivers compiled for your kernel today may not install > > on newer (or older) kernels. You'll have to recompile it. Also, changes > > like support for more than 4GB, how the lower 4GB is split, architecture > > options, gcc version, function calling convections, etc., creates > > dependencies that have to be met by the binary driver. > > > > Windows guarantees that the exposed interface doesn't change, so there's > > no need to recompile things if something internal changes. > > > > But Linux doesn't even have a stable API, so the module may not compile > > on your newer kernels. > > > > Please see Documentation/stable_api_nonsense.txt, in the kernel sources, > > or online at: > > <http://scienceblogs.com/gregladen/2007/12/linux_stable_api_vs_not.php> > > > > Note that without a stable API, there is no change of a stable ABI. > > > > > > Luciano, thank you very much. I read your post, the link you provided, and > a few other things from that link, and I at least understood enough to > realize that it answers my question. I think I *kind of* get it now. > > I think understanding the answer to my question really revolves around > understanding an API and an ABI. Would you please read the following and > let me know if I at least get the gist of what these two things are? FYI, when in doubt about these acronyms, search for "define: ABI", for instance, in google. > An API influences what your source code will look like. If they change the > Linux kernel API, then you may need to make changes to your source code such > as making "myLinuxKernelAPIFunctionCall( myparam1, myparam2 )" look > something more like "myUpdatedLinuxKernelAPIFunctionCall( myparam1 )" in > order to even make your code compile. Yes, but also more important things. Like changing the use of semaphores to mutexes, when appropriate (they "lock" something, mutexes can have only one accessing the something at once, while semaphores can have N accessing); changing the way stuff is exported to userland (sysfs, configfs, debugfs, relayfs, procfs); etc.. > The ABI is the interface between a compiled binary kernel module and the > kernel. It determines if an already compiled binary will properly interface > with the kernel and run. If the ABI changes and you find your kernel module > won't run properly, you just need to recompile from source to get a kernel > module that will run. Hopefully the API hasn't changed and you won't need > to change your source code to make it recompile... Yes, that's it. The compiled modules include the dependency info, so that you won't be able to insert it in another kernel: $ modinfo ext2.ko filename: ext2.ko license: GPL description: Second Extended Filesystem author: Remy Card and others depends: vermagic: 2.6.23.12lcfs1 preempt mod_unload PENTIUM4 4KSTACKS > BOTH kinds of changes happen with some degree of frequency in Linux. Yes. Due to the nature of the kernel (open-source, GPL), and the current policy, changes occur *very* frequently, especially in the 2.6.x series. > Did I get at least this much right? I think you're doing fine. Note that this state of affairs is more due to how the kernel people work/philosophy, than due to technical limitations, as Les Mikesell pointed out. Anyway, nifty things have come from this development method in the latest Linux kernels. Also, there are some stable apis/abis: userland driver (for simple devices, no dma is possible, for instance), and userland access to usb devices (mostly used for printers, scanners and non-standard usb memory sticks/mp3 players). -- lfr 0/0
Attachment:
pgp2QyJCTgxS7.pgp
Description: PGP signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
