On 11/18/2014 10:53 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-11-19 04:33, Andrei Borzenkov wrote:
В Tue, 18 Nov 2014 22:28:25 -0300 Claudio Freire <> пишет:
So what they complain about is internal instability. Some internal interfaces in the kernel are marked as "stable"
No, they are not.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documen...
At the best, some internal interfaces are so complicated that nobody dares to touch them because of unpredictable effects.
I think I understand now, thank you both :-)
Let me see if I can put it in my words.
Let's have a kernel module, internal part of the kernel source tree. If the api of some function it calls changes, the module doesn't build; being part of the kernel source tree, someone has to repair it before the entire kernel builds and can be published.
That is close, but not quite right. The rule is that if you are the one that changes an API such that it breaks part of the build, then you are required to fix all the users of that API. In fact, it is a requirement that the kernel build after every commit. That requirement is in place so that bisection of a regression will work.
But a module that is not part of the upstream kernel tree, but that is outside, external, has to be modified when their maintainers notice the problem, after the kernel is published. When, if, the module is inserted in the kernel, the problem is solved, not magically, but as a need, a necessity. Of course, as more modules are added, the kernel grows both in size and complexity, each small api change rippling over a cascade of changes in a pile of modules.
The API changes show up early in the evolution from version N to N+1. They are usually available in -rc1, and yes the external maintainer must adapt to these changes. If you look at any out-of-kernel driver that can be built for different kernel versions, you will see lots of preprocessor commands that test a macro named KERNEL_VERSION.
But the nvidia kernel modules can never be inserted in the source tree, because of incompatible licenses. Thus, the lag.
Nvidia can not, will not, open fully their sources. The kernel devs can not, will not, accept linking closed source blobs. Both sides have their valid reasons. Impasse.
If nvidia were to publish their sources under GPL, and they were willing to modify those sources to meet kernel coding standards, then their drivers would be accepted into the kernel. As those steps would reveal their trade secrets to the competition, they will never do that. Adding binary blobs to the kernel means that you are allowing code that cannot be reviewed to run with no restrictions. That is a major hit to security and stability. For that reason, loading such a driver sets the "taint" flag that alerts all developers. Most refuse to investigate a reported bug unless it can be reproduced without such a taint. Fedora's automated OOPS reporting will not operate whenever any of the taint flags is set. Their reason is that an OOPS usually leads to others, and they only want the primary failure; however, their policy prevents such automated processing if a staging driver has been loaded. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org