Luciano Rocha wrote: > 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). > > Thank you again for your help! You've given me a place to really get started and this doesn't seem quite so mysterious to me anymore. I have one last related burning question for now that I was hoping you might be able to answer. ATI drivers are proprietary and closed-source. So, for example, on my current desktop, I download the Linux drivers for my card from the link below and run the installer as per their instructions. http://ati.amd.com/support/drivers/linux/linux-radeon.html It's doing *something* to make a kernel module that will insert into and work with my current running kernel. At one time, I thought that it was compiling a module from source code, probably by invoking make, in much the same way I might download and install any open-source software in Linux from a tarball. However, I realized that this doesn't make sense since ATI's drivers are proprietary and closed-source. So the installer I download can't possibly be compiling anything from source code, because that would mean I could almost certainly read the source code, which they don't want. Which leaves me wondering what the installer is really doing. Any ideas? Thanks! bit