je suis à la recherche de liens info sur les librairies
exploitables dans le noyau linux par un driver
pour faire de la crypto
en gros j'ai besoin de tester la primalité
de structures qui gèrent les grands nombres
et de l'opération modulo
j'ai bien trouvé crypto.h
http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1
mais je suis un peu bouché
ou en manque d'exemples
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
YBM
remy a écrit :
bonjour
je suis à la recherche de liens info sur les librairies exploitables dans le noyau linux par un driver pour faire de la crypto
en gros j'ai besoin de tester la primalité de structures qui gèrent les grands nombres et de l'opération modulo
j'ai bien trouvé crypto.h http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1
mais je suis un peu bouché ou en manque d'exemples
Comme déjà dit sur f.c.l.c coller toute une bibliothèque de calcul en multi précision dans le noyau est une mauvaise idée... Je ne vois toujours pas en quoi ton machin a le moindre intérêt à fournir un périphérique plutôt que d'être entièrement en espace user... Mais bon, un truc qui vient de sortir pourrait t'intéresser : CUSE (Char Device In User Space) :
je suis à la recherche de liens info sur les librairies
exploitables dans le noyau linux par un driver
pour faire de la crypto
en gros j'ai besoin de tester la primalité
de structures qui gèrent les grands nombres
et de l'opération modulo
j'ai bien trouvé crypto.h
http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1
mais je suis un peu bouché
ou en manque d'exemples
Comme déjà dit sur f.c.l.c coller toute une bibliothèque de
calcul en multi précision dans le noyau est une mauvaise idée...
Je ne vois toujours pas en quoi ton machin a le moindre intérêt
à fournir un périphérique plutôt que d'être entièrement en
espace user... Mais bon, un truc qui vient de sortir pourrait
t'intéresser : CUSE (Char Device In User Space) :
je suis à la recherche de liens info sur les librairies exploitables dans le noyau linux par un driver pour faire de la crypto
en gros j'ai besoin de tester la primalité de structures qui gèrent les grands nombres et de l'opération modulo
j'ai bien trouvé crypto.h http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1
mais je suis un peu bouché ou en manque d'exemples
Comme déjà dit sur f.c.l.c coller toute une bibliothèque de calcul en multi précision dans le noyau est une mauvaise idée... Je ne vois toujours pas en quoi ton machin a le moindre intérêt à fournir un périphérique plutôt que d'être entièrement en espace user... Mais bon, un truc qui vient de sortir pourrait t'intéresser : CUSE (Char Device In User Space) :
je suis à la recherche de liens info sur les librairies exploitables dans le noyau linux par un driver pour faire de la crypto
en gros j'ai besoin de tester la primalité de structures qui gèrent les grands nombres et de l'opération modulo
j'ai bien trouvé crypto.h http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1
mais je suis un peu bouché ou en manque d'exemples
Comme déjà dit sur f.c.l.c coller toute une bibliothèque de calcul en multi précision dans le noyau est une mauvaise idée... Je ne vois toujours pas en quoi ton machin a le moindre intérêt à fournir un périphérique plutôt que d'être entièrement en espace user... Mais bon, un truc qui vient de sortir pourrait t'intéresser : CUSE (Char Device In User Space) :
je suis à la recherche de liens info sur les librairies
exploitables dans le noyau linux par un driver
pour faire de la crypto
en gros j'ai besoin de tester la primalité
de structures qui gèrent les grands nombres
et de l'opération modulo
j'ai bien trouvé crypto.h
http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1
mais je suis un peu bouché
ou en manque d'exemples
Comme déjà dit sur f.c.l.c coller toute une bibliothèque de
calcul en multi précision dans le noyau est une mauvaise idée...
Je ne vois toujours pas en quoi ton machin a le moindre intérêt
à fournir un périphérique plutôt que d'être entièrement en
espace user... Mais bon, un truc qui vient de sortir pourrait
t'intéresser : CUSE (Char Device In User Space) :
je suis à la recherche de liens info sur les librairies exploitables dans le noyau linux par un driver pour faire de la crypto
en gros j'ai besoin de tester la primalité de structures qui gèrent les grands nombres et de l'opération modulo
j'ai bien trouvé crypto.h http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1
mais je suis un peu bouché ou en manque d'exemples
Comme déjà dit sur f.c.l.c coller toute une bibliothèque de calcul en multi précision dans le noyau est une mauvaise idée... Je ne vois toujours pas en quoi ton machin a le moindre intérêt à fournir un périphérique plutôt que d'être entièrement en espace user... Mais bon, un truc qui vient de sortir pourrait t'intéresser : CUSE (Char Device In User Space) :
je suis à la recherche de liens info sur les librairies exploitables dans le noyau linux par un driver pour faire de la crypto
en gros j'ai besoin de tester la primalité de structures qui gèrent les grands nombres et de l'opération modulo
j'ai bien trouvé crypto.h http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1
mais je suis un peu bouché ou en manque d'exemples
Comme déjà dit sur f.c.l.c coller toute une bibliothèque de calcul en multi précision dans le noyau est une mauvaise idée... Je ne vois toujours pas en quoi ton machin a le moindre intérêt à fournir un périphérique plutôt que d'être entièrement en espace user... Mais bon, un truc qui vient de sortir pourrait t'intéresser : CUSE (Char Device In User Space) :
Cependant je n'arrive vraiment pas à imaginer une seule raison valable pour laquelle ton machin aléatoire devrait être, ne serait-ce qu'en partie, dans le noyau et fournir un périphérique dans /dev.
Les seules raisons pour être dans le noyau sont 1) besoin d'un accès privilégié au matériel, 2) besoin d'interagir de façon "intime" avec un pilote dans le noyau ou 3) performances (ou temps réel dur) (les puristes des micro-noyaux éjectent 2) et 3) à la poubelle). Par ex :
Pilote son/reseau/disque : 1) Systèmes de fichiers : 2) et 3) TCP/IP : 2) et 3) Firewall : 2) et 3) /dev/random : 1) IPSEC : 2) et 3) etc.
Pour ton générateur aléatoire basé sur des (grands) nombres premiers je ne vois rien de semblable.
remy a écrit :
YBM a écrit :
remy a écrit :
bonjour
je suis à la recherche de liens info sur les librairies
exploitables dans le noyau linux par un driver
pour faire de la crypto
en gros j'ai besoin de tester la primalité
de structures qui gèrent les grands nombres
et de l'opération modulo
j'ai bien trouvé crypto.h
http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1
mais je suis un peu bouché
ou en manque d'exemples
Comme déjà dit sur f.c.l.c coller toute une bibliothèque de
calcul en multi précision dans le noyau est une mauvaise idée...
Je ne vois toujours pas en quoi ton machin a le moindre intérêt
à fournir un périphérique plutôt que d'être entièrement en
espace user... Mais bon, un truc qui vient de sortir pourrait
t'intéresser : CUSE (Char Device In User Space) :
Cependant je n'arrive vraiment pas à imaginer une seule raison
valable pour laquelle ton machin aléatoire devrait être, ne
serait-ce qu'en partie, dans le noyau et fournir un périphérique
dans /dev.
Les seules raisons pour être dans le noyau sont 1) besoin
d'un accès privilégié au matériel, 2) besoin d'interagir
de façon "intime" avec un pilote dans le noyau ou 3) performances
(ou temps réel dur)
(les puristes des micro-noyaux éjectent 2) et 3) à la poubelle).
Par ex :
Pilote son/reseau/disque : 1)
Systèmes de fichiers : 2) et 3)
TCP/IP : 2) et 3)
Firewall : 2) et 3)
/dev/random : 1)
IPSEC : 2) et 3)
etc.
Pour ton générateur aléatoire basé sur des (grands) nombres premiers
je ne vois rien de semblable.
je suis à la recherche de liens info sur les librairies exploitables dans le noyau linux par un driver pour faire de la crypto
en gros j'ai besoin de tester la primalité de structures qui gèrent les grands nombres et de l'opération modulo
j'ai bien trouvé crypto.h http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1
mais je suis un peu bouché ou en manque d'exemples
Comme déjà dit sur f.c.l.c coller toute une bibliothèque de calcul en multi précision dans le noyau est une mauvaise idée... Je ne vois toujours pas en quoi ton machin a le moindre intérêt à fournir un périphérique plutôt que d'être entièrement en espace user... Mais bon, un truc qui vient de sortir pourrait t'intéresser : CUSE (Char Device In User Space) :
Cependant je n'arrive vraiment pas à imaginer une seule raison valable pour laquelle ton machin aléatoire devrait être, ne serait-ce qu'en partie, dans le noyau et fournir un périphérique dans /dev.
Les seules raisons pour être dans le noyau sont 1) besoin d'un accès privilégié au matériel, 2) besoin d'interagir de façon "intime" avec un pilote dans le noyau ou 3) performances (ou temps réel dur) (les puristes des micro-noyaux éjectent 2) et 3) à la poubelle). Par ex :
Pilote son/reseau/disque : 1) Systèmes de fichiers : 2) et 3) TCP/IP : 2) et 3) Firewall : 2) et 3) /dev/random : 1) IPSEC : 2) et 3) etc.
Pour ton générateur aléatoire basé sur des (grands) nombres premiers je ne vois rien de semblable.
remy
YBM a écrit :
remy a écrit :
YBM a écrit :
remy a écrit :
bonjour
je suis à la recherche de liens info sur les librairies exploitables dans le noyau linux par un driver pour faire de la crypto
en gros j'ai besoin de tester la primalité de structures qui gèrent les grands nombres et de l'opération modulo
j'ai bien trouvé crypto.h http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1
mais je suis un peu bouché ou en manque d'exemples
Comme déjà dit sur f.c.l.c coller toute une bibliothèque de calcul en multi précision dans le noyau est une mauvaise idée... Je ne vois toujours pas en quoi ton machin a le moindre intérêt à fournir un périphérique plutôt que d'être entièrement en espace user... Mais bon, un truc qui vient de sortir pourrait t'intéresser : CUSE (Char Device In User Space) :
Cependant je n'arrive vraiment pas à imaginer une seule raison valable pour laquelle ton machin aléatoire devrait être, ne serait-ce qu'en partie, dans le noyau et fournir un périphérique dans /dev.
Les seules raisons pour être dans le noyau sont 1) besoin d'un accès privilégié au matériel, 2) besoin d'interagir de façon "intime" avec un pilote dans le noyau ou 3) performances (ou temps réel dur) (les puristes des micro-noyaux éjectent 2) et 3) à la poubelle). Par ex :
Pilote son/reseau/disque : 1) Systèmes de fichiers : 2) et 3) TCP/IP : 2) et 3) Firewall : 2) et 3) /dev/random : 1) IPSEC : 2) et 3) etc.
Pour ton générateur aléatoire basé sur des (grands) nombres premiers je ne vois rien de semblable.
il n'y a pas de raison objective basée sur une contrainte tangible dit différemment je cherche à coller à une pratique ou à faire un peu comme tout le monde
je cherche à mettre mon truc dans /dev/ parce qu'il y a déjà un /dev/random il ne faut pas chercher plus loin
dans tous les cas j'ai mon driver qui tourne
je vais coder mon truc en c et à un moment donné j'essaierai de faire converger les deux bouts de code
remy
YBM a écrit :
remy a écrit :
YBM a écrit :
remy a écrit :
bonjour
je suis à la recherche de liens info sur les librairies
exploitables dans le noyau linux par un driver
pour faire de la crypto
en gros j'ai besoin de tester la primalité
de structures qui gèrent les grands nombres
et de l'opération modulo
j'ai bien trouvé crypto.h
http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1
mais je suis un peu bouché
ou en manque d'exemples
Comme déjà dit sur f.c.l.c coller toute une bibliothèque de
calcul en multi précision dans le noyau est une mauvaise idée...
Je ne vois toujours pas en quoi ton machin a le moindre intérêt
à fournir un périphérique plutôt que d'être entièrement en
espace user... Mais bon, un truc qui vient de sortir pourrait
t'intéresser : CUSE (Char Device In User Space) :
Cependant je n'arrive vraiment pas à imaginer une seule raison
valable pour laquelle ton machin aléatoire devrait être, ne
serait-ce qu'en partie, dans le noyau et fournir un périphérique
dans /dev.
Les seules raisons pour être dans le noyau sont 1) besoin
d'un accès privilégié au matériel, 2) besoin d'interagir
de façon "intime" avec un pilote dans le noyau ou 3) performances
(ou temps réel dur)
(les puristes des micro-noyaux éjectent 2) et 3) à la poubelle).
Par ex :
Pilote son/reseau/disque : 1)
Systèmes de fichiers : 2) et 3)
TCP/IP : 2) et 3)
Firewall : 2) et 3)
/dev/random : 1)
IPSEC : 2) et 3)
etc.
Pour ton générateur aléatoire basé sur des (grands) nombres premiers
je ne vois rien de semblable.
il n'y a pas de raison objective basée sur une contrainte tangible
dit différemment je cherche à coller à une pratique ou à faire un peu
comme tout le monde
je cherche à mettre mon truc dans /dev/ parce qu'il y a déjà un
/dev/random il ne faut pas chercher plus loin
dans tous les cas j'ai mon driver qui tourne
je vais coder mon truc en c et à un moment donné j'essaierai de faire
converger les deux bouts de code
je suis à la recherche de liens info sur les librairies exploitables dans le noyau linux par un driver pour faire de la crypto
en gros j'ai besoin de tester la primalité de structures qui gèrent les grands nombres et de l'opération modulo
j'ai bien trouvé crypto.h http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1
mais je suis un peu bouché ou en manque d'exemples
Comme déjà dit sur f.c.l.c coller toute une bibliothèque de calcul en multi précision dans le noyau est une mauvaise idée... Je ne vois toujours pas en quoi ton machin a le moindre intérêt à fournir un périphérique plutôt que d'être entièrement en espace user... Mais bon, un truc qui vient de sortir pourrait t'intéresser : CUSE (Char Device In User Space) :
Cependant je n'arrive vraiment pas à imaginer une seule raison valable pour laquelle ton machin aléatoire devrait être, ne serait-ce qu'en partie, dans le noyau et fournir un périphérique dans /dev.
Les seules raisons pour être dans le noyau sont 1) besoin d'un accès privilégié au matériel, 2) besoin d'interagir de façon "intime" avec un pilote dans le noyau ou 3) performances (ou temps réel dur) (les puristes des micro-noyaux éjectent 2) et 3) à la poubelle). Par ex :
Pilote son/reseau/disque : 1) Systèmes de fichiers : 2) et 3) TCP/IP : 2) et 3) Firewall : 2) et 3) /dev/random : 1) IPSEC : 2) et 3) etc.
Pour ton générateur aléatoire basé sur des (grands) nombres premiers je ne vois rien de semblable.
il n'y a pas de raison objective basée sur une contrainte tangible dit différemment je cherche à coller à une pratique ou à faire un peu comme tout le monde
je cherche à mettre mon truc dans /dev/ parce qu'il y a déjà un /dev/random il ne faut pas chercher plus loin
dans tous les cas j'ai mon driver qui tourne
je vais coder mon truc en c et à un moment donné j'essaierai de faire converger les deux bouts de code
remy
YBM
remy a écrit :
YBM a écrit :
...
Pour ton générateur aléatoire basé sur des (grands) nombres premiers je ne vois rien de semblable.
il n'y a pas de raison objective basée sur une contrainte tangible dit différemment je cherche à coller à une pratique ou à faire un peu comme tout le monde
Donc aucune raison, et NON ce n'est pas "faire un peu comme tout le monde".
je cherche à mettre mon truc dans /dev/ parce qu'il y a déjà un /dev/random il ne faut pas chercher plus loin
Tu aurais commencer à te demander pourquoi le générateur derrière /dev/random est un pilote : uniquement parce qu'il se base sur des évènements matériels, et que ce sont les pilotes de périphériques qui sont en mesure d'obtenir ces informations afin d'augmenter le pool d'entropie. Le cas de /dev/urandom est plus problématique, mais vu comment il est simple, c'est pas trop grave de le mettre dans le noyau, même si un simple service en mode utilisateur aurait pu faire de même. C'est le côté un peu opportuniste d'UNIX qui laisse faire ça.
dans tous les cas j'ai mon driver qui tourne
Déjà ? Tu as réussi à faire l'immense bêtise de lier libgmp à un module ? J'en doute...
je vais coder mon truc en c et à un moment donné j'essaierai de faire converger les deux bouts de code
Ce qui n'a pas le moindre intérêt : fais en plutôt un service de ton bousin.
remy a écrit :
YBM a écrit :
...
Pour ton générateur aléatoire basé sur des (grands) nombres premiers
je ne vois rien de semblable.
il n'y a pas de raison objective basée sur une contrainte tangible
dit différemment je cherche à coller à une pratique ou à faire un peu
comme tout le monde
Donc aucune raison, et NON ce n'est pas "faire un peu comme
tout le monde".
je cherche à mettre mon truc dans /dev/ parce qu'il y a déjà un
/dev/random il ne faut pas chercher plus loin
Tu aurais commencer à te demander pourquoi le générateur derrière
/dev/random est un pilote : uniquement parce qu'il se base sur des
évènements matériels, et que ce sont les pilotes de périphériques
qui sont en mesure d'obtenir ces informations afin d'augmenter le
pool d'entropie. Le cas de /dev/urandom est plus problématique,
mais vu comment il est simple, c'est pas trop grave de le
mettre dans le noyau, même si un simple service en mode utilisateur
aurait pu faire de même. C'est le côté un peu opportuniste
d'UNIX qui laisse faire ça.
dans tous les cas j'ai mon driver qui tourne
Déjà ? Tu as réussi à faire l'immense bêtise de lier libgmp
à un module ? J'en doute...
je vais coder mon truc en c et à un moment donné j'essaierai de faire
converger les deux bouts de code
Ce qui n'a pas le moindre intérêt : fais en plutôt un service de ton
bousin.
Pour ton générateur aléatoire basé sur des (grands) nombres premiers je ne vois rien de semblable.
il n'y a pas de raison objective basée sur une contrainte tangible dit différemment je cherche à coller à une pratique ou à faire un peu comme tout le monde
Donc aucune raison, et NON ce n'est pas "faire un peu comme tout le monde".
je cherche à mettre mon truc dans /dev/ parce qu'il y a déjà un /dev/random il ne faut pas chercher plus loin
Tu aurais commencer à te demander pourquoi le générateur derrière /dev/random est un pilote : uniquement parce qu'il se base sur des évènements matériels, et que ce sont les pilotes de périphériques qui sont en mesure d'obtenir ces informations afin d'augmenter le pool d'entropie. Le cas de /dev/urandom est plus problématique, mais vu comment il est simple, c'est pas trop grave de le mettre dans le noyau, même si un simple service en mode utilisateur aurait pu faire de même. C'est le côté un peu opportuniste d'UNIX qui laisse faire ça.
dans tous les cas j'ai mon driver qui tourne
Déjà ? Tu as réussi à faire l'immense bêtise de lier libgmp à un module ? J'en doute...
je vais coder mon truc en c et à un moment donné j'essaierai de faire converger les deux bouts de code
Ce qui n'a pas le moindre intérêt : fais en plutôt un service de ton bousin.
remy
YBM a écrit :
remy a écrit :
YBM a écrit :
...
Pour ton générateur aléatoire basé sur des (grands) nombres premiers je ne vois rien de semblable.
il n'y a pas de raison objective basée sur une contrainte tangible dit différemment je cherche à coller à une pratique ou à faire un peu comme tout le monde
Donc aucune raison, et NON ce n'est pas "faire un peu comme tout le monde".
oui complètement d'accord
tu peux même rajouter qu'il n'y aura personne qui utilisera se truc donc c'est pas très grave
mais comme je suis borné ...
je cherche à mettre mon truc dans /dev/ parce qu'il y a déjà un /dev/random il ne faut pas chercher plus loin
Tu aurais commencer à te demander pourquoi le générateur derrière /dev/random est un pilote : uniquement parce qu'il se base sur des évènements matériels, et que ce sont les pilotes de périphériques qui sont en mesure d'obtenir ces informations afin d'augmenter le pool d'entropie.
ah ben merde alors ça ....
Le cas de /dev/urandom est plus problématique,
mais vu comment il est simple, c'est pas trop grave de le mettre dans le noyau, même si un simple service en mode utilisateur aurait pu faire de même. C'est le côté un peu opportuniste d'UNIX qui laisse faire ça.
dans tous les cas j'ai mon driver qui tourne
Déjà ? Tu as réussi à faire l'immense bêtise de lier libgmp à un module ? J'en doute...
non non c'est pas de mon niveau, mon c'est antédiluvien juste un truc qui dit coucou et qui se charge et c'est déjà pas mal, cela fait plus de 20 ans que je n'ai pas touché un compilateur c
j'ai bien essayé de lire les makefile du noyau mais
je ne crois pas qu'il faille avoir un esprit sain pour aller se perdre dans le dédale
point de départ make -C ${KERNEL_SOURCE} M=${PWD} modules
je me suis arrêté /usr/src/linux-headers-2.6.20/scripts/Makefile.modpost
il y avait longtemps que je n'avais pas vu un tel enchevêtrement
je vais coder mon truc en c et à un moment donné j'essaierai de faire converger les deux bouts de code
Ce qui n'a pas le moindre intérêt : fais en plutôt un service de ton bousin.
je code mon bousin avec gmp et après je réfléchirais j'en ai marre de lire du code
YBM a écrit :
remy a écrit :
YBM a écrit :
...
Pour ton générateur aléatoire basé sur des (grands) nombres premiers
je ne vois rien de semblable.
il n'y a pas de raison objective basée sur une contrainte tangible
dit différemment je cherche à coller à une pratique ou à faire un peu
comme tout le monde
Donc aucune raison, et NON ce n'est pas "faire un peu comme
tout le monde".
oui complètement d'accord
tu peux même rajouter qu'il n'y aura personne qui utilisera se truc
donc c'est pas très grave
mais comme je suis borné ...
je cherche à mettre mon truc dans /dev/ parce qu'il y a déjà un
/dev/random il ne faut pas chercher plus loin
Tu aurais commencer à te demander pourquoi le générateur derrière
/dev/random est un pilote : uniquement parce qu'il se base sur des
évènements matériels, et que ce sont les pilotes de périphériques
qui sont en mesure d'obtenir ces informations afin d'augmenter le
pool d'entropie.
ah ben merde alors ça ....
Le cas de /dev/urandom est plus problématique,
mais vu comment il est simple, c'est pas trop grave de le
mettre dans le noyau, même si un simple service en mode utilisateur
aurait pu faire de même. C'est le côté un peu opportuniste
d'UNIX qui laisse faire ça.
dans tous les cas j'ai mon driver qui tourne
Déjà ? Tu as réussi à faire l'immense bêtise de lier libgmp
à un module ? J'en doute...
non non c'est pas de mon niveau, mon c'est antédiluvien
juste un truc qui dit coucou et qui se charge
et c'est déjà pas mal, cela fait plus de 20 ans que je n'ai pas touché
un compilateur c
j'ai bien essayé de lire les makefile du noyau mais
je ne crois pas qu'il faille avoir un esprit sain pour
aller se perdre dans le dédale
point de départ
make -C ${KERNEL_SOURCE} M=${PWD} modules
je me suis arrêté
/usr/src/linux-headers-2.6.20/scripts/Makefile.modpost
il y avait longtemps que je n'avais pas vu un tel enchevêtrement
je vais coder mon truc en c et à un moment donné j'essaierai de faire
converger les deux bouts de code
Ce qui n'a pas le moindre intérêt : fais en plutôt un service de ton
bousin.
je code mon bousin avec gmp
et après je réfléchirais j'en ai marre de lire du code
Pour ton générateur aléatoire basé sur des (grands) nombres premiers je ne vois rien de semblable.
il n'y a pas de raison objective basée sur une contrainte tangible dit différemment je cherche à coller à une pratique ou à faire un peu comme tout le monde
Donc aucune raison, et NON ce n'est pas "faire un peu comme tout le monde".
oui complètement d'accord
tu peux même rajouter qu'il n'y aura personne qui utilisera se truc donc c'est pas très grave
mais comme je suis borné ...
je cherche à mettre mon truc dans /dev/ parce qu'il y a déjà un /dev/random il ne faut pas chercher plus loin
Tu aurais commencer à te demander pourquoi le générateur derrière /dev/random est un pilote : uniquement parce qu'il se base sur des évènements matériels, et que ce sont les pilotes de périphériques qui sont en mesure d'obtenir ces informations afin d'augmenter le pool d'entropie.
ah ben merde alors ça ....
Le cas de /dev/urandom est plus problématique,
mais vu comment il est simple, c'est pas trop grave de le mettre dans le noyau, même si un simple service en mode utilisateur aurait pu faire de même. C'est le côté un peu opportuniste d'UNIX qui laisse faire ça.
dans tous les cas j'ai mon driver qui tourne
Déjà ? Tu as réussi à faire l'immense bêtise de lier libgmp à un module ? J'en doute...
non non c'est pas de mon niveau, mon c'est antédiluvien juste un truc qui dit coucou et qui se charge et c'est déjà pas mal, cela fait plus de 20 ans que je n'ai pas touché un compilateur c
j'ai bien essayé de lire les makefile du noyau mais
je ne crois pas qu'il faille avoir un esprit sain pour aller se perdre dans le dédale
point de départ make -C ${KERNEL_SOURCE} M=${PWD} modules
je me suis arrêté /usr/src/linux-headers-2.6.20/scripts/Makefile.modpost
il y avait longtemps que je n'avais pas vu un tel enchevêtrement
je vais coder mon truc en c et à un moment donné j'essaierai de faire converger les deux bouts de code
Ce qui n'a pas le moindre intérêt : fais en plutôt un service de ton bousin.
je code mon bousin avec gmp et après je réfléchirais j'en ai marre de lire du code
