Ce que je ne comprends pas trop, c'est que la dernière l'explication de l'arret du dev était un probleme de license, je ne vois pas comment continuer a faire du dev peut résoudre un probleme de license, bah on verra bien..
On va faire simple ;-) Pour que dtrace fonctionne, il faut rajouter un peu partout du code sous CDDL, qui va "polluer" le code sous BSD du kernel. ZFS n'a pas ce probleme car c'est 1 module kernel. Pour Dtrace c'est la meme chose. Pour reprendre l'exemple de John Birrell. afin que drtace ait connaissance des etats internes au kernel, il faut rajouter un element dans la structure qui definit un thread. Et donc inclure du code CDDL dans du code 100% BSD. L'astuce du ifdef ne tient pas la ni pour des raisons legales, ni technique (ca casse l'ABI).
Toute l'astuce du port reside dans l'isolation du code sous CDDL et donc eviter le conflit de licence. Dans le cas de la structure d'un thread, c'est de rajouter un mecanisme (kernel-wide) qui permet d'avoir un element "opaque" qui sera exploite par dtrace, qui au final ne sera plus qu'un module a part.
[^] # Re: Un autre point
Posté par nullisimo . En réponse à la dépêche Sortie du noyau Linux 2.6.24. Évalué à 6.
On va faire simple ;-) Pour que dtrace fonctionne, il faut rajouter un peu partout du code sous CDDL, qui va "polluer" le code sous BSD du kernel. ZFS n'a pas ce probleme car c'est 1 module kernel. Pour Dtrace c'est la meme chose. Pour reprendre l'exemple de John Birrell. afin que drtace ait connaissance des etats internes au kernel, il faut rajouter un element dans la structure qui definit un thread. Et donc inclure du code CDDL dans du code 100% BSD. L'astuce du ifdef ne tient pas la ni pour des raisons legales, ni technique (ca casse l'ABI).
Toute l'astuce du port reside dans l'isolation du code sous CDDL et donc eviter le conflit de licence. Dans le cas de la structure d'un thread, c'est de rajouter un mecanisme (kernel-wide) qui permet d'avoir un element "opaque" qui sera exploite par dtrace, qui au final ne sera plus qu'un module a part.