Nvivia a apparemment sorti un nouveau driver « compatible » avec le 5.9
Je suis allé creuser : dans le driver qui vient de sortir en novembre on a un nouveau flag créé dans le Kbuild qui s'appelle « NV_BUILD_MAY_USE_GPL_SYMBOLS » (on peut donc forcer à violer la GPL, qu'ils indique comme « permission d'utiliser », même si par défaut il est à 0) :
diff -ru 455-455.32/usr/src/nvidia-455/nvidia-uvm/nvidia-uvm.Kbuild 455-455.45/usr/src/nvidia-455/nvidia-uvm/nvidia-uvm.Kbuild
--- 455-455.32/usr/src/nvidia-455/nvidia-uvm/nvidia-uvm.Kbuild 2020年10月15日 00:58:52.000000000 +0200
+++ 455-455.45/usr/src/nvidia-455/nvidia-uvm/nvidia-uvm.Kbuild 2020年11月06日 00:15:34.000000000 +0100
@@ -54,6 +54,13 @@
NVIDIA_UVM_CFLAGS += -D__linux__
NVIDIA_UVM_CFLAGS += -I$(src)/nvidia-uvm
+# Avoid using GPL symbols unless explicitly permitted to do so.
+NV_BUILD_MAY_USE_GPL_SYMBOLS ?= 0
+
+ifeq ($(NV_BUILD_MAY_USE_GPL_SYMBOLS),1)
+ NVIDIA_UVM_CFLAGS += -DNV_BUILD_MAY_USE_GPL_SYMBOLS
+endif
+
# Avoid even building HMM until the HMM patch is in the upstream kernel.
# Bug 1772628 has details.
NV_BUILD_SUPPORTS_HMM ?= 0
Ce flag est pour l'instant uniquement utilisé lors du test de la présence de l'API gérant l'affinité des threads par CPU (flag UVM_THREAD_AFFINITY_SUPPORTED) qui est maintenant à zéro même si l'API (en particulier celle indiquée par le flag NV_KTHREAD_CREATE_ON_NODE_PRESENT) est présente quand le driver n'est pas autorisé à violer la GPL : c'est la fonction kthread_create_on_node() ajoutée en 2011 par Éric Dumazet dans le commit 207205a2ba26 qui est GPL et est utilisée par le shim « libre » de Nvidia.
Donc en fait je suppose qu'ainsi, les performances sont un peu dégradées car les threads ne sont pas créés sur le CPU le plus approprié pour la tâche, mais ça évite d'utiliser des symboles GPL dans ce shim, et donc de se faire bloquer comme violant la GPL par la nouvelle protection apportée par Hellwig. Je pensais que leurs dépendances étaient plus larges, si c'est le seul bout, on pourrait dire que c'est « bien joué » de la part de Nvidia, même si on sent quand même qu'ils aiment toujours bien jouer avec le feu.
[^] # Re: détails de l'histoire ?
Posté par benoar . En réponse au journal Linux & Nvidia. Évalué à 3.
Je suis allé creuser : dans le driver qui vient de sortir en novembre on a un nouveau flag créé dans le Kbuild qui s'appelle « NV_BUILD_MAY_USE_GPL_SYMBOLS » (on peut donc forcer à violer la GPL, qu'ils indique comme « permission d'utiliser », même si par défaut il est à 0) :
Ce flag est pour l'instant uniquement utilisé lors du test de la présence de l'API gérant l'affinité des threads par CPU (flag UVM_THREAD_AFFINITY_SUPPORTED) qui est maintenant à zéro même si l'API (en particulier celle indiquée par le flag NV_KTHREAD_CREATE_ON_NODE_PRESENT) est présente quand le driver n'est pas autorisé à violer la GPL : c'est la fonction kthread_create_on_node() ajoutée en 2011 par Éric Dumazet dans le commit 207205a2ba26 qui est GPL et est utilisée par le shim « libre » de Nvidia.
Donc en fait je suppose qu'ainsi, les performances sont un peu dégradées car les threads ne sont pas créés sur le CPU le plus approprié pour la tâche, mais ça évite d'utiliser des symboles GPL dans ce shim, et donc de se faire bloquer comme violant la GPL par la nouvelle protection apportée par Hellwig. Je pensais que leurs dépendances étaient plus larges, si c'est le seul bout, on pourrait dire que c'est « bien joué » de la part de Nvidia, même si on sent quand même qu'ils aiment toujours bien jouer avec le feu.