En quelques mots, pourquoi je n’ai pas fait ni n’envisage de faire de scdrand un module noyau.
Vouloir faire ce que fait scdrand dans le noyau impliquerait, entre autres choses, de déplacer les pilotes de lecteurs de carte dans le noyau (actuellement, ils sont en espace utilisateur, gérés par le projet pcsc-lite notamment), ainsi que toute la logique de communication avec les cartes. C’est faisable, certes, mais c’est pas mal de boulot. Si je suis passé par scdaemon, c’est justement pour ne pas avoir à implémenter tout ce qu’il fait moi-même.
Ensuite, si c’est un module qui prend désormais en charge la communication avec les cartes à puce, ça veut dire que les programmes en espace utilisateur ne peuvent plus le faire directement. Tous les projets concernés par les cartes à puce (comme GnuPG et son programme scdaemon) devraient revoir complètement leur architecture pour utiliser une interface exportée par le noyau plutôt que d’utiliser l’API de pcsc-lite.
Ça fait de gros changements juste pour éviter à un programme d’interroger régulièrement l’état du pool d’entropie...
Par ailleurs, même à l’intérieur du noyau, il n’y a pas de mécanisme prévu pour informer automatiquement un module que l’entropie disponible dans le pool tombe en-dessous d’un certain seuil, ce serait encore une autre chose à changer.
Enfin, une considération un peu moins technique : la carte à puce appartient à un utilisateur donné, ce n’est pas un périphérique appartenant à l’ordinateur. J’estime que ce n’est pas au noyau de décider arbitrairement de solliciter ma carte quand bon lui semble.
[^] # Re: pilote noyau
Posté par gouttegd . En réponse à la dépêche scdrand: alimenter le pool d’entropie du noyau à partir d’une carte à puce. Évalué à 8.
En quelques mots, pourquoi je n’ai pas fait ni n’envisage de faire de scdrand un module noyau.
Vouloir faire ce que fait scdrand dans le noyau impliquerait, entre autres choses, de déplacer les pilotes de lecteurs de carte dans le noyau (actuellement, ils sont en espace utilisateur, gérés par le projet pcsc-lite notamment), ainsi que toute la logique de communication avec les cartes. C’est faisable, certes, mais c’est pas mal de boulot. Si je suis passé par scdaemon, c’est justement pour ne pas avoir à implémenter tout ce qu’il fait moi-même.
Ensuite, si c’est un module qui prend désormais en charge la communication avec les cartes à puce, ça veut dire que les programmes en espace utilisateur ne peuvent plus le faire directement. Tous les projets concernés par les cartes à puce (comme GnuPG et son programme scdaemon) devraient revoir complètement leur architecture pour utiliser une interface exportée par le noyau plutôt que d’utiliser l’API de pcsc-lite.
Ça fait de gros changements juste pour éviter à un programme d’interroger régulièrement l’état du pool d’entropie...
Par ailleurs, même à l’intérieur du noyau, il n’y a pas de mécanisme prévu pour informer automatiquement un module que l’entropie disponible dans le pool tombe en-dessous d’un certain seuil, ce serait encore une autre chose à changer.
Enfin, une considération un peu moins technique : la carte à puce appartient à un utilisateur donné, ce n’est pas un périphérique appartenant à l’ordinateur. J’estime que ce n’est pas au noyau de décider arbitrairement de solliciter ma carte quand bon lui semble.