Je ne suis peut-etre pas au bon endroit pour poser ma question, mais
apres avoir parcouru le web et autres newsgroups, je n'ai aps encore
trouvé de solution.
Je souhaiterais modifier un module du noyau Linux. Les fonctions que je
rajoute utilisent des macros (et d'autres fonctions) definies dans la
stdlib.h. Le probleme est que je n'arrive pas a compiler mon nouveau
module :
/home/toto$ make -C /usr/src/linux SUBDIRS=$PWD modules
Les sources du noyau sont bien dans /usr/src/linux. A la compilation,
gcc ne trouve pas le fichier stdlib.h. Normal car ce fichier n'est pas
dans l'arborescence du noyau mais dans /usr/include. Lorsque je specifie
le chemin complet dans le source du module
(#include "/usr/include/stdlib.h"), j'ai d'autres erreurs car le fichier
stdlib fait des inclusions d'autres fichiers egalement dans /usr/include.
Y'a-t-il un moyen simple et propre pour remedier a ce probleme ? (je
pourrais eventuellement copier le stdlib.h ainsi que les autres .h
necessaires dans l'arborescence du noyau, mais je ne pense pas que ce
soit une bonne solution).
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
screetch
je ne pense pas que le noyau soit sensé utiliser stdlib puisque stdlib contient beaucoup de routines "haut niveau" qui sont une surcouche du noyau linux. Les fonctionalités que tu cherches dans stdlib existent surement dans le reste du noyau, sous forme d'appels systemes probablement. c'est comme si tu essayais de faire un printf au sein de printf pour debugger la fonction...
Maintenant je ne sais pas exactement ce que tu veux faire, peut etre as tu de bonnes raisons, mais ca me parait impossible.
Erwann Thoraval wrote:
Bonjour,
Je ne suis peut-etre pas au bon endroit pour poser ma question, mais apres avoir parcouru le web et autres newsgroups, je n'ai aps encore trouvé de solution.
Je souhaiterais modifier un module du noyau Linux. Les fonctions que je rajoute utilisent des macros (et d'autres fonctions) definies dans la stdlib.h. Le probleme est que je n'arrive pas a compiler mon nouveau module :
/home/toto$ make -C /usr/src/linux SUBDIRS=$PWD modules
Les sources du noyau sont bien dans /usr/src/linux. A la compilation, gcc ne trouve pas le fichier stdlib.h. Normal car ce fichier n'est pas dans l'arborescence du noyau mais dans /usr/include. Lorsque je specifie le chemin complet dans le source du module (#include "/usr/include/stdlib.h"), j'ai d'autres erreurs car le fichier stdlib fait des inclusions d'autres fichiers egalement dans /usr/include.
Y'a-t-il un moyen simple et propre pour remedier a ce probleme ? (je pourrais eventuellement copier le stdlib.h ainsi que les autres .h necessaires dans l'arborescence du noyau, mais je ne pense pas que ce soit une bonne solution).
je ne pense pas que le noyau soit sensé utiliser stdlib puisque stdlib
contient beaucoup de routines "haut niveau" qui sont une surcouche du
noyau linux. Les fonctionalités que tu cherches dans stdlib existent
surement dans le reste du noyau, sous forme d'appels systemes
probablement. c'est comme si tu essayais de faire un printf au sein de
printf pour debugger la fonction...
Maintenant je ne sais pas exactement ce que tu veux faire, peut etre as
tu de bonnes raisons, mais ca me parait impossible.
Erwann Thoraval wrote:
Bonjour,
Je ne suis peut-etre pas au bon endroit pour poser ma question, mais
apres avoir parcouru le web et autres newsgroups, je n'ai aps encore
trouvé de solution.
Je souhaiterais modifier un module du noyau Linux. Les fonctions que je
rajoute utilisent des macros (et d'autres fonctions) definies dans la
stdlib.h. Le probleme est que je n'arrive pas a compiler mon nouveau
module :
/home/toto$ make -C /usr/src/linux SUBDIRS=$PWD modules
Les sources du noyau sont bien dans /usr/src/linux. A la compilation,
gcc ne trouve pas le fichier stdlib.h. Normal car ce fichier n'est pas
dans l'arborescence du noyau mais dans /usr/include. Lorsque je specifie
le chemin complet dans le source du module
(#include "/usr/include/stdlib.h"), j'ai d'autres erreurs car le fichier
stdlib fait des inclusions d'autres fichiers egalement dans /usr/include.
Y'a-t-il un moyen simple et propre pour remedier a ce probleme ? (je
pourrais eventuellement copier le stdlib.h ainsi que les autres .h
necessaires dans l'arborescence du noyau, mais je ne pense pas que ce
soit une bonne solution).
je ne pense pas que le noyau soit sensé utiliser stdlib puisque stdlib contient beaucoup de routines "haut niveau" qui sont une surcouche du noyau linux. Les fonctionalités que tu cherches dans stdlib existent surement dans le reste du noyau, sous forme d'appels systemes probablement. c'est comme si tu essayais de faire un printf au sein de printf pour debugger la fonction...
Maintenant je ne sais pas exactement ce que tu veux faire, peut etre as tu de bonnes raisons, mais ca me parait impossible.
Erwann Thoraval wrote:
Bonjour,
Je ne suis peut-etre pas au bon endroit pour poser ma question, mais apres avoir parcouru le web et autres newsgroups, je n'ai aps encore trouvé de solution.
Je souhaiterais modifier un module du noyau Linux. Les fonctions que je rajoute utilisent des macros (et d'autres fonctions) definies dans la stdlib.h. Le probleme est que je n'arrive pas a compiler mon nouveau module :
/home/toto$ make -C /usr/src/linux SUBDIRS=$PWD modules
Les sources du noyau sont bien dans /usr/src/linux. A la compilation, gcc ne trouve pas le fichier stdlib.h. Normal car ce fichier n'est pas dans l'arborescence du noyau mais dans /usr/include. Lorsque je specifie le chemin complet dans le source du module (#include "/usr/include/stdlib.h"), j'ai d'autres erreurs car le fichier stdlib fait des inclusions d'autres fichiers egalement dans /usr/include.
Y'a-t-il un moyen simple et propre pour remedier a ce probleme ? (je pourrais eventuellement copier le stdlib.h ainsi que les autres .h necessaires dans l'arborescence du noyau, mais je ne pense pas que ce soit une bonne solution).
Erwann Thoraval
screetch wrote:
Maintenant je ne sais pas exactement ce que tu veux faire, peut etre as tu de bonnes raisons, mais ca me parait impossible.
En fait, c'est pour utiliser les fonctions drand48() et srand48() qui generent des nombres pseudo-aleatoires. Peut-etre existe-t-il des equivalents dans le noyau, mais je ne les connais pas.
-- Erwann
screetch wrote:
Maintenant je ne sais pas exactement ce que tu veux faire, peut etre as
tu de bonnes raisons, mais ca me parait impossible.
En fait, c'est pour utiliser les fonctions drand48() et srand48() qui
generent des nombres pseudo-aleatoires. Peut-etre existe-t-il des
equivalents dans le noyau, mais je ne les connais pas.
Maintenant je ne sais pas exactement ce que tu veux faire, peut etre as tu de bonnes raisons, mais ca me parait impossible.
En fait, c'est pour utiliser les fonctions drand48() et srand48() qui generent des nombres pseudo-aleatoires. Peut-etre existe-t-il des equivalents dans le noyau, mais je ne les connais pas.
-- Erwann
Targeur fou
Erwann Thoraval wrote:
Bonjour,
Bonjour,
[coupé]
Y'a-t-il un moyen simple et propre pour remedier a ce probleme ? (je pourrais eventuellement copier le stdlib.h ainsi que les autres .h necessaires dans l'arborescence du noyau, mais je ne pense pas que ce
soit une bonne solution).
De quelles macros s'agit-il ? Si ce n'est pas trop compliqué, le mieux serait AMA de les refaire dans un .h à part pour garder l'indépendance entre sources du noyau et sources de la libc.
Regis
Erwann Thoraval wrote:
Bonjour,
Bonjour,
[coupé]
Y'a-t-il un moyen simple et propre pour remedier a ce probleme ? (je
pourrais eventuellement copier le stdlib.h ainsi que les autres .h
necessaires dans l'arborescence du noyau, mais je ne pense pas que ce
soit une bonne solution).
De quelles macros s'agit-il ?
Si ce n'est pas trop compliqué, le mieux serait AMA de les refaire
dans un .h à part pour garder l'indépendance entre sources du noyau
et sources de la libc.
Y'a-t-il un moyen simple et propre pour remedier a ce probleme ? (je pourrais eventuellement copier le stdlib.h ainsi que les autres .h necessaires dans l'arborescence du noyau, mais je ne pense pas que ce
soit une bonne solution).
De quelles macros s'agit-il ? Si ce n'est pas trop compliqué, le mieux serait AMA de les refaire dans un .h à part pour garder l'indépendance entre sources du noyau et sources de la libc.
Regis
screetch
les appels systemes de lnux permettent ca, mais je ne sais pas ou ^^
je sais que ca existe car le fichier /dev/random utilise cela, mais je ne sais pas comment il est géré. Cen 'est surement pas l'equivalent exact de drand48 et srand48, il faudra aussi sans doute adapter
Erwann Thoraval wrote:
screetch wrote:
Maintenant je ne sais pas exactement ce que tu veux faire, peut etre as tu de bonnes raisons, mais ca me parait impossible.
En fait, c'est pour utiliser les fonctions drand48() et srand48() qui generent des nombres pseudo-aleatoires. Peut-etre existe-t-il des equivalents dans le noyau, mais je ne les connais pas.
les appels systemes de lnux permettent ca, mais je ne sais pas ou ^^
je sais que ca existe car le fichier /dev/random utilise cela, mais je
ne sais pas comment il est géré. Cen 'est surement pas l'equivalent
exact de drand48 et srand48, il faudra aussi sans doute adapter
Erwann Thoraval wrote:
screetch wrote:
Maintenant je ne sais pas exactement ce que tu veux faire, peut etre
as tu de bonnes raisons, mais ca me parait impossible.
En fait, c'est pour utiliser les fonctions drand48() et srand48() qui
generent des nombres pseudo-aleatoires. Peut-etre existe-t-il des
equivalents dans le noyau, mais je ne les connais pas.
les appels systemes de lnux permettent ca, mais je ne sais pas ou ^^
je sais que ca existe car le fichier /dev/random utilise cela, mais je ne sais pas comment il est géré. Cen 'est surement pas l'equivalent exact de drand48 et srand48, il faudra aussi sans doute adapter
Erwann Thoraval wrote:
screetch wrote:
Maintenant je ne sais pas exactement ce que tu veux faire, peut etre as tu de bonnes raisons, mais ca me parait impossible.
En fait, c'est pour utiliser les fonctions drand48() et srand48() qui generent des nombres pseudo-aleatoires. Peut-etre existe-t-il des equivalents dans le noyau, mais je ne les connais pas.
Antoine Leca
En news:d19ecs$bk0$, Erwann Thoraval va escriure:
screetch wrote:
Maintenant je ne sais pas exactement ce que tu veux faire,
En fait, c'est pour utiliser les fonctions drand48() et srand48()
Tu peux toujours inclure le prototype de ces fonctions à la place où tu as mis l'#include <stdlib.h>, cela reviendra au même... double drand48(void); void srand48(long);
Maintenant, si tu essayes cela sans autre précaution, je pense que tu avoir une erreur à l'édition des liens, à propos de symboles non définis... parce que #inclure <stdlib.h>, ce n'est qu'un tout petit bout de l'iceberg.
qui generent des nombres pseudo-aleatoires. Peut-etre existe-t-il des equivalents dans le noyau, mais je ne les connais pas.
Juste un tuyau: si «générateur de nombres pseudo-aléatoires» ne t'a pas donné de bons résultats dans tes exhaustives recherches, essaye donc l'équivalent anglais, "random". Google ne me donne que 1.200.000 pages (http://www.google.com/search?hl=xx-hacker&q=random+kernel+linux), il y a peut-être d'autres moteurs de recherche qui donnent de meilleurs résultats...
Antoine
En news:d19ecs$bk0$1@amma.irisa.fr, Erwann Thoraval va escriure:
screetch wrote:
Maintenant je ne sais pas exactement ce que tu veux faire,
En fait, c'est pour utiliser les fonctions drand48() et srand48()
Tu peux toujours inclure le prototype de ces fonctions à la place où tu as
mis l'#include <stdlib.h>, cela reviendra au même...
double drand48(void);
void srand48(long);
Maintenant, si tu essayes cela sans autre précaution, je pense que tu avoir
une erreur à l'édition des liens, à propos de symboles non définis... parce
que #inclure <stdlib.h>, ce n'est qu'un tout petit bout de l'iceberg.
qui generent des nombres pseudo-aleatoires. Peut-etre existe-t-il
des equivalents dans le noyau, mais je ne les connais pas.
Juste un tuyau: si «générateur de nombres pseudo-aléatoires» ne t'a pas
donné de bons résultats dans tes exhaustives recherches, essaye donc
l'équivalent anglais, "random". Google ne me donne que 1.200.000 pages
(http://www.google.com/search?hl=xx-hacker&q=random+kernel+linux), il y a
peut-être d'autres moteurs de recherche qui donnent de meilleurs
résultats...
Maintenant je ne sais pas exactement ce que tu veux faire,
En fait, c'est pour utiliser les fonctions drand48() et srand48()
Tu peux toujours inclure le prototype de ces fonctions à la place où tu as mis l'#include <stdlib.h>, cela reviendra au même... double drand48(void); void srand48(long);
Maintenant, si tu essayes cela sans autre précaution, je pense que tu avoir une erreur à l'édition des liens, à propos de symboles non définis... parce que #inclure <stdlib.h>, ce n'est qu'un tout petit bout de l'iceberg.
qui generent des nombres pseudo-aleatoires. Peut-etre existe-t-il des equivalents dans le noyau, mais je ne les connais pas.
Juste un tuyau: si «générateur de nombres pseudo-aléatoires» ne t'a pas donné de bons résultats dans tes exhaustives recherches, essaye donc l'équivalent anglais, "random". Google ne me donne que 1.200.000 pages (http://www.google.com/search?hl=xx-hacker&q=random+kernel+linux), il y a peut-être d'autres moteurs de recherche qui donnent de meilleurs résultats...
Antoine
Erwann Thoraval
Antoine Leca wrote:
Maintenant, si tu essayes cela sans autre précaution, je pense que tu avoir une erreur à l'édition des liens, à propos de symboles non définis... parce que #inclure <stdlib.h>, ce n'est qu'un tout petit bout de l'iceberg.
Certainement, je vais donc eviter ;-)
Juste un tuyau: si «générateur de nombres pseudo-aléatoires» ne t'a pas donné de bons résultats dans tes exhaustives recherches, essaye donc l'équivalent anglais, "random". Google ne me donne que 1.200.000 pages (http://www.google.com/search?hl=xx-hacker&q=random+kernel+linux), il y a peut-être d'autres moteurs de recherche qui donnent de meilleurs résultats...
Oui j'avais deja exploré cette voie. En fait, il existe une implementation dans le noyau et accessible apr l'intermediaire de fichiers /dev/random et /dev/urandom. Mais la generation des sequences fait appel a des generateurs d'entropie qui sont alimentés par l'environnement (pilotes de peripheriques entre autres d'apres le man). Mais l'acces aux nombres ne se fait apparemment que par l'intermediaire de ces fichiers et ca ne correspond pas du tout a ce que je veux.
En revanche, j'ai trouvé la fonction suivante dans le bouquin de C de Kernighan et Ritchie :
unsigned long int gilb_random_next = 1;
/* rand: return pseudo-random integer on 0..32767 at least */ int gilb_rand(void) { gilb_random_next = gilb_random_next * 1103515245 + 12345; return (unsigned int)(gilb_random_next/65536) % 32768; }
/*srand: set seed for rand */ void gilb_srand(unsigned int seed) { gilb_random_next = seed; }
Je vais deja essayer avec ca. Maintenant ca compile bien, mais j'ai un probleme de symboles non resolus qui me tracasse d'autant plus que je ne comprends pas d'ou il vient.
-- Erwann
Antoine Leca wrote:
Maintenant, si tu essayes cela sans autre précaution, je pense que tu avoir
une erreur à l'édition des liens, à propos de symboles non définis... parce
que #inclure <stdlib.h>, ce n'est qu'un tout petit bout de l'iceberg.
Certainement, je vais donc eviter ;-)
Juste un tuyau: si «générateur de nombres pseudo-aléatoires» ne t'a pas
donné de bons résultats dans tes exhaustives recherches, essaye donc
l'équivalent anglais, "random". Google ne me donne que 1.200.000 pages
(http://www.google.com/search?hl=xx-hacker&q=random+kernel+linux), il y a
peut-être d'autres moteurs de recherche qui donnent de meilleurs
résultats...
Oui j'avais deja exploré cette voie. En fait, il existe une
implementation dans le noyau et accessible apr l'intermediaire de
fichiers /dev/random et /dev/urandom. Mais la generation des sequences
fait appel a des generateurs d'entropie qui sont alimentés par
l'environnement (pilotes de peripheriques entre autres d'apres le man).
Mais l'acces aux nombres ne se fait apparemment que par l'intermediaire
de ces fichiers et ca ne correspond pas du tout a ce que je veux.
En revanche, j'ai trouvé la fonction suivante dans le bouquin de C de
Kernighan et Ritchie :
unsigned long int gilb_random_next = 1;
/* rand: return pseudo-random integer on 0..32767 at least */
int gilb_rand(void)
{
gilb_random_next = gilb_random_next * 1103515245 + 12345;
return (unsigned int)(gilb_random_next/65536) % 32768;
}
/*srand: set seed for rand */
void gilb_srand(unsigned int seed)
{
gilb_random_next = seed;
}
Je vais deja essayer avec ca. Maintenant ca compile bien, mais j'ai un
probleme de symboles non resolus qui me tracasse d'autant plus que je ne
comprends pas d'ou il vient.
Maintenant, si tu essayes cela sans autre précaution, je pense que tu avoir une erreur à l'édition des liens, à propos de symboles non définis... parce que #inclure <stdlib.h>, ce n'est qu'un tout petit bout de l'iceberg.
Certainement, je vais donc eviter ;-)
Juste un tuyau: si «générateur de nombres pseudo-aléatoires» ne t'a pas donné de bons résultats dans tes exhaustives recherches, essaye donc l'équivalent anglais, "random". Google ne me donne que 1.200.000 pages (http://www.google.com/search?hl=xx-hacker&q=random+kernel+linux), il y a peut-être d'autres moteurs de recherche qui donnent de meilleurs résultats...
Oui j'avais deja exploré cette voie. En fait, il existe une implementation dans le noyau et accessible apr l'intermediaire de fichiers /dev/random et /dev/urandom. Mais la generation des sequences fait appel a des generateurs d'entropie qui sont alimentés par l'environnement (pilotes de peripheriques entre autres d'apres le man). Mais l'acces aux nombres ne se fait apparemment que par l'intermediaire de ces fichiers et ca ne correspond pas du tout a ce que je veux.
En revanche, j'ai trouvé la fonction suivante dans le bouquin de C de Kernighan et Ritchie :
unsigned long int gilb_random_next = 1;
/* rand: return pseudo-random integer on 0..32767 at least */ int gilb_rand(void) { gilb_random_next = gilb_random_next * 1103515245 + 12345; return (unsigned int)(gilb_random_next/65536) % 32768; }
/*srand: set seed for rand */ void gilb_srand(unsigned int seed) { gilb_random_next = seed; }
Je vais deja essayer avec ca. Maintenant ca compile bien, mais j'ai un probleme de symboles non resolus qui me tracasse d'autant plus que je ne comprends pas d'ou il vient.
-- Erwann
Antoine Leca
Changement de sujet pour éviter les remarques sur le HS (et pour intéresser plus de monde).
En news:d19le2$g25$, Erwann Thoraval va escriure:
Antoine Leca wrote: Oui j'avais deja exploré cette voie. En fait, il existe une implementation dans le noyau et accessible apr l'intermediaire de fichiers /dev/random et /dev/urandom. Mais la generation des sequences fait appel a des generateurs d'entropie qui sont alimentés par l'environnement (pilotes de peripheriques entre autres d'apres le man).
C'est sûr que cela impose une dépendance sur l'ordre d'initialisation.
Mais l'acces aux nombres ne se fait apparemment que par l'intermediaire de ces fichiers et ca ne correspond pas du tout a ce que je veux.
Je ne connais pas la programmation du noyau Linux, mais je serais surpris qu'il n'y ait aucun moyen d'y accéder depuis l'intérieur du noyau.
En ayant fouillé un peu pour écrire le reste du message, j'ai découvert un truc, http://lxr.linux.no/ident?i=get_random_bytes. Pas testé, évidemment.
En revanche, j'ai trouvé la fonction suivante dans le bouquin de C de Kernighan et Ritchie : gilb_random_next = gilb_random_next * 1103515245 + 12345;
C'est un grand classique en effet (en général, il ne faut pas aller cherche plus loin que le rand() de <stdlib.h>). Les propriétés spectrales sont une référence (c'est-à-dire que tout le monde se mesure par rapport à elles, et tout le monde se gausse de leur piètre qualité) mais c'est sûr que c'est facile à programmer et à exécuter.
Attention tout de même: la sûreté de ce générateur est nulle: n'importe quel petit malin est capable de te prévoir avec toutes les chances de succès le numéro suivant avec seulement deux numéros! Et comme en plus, il est archi-connu, c'est la première chose que l'on « teste ».
Dans BSD il y a une autre possibilité, random(), qui est beaucoup plus ambitieuse (src/lib/libc/stdlib/random.c) Mais si tu prend ce chemin-là, tu vas ajouter un maximum de code et de données à ton driver (problème si ton code est appelable sous interruption), et cela duplique complètement le propos du bidule déjà présent...
Antoine
Changement de sujet pour éviter les remarques sur le HS (et pour intéresser
plus de monde).
En news:d19le2$g25$1@amma.irisa.fr, Erwann Thoraval va escriure:
Antoine Leca wrote:
Oui j'avais deja exploré cette voie. En fait, il existe une
implementation dans le noyau et accessible apr l'intermediaire de
fichiers /dev/random et /dev/urandom. Mais la generation des
sequences fait appel a des generateurs d'entropie qui sont
alimentés par l'environnement (pilotes de peripheriques entre
autres d'apres le man).
C'est sûr que cela impose une dépendance sur l'ordre d'initialisation.
Mais l'acces aux nombres ne se fait apparemment que par
l'intermediaire de ces fichiers et ca ne correspond pas du
tout a ce que je veux.
Je ne connais pas la programmation du noyau Linux, mais je serais surpris
qu'il n'y ait aucun moyen d'y accéder depuis l'intérieur du noyau.
En ayant fouillé un peu pour écrire le reste du message, j'ai découvert un
truc, http://lxr.linux.no/ident?i=get_random_bytes. Pas testé, évidemment.
En revanche, j'ai trouvé la fonction suivante dans le bouquin de C
de Kernighan et Ritchie :
gilb_random_next = gilb_random_next * 1103515245 + 12345;
C'est un grand classique en effet (en général, il ne faut pas aller cherche
plus loin que le rand() de <stdlib.h>). Les propriétés spectrales sont une
référence (c'est-à-dire que tout le monde se mesure par rapport à elles, et
tout le monde se gausse de leur piètre qualité) mais c'est sûr que c'est
facile à programmer et à exécuter.
Attention tout de même: la sûreté de ce générateur est nulle: n'importe quel
petit malin est capable de te prévoir avec toutes les chances de succès le
numéro suivant avec seulement deux numéros! Et comme en plus, il est
archi-connu, c'est la première chose que l'on « teste ».
Dans BSD il y a une autre possibilité, random(), qui est beaucoup plus
ambitieuse (src/lib/libc/stdlib/random.c) Mais si tu prend ce chemin-là, tu
vas ajouter un maximum de code et de données à ton driver (problème si ton
code est appelable sous interruption), et cela duplique complètement le
propos du bidule déjà présent...
Changement de sujet pour éviter les remarques sur le HS (et pour intéresser plus de monde).
En news:d19le2$g25$, Erwann Thoraval va escriure:
Antoine Leca wrote: Oui j'avais deja exploré cette voie. En fait, il existe une implementation dans le noyau et accessible apr l'intermediaire de fichiers /dev/random et /dev/urandom. Mais la generation des sequences fait appel a des generateurs d'entropie qui sont alimentés par l'environnement (pilotes de peripheriques entre autres d'apres le man).
C'est sûr que cela impose une dépendance sur l'ordre d'initialisation.
Mais l'acces aux nombres ne se fait apparemment que par l'intermediaire de ces fichiers et ca ne correspond pas du tout a ce que je veux.
Je ne connais pas la programmation du noyau Linux, mais je serais surpris qu'il n'y ait aucun moyen d'y accéder depuis l'intérieur du noyau.
En ayant fouillé un peu pour écrire le reste du message, j'ai découvert un truc, http://lxr.linux.no/ident?i=get_random_bytes. Pas testé, évidemment.
En revanche, j'ai trouvé la fonction suivante dans le bouquin de C de Kernighan et Ritchie : gilb_random_next = gilb_random_next * 1103515245 + 12345;
C'est un grand classique en effet (en général, il ne faut pas aller cherche plus loin que le rand() de <stdlib.h>). Les propriétés spectrales sont une référence (c'est-à-dire que tout le monde se mesure par rapport à elles, et tout le monde se gausse de leur piètre qualité) mais c'est sûr que c'est facile à programmer et à exécuter.
Attention tout de même: la sûreté de ce générateur est nulle: n'importe quel petit malin est capable de te prévoir avec toutes les chances de succès le numéro suivant avec seulement deux numéros! Et comme en plus, il est archi-connu, c'est la première chose que l'on « teste ».
Dans BSD il y a une autre possibilité, random(), qui est beaucoup plus ambitieuse (src/lib/libc/stdlib/random.c) Mais si tu prend ce chemin-là, tu vas ajouter un maximum de code et de données à ton driver (problème si ton code est appelable sous interruption), et cela duplique complètement le propos du bidule déjà présent...
Antoine
Harpo
Erwann Thoraval wrote:
screetch wrote:
Maintenant je ne sais pas exactement ce que tu veux faire, peut etre as tu de bonnes raisons, mais ca me parait impossible.
En fait, c'est pour utiliser les fonctions drand48() et srand48() qui generent des nombres pseudo-aleatoires. Peut-etre existe-t-il des equivalents dans le noyau, mais je ne les connais pas.
Voir dans /usr/src/linux/include/linux/random.h La fonction get_random_bytes pourrait convenir (?), pour des exemples d'utilisation : # grep -r "get_random_bytes" /usr/src devrait en donner un certain nombre. le source dans /usr/src/drivers/char/ est bien documenté.
Sinon, il n'est pas possible d'utiliser la glibc et autres bibliothèques dans le noyau ou un module. La plupart des fonctions nécessaires sont implémentées dans le kernel : http://kernelnewbies.org/documents/kdoc/kernel-api/linuxkernelapi.html http://www.kernelhacking.org/ http://ffpf.sourceforge.net/other/kernelres.php
Have fun -- Patrick http://patrick.davalan.free.fr/
Erwann Thoraval wrote:
screetch wrote:
Maintenant je ne sais pas exactement ce que tu veux faire, peut etre
as tu de bonnes raisons, mais ca me parait impossible.
En fait, c'est pour utiliser les fonctions drand48() et srand48() qui
generent des nombres pseudo-aleatoires. Peut-etre existe-t-il des
equivalents dans le noyau, mais je ne les connais pas.
Voir dans /usr/src/linux/include/linux/random.h
La fonction get_random_bytes pourrait convenir (?), pour des exemples
d'utilisation :
# grep -r "get_random_bytes" /usr/src
devrait en donner un certain nombre.
le source dans /usr/src/drivers/char/ est bien documenté.
Sinon, il n'est pas possible d'utiliser la glibc et autres bibliothèques
dans le noyau ou un module. La plupart des fonctions nécessaires sont
implémentées dans le kernel :
http://kernelnewbies.org/documents/kdoc/kernel-api/linuxkernelapi.html
http://www.kernelhacking.org/
http://ffpf.sourceforge.net/other/kernelres.php
Have fun
--
Patrick
http://patrick.davalan.free.fr/
Maintenant je ne sais pas exactement ce que tu veux faire, peut etre as tu de bonnes raisons, mais ca me parait impossible.
En fait, c'est pour utiliser les fonctions drand48() et srand48() qui generent des nombres pseudo-aleatoires. Peut-etre existe-t-il des equivalents dans le noyau, mais je ne les connais pas.
Voir dans /usr/src/linux/include/linux/random.h La fonction get_random_bytes pourrait convenir (?), pour des exemples d'utilisation : # grep -r "get_random_bytes" /usr/src devrait en donner un certain nombre. le source dans /usr/src/drivers/char/ est bien documenté.
Sinon, il n'est pas possible d'utiliser la glibc et autres bibliothèques dans le noyau ou un module. La plupart des fonctions nécessaires sont implémentées dans le kernel : http://kernelnewbies.org/documents/kdoc/kernel-api/linuxkernelapi.html http://www.kernelhacking.org/ http://ffpf.sourceforge.net/other/kernelres.php
Have fun -- Patrick http://patrick.davalan.free.fr/
