FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 12-26-2007, 09:01 PM
Bit
 
Default Linux vs Windows Drivers

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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-26-2007, 09:34 PM
Luciano Rocha
 
Default Linux vs Windows Drivers

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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-26-2007, 09:40 PM
Johnny Hughes
 
Default Linux vs Windows Drivers

Bit wrote:
> 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?
>

It is compiling a module from kernel source code ... part of the
process also LINKS into PRE compiled object files (also known a .o
files) and /or shared object files (also known as .so files).

ATI (and nvidia) provide pre-compiled .o files to link to ... without
providing the source code to build the .o files.

The newer ATI drivers are really open source, so they provide the source
code to build the .o files.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 12-27-2007, 01:47 PM
Bit
 
Default Linux vs Windows Drivers

Luciano Rocha wrote:

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.


Thanks! I appreciate you taking the time to explain all that. I have
some moderate amount of programming experience, so that did (for the
most part) make sense. =)


Thanks to everyone else who helped out too. This has probably been the
most helpful thread I've ever read. One of those little things
constantly at the back of my mind finally put to rest. =P

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 08:55 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org