[CentOS] Linux vs Windows Drivers

Luciano Rocha strange at nsk.no-ip.org
Wed Dec 26 22:34:09 UTC 2007


On Wed, Dec 26, 2007 at 05:01:54PM -0500, Bit wrote:
>  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?
> 

The drivers are comprised of two things:
1. The X driver and OpenGL library, usually in binary form only;
2. The kernel driver for accessing and controlling the hardware.

Usually, the X driver/OpenGL library does most of the "3D" work, but
that isn't necessarily so.

Now, about the "can't possibly be compiling anything from source code".

Assuming you have compiled or developed a few things, you should know
that the final program is composed by several object files, .o.

Kernel drivers/modules aren't any different. What happens is that
there's at least one binary .o, without any source code, already compiled
in the installer/package.

There's also what is usually called a shim. A piece of source code that
does the bridge between your kernel and the real code. The real code is
thus a little abstracted from the kernel API, though not at all, as was
attested by recent breaks in the nVidia driver with new kernels. But
they are usually quick to respond to those changes.

So, there _is_ a make and compile involved, but is usually the
compilation of small code, linking with the big blob in an .o.

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos/attachments/20071226/a9850856/attachment.sig>


More information about the CentOS mailing list