en premier je vais profiter de cette question pour savoir
s'il n'y a pas quelque part un groupe francophile pour poser des questions
sur la programmation de drivers
et ensuite la the question je n'arrive pas à introduire la bibliothèque
#include </usr/include/stdlib.h>
pour utiliser system("beep");
dans un driver en cours de fabrication
en gros et pour faire simple le but du jeu
faire une allocation dynamique du numéro majeur( cela fonctionne déjà)
pour ensuite créer le fichier qui va bien (cela ne fct pas encore )
et dans la foulée si vous savez comment je peux récupérer
le numéro majeur qd il y a eu une allocation dynamique je suis preneur
pour un driver bien sûr parce que pour l'instant
Zut, il utilise des fonctions obsolètes. Voir plutôt : http://lwn.net/Kernel/LDD3/ Chapitre 3.
merci je garde le lien sous la main
mais il parle encore de script avec mkmod pour la création du fichier spécial voir chapitre 6 remarque faite après un parcours à grands coups de ctrl f donc ne pas crier sur moi dans tous les cas merci
remy
http://tldp.org/LDP/lkmpg/2.6/html/index.html
regarder chardev.c
Zut, il utilise des fonctions obsolètes. Voir plutôt :
http://lwn.net/Kernel/LDD3/
Chapitre 3.
merci je garde le lien sous la main
mais il parle encore de script avec mkmod pour la création du fichier
spécial voir chapitre 6 remarque faite après un parcours à grands coups
de ctrl f donc ne pas crier sur moi
dans tous les cas merci
Zut, il utilise des fonctions obsolètes. Voir plutôt : http://lwn.net/Kernel/LDD3/ Chapitre 3.
merci je garde le lien sous la main
mais il parle encore de script avec mkmod pour la création du fichier spécial voir chapitre 6 remarque faite après un parcours à grands coups de ctrl f donc ne pas crier sur moi dans tous les cas merci
remy
remy
ah non chez moi cela passe la compilation sans erreur j'avais mis le code "litigieux "en commentaire dans
http://cjoint.com/data/fBkEZgllY6.htm
ah non chez moi cela passe la compilation sans erreur j'avais mis le code
"litigieux "en commentaire dans
ah non chez moi cela passe la compilation sans erreur j'avais mis le code "litigieux "en commentaire dans
http://cjoint.com/data/fBkEZgllY6.htm
Eric Levenez
Le 27/05/08 10:21, dans <g1gd78$ik8$, « remy » a écrit :
ah non chez moi cela passe la compilation sans erreur j'avais mis le code "litigieux "en commentaire
Ça ne passait pas chez toi vu qu'il y avait des warnings (c'était tes warnings que j'ai reportés, et pas les miens vu que je n'ai pas testé ton code). Et ce n'est pas parce qu'il n'y a pas d'erreurs que ça passe. Il peut y avoir des warnings affichés ou non. Cela dépend aussi de tes options de compilation.
Il faut ajouter "linux/devfs_fs_kernel" et peut-être d'autres includes.
là tu viens de mettre le doigt sur mon problème il ne trouve pas le fichier d'en tête c'est bizarre les retours d'erreurs de type
attention : implicit declaration of function «devfs_register_chrdev"
va falloir que je me remette au gout du jour
bon bref le même code met #include <linux/devfs_fs_kernel.h>
:~/Desktop/Mydriver$ make make -C /lib/modules/`uname -r`/build/ M=/home/remy/Desktop/Mydriver modules make[1]: entrant dans le répertoire « /usr/src/linux-headers-2.6.20-16-generic » CC [M] /home/remy/Desktop/Mydriver/mydriver.o /home/remy/Desktop/Mydriver/mydriver.c:9:35: erreur: linux/devfs_fs_kernel.h : Aucun fichier ou répertoire de ce type
Regarde dans tes options de compilation pour avoir le chemin vers les includes du noyau. Aucune idée si la façon dont tu compiles est la bonne ou non car je ne fais pas comme cela du tout.
je dois avoir un truc à la con bête comme chou mais quoi ?
Déjà tes options de compilation...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 27/05/08 10:21, dans <g1gd78$ik8$1@s1.news.oleane.net>, « remy »
<remy@fctpas.fr> a écrit :
ah non chez moi cela passe la compilation sans erreur j'avais mis le code
"litigieux "en commentaire
Ça ne passait pas chez toi vu qu'il y avait des warnings (c'était tes
warnings que j'ai reportés, et pas les miens vu que je n'ai pas testé ton
code). Et ce n'est pas parce qu'il n'y a pas d'erreurs que ça passe. Il peut
y avoir des warnings affichés ou non. Cela dépend aussi de tes options de
compilation.
Il faut ajouter "linux/devfs_fs_kernel" et peut-être d'autres includes.
là tu viens de mettre le doigt sur mon problème
il ne trouve pas le fichier d'en tête
c'est bizarre les retours d'erreurs de type
attention : implicit declaration of function «devfs_register_chrdev"
va falloir que je me remette au gout du jour
bon bref le même code met
#include <linux/devfs_fs_kernel.h>
remy@remy-desktop:~/Desktop/Mydriver$ make
make -C /lib/modules/`uname -r`/build/ M=/home/remy/Desktop/Mydriver modules
make[1]: entrant dans le répertoire «
/usr/src/linux-headers-2.6.20-16-generic »
CC [M] /home/remy/Desktop/Mydriver/mydriver.o
/home/remy/Desktop/Mydriver/mydriver.c:9:35: erreur:
linux/devfs_fs_kernel.h : Aucun fichier ou répertoire de ce type
Regarde dans tes options de compilation pour avoir le chemin vers les
includes du noyau. Aucune idée si la façon dont tu compiles est la bonne ou
non car je ne fais pas comme cela du tout.
Le 27/05/08 10:21, dans <g1gd78$ik8$, « remy » a écrit :
ah non chez moi cela passe la compilation sans erreur j'avais mis le code "litigieux "en commentaire
Ça ne passait pas chez toi vu qu'il y avait des warnings (c'était tes warnings que j'ai reportés, et pas les miens vu que je n'ai pas testé ton code). Et ce n'est pas parce qu'il n'y a pas d'erreurs que ça passe. Il peut y avoir des warnings affichés ou non. Cela dépend aussi de tes options de compilation.
Il faut ajouter "linux/devfs_fs_kernel" et peut-être d'autres includes.
là tu viens de mettre le doigt sur mon problème il ne trouve pas le fichier d'en tête c'est bizarre les retours d'erreurs de type
attention : implicit declaration of function «devfs_register_chrdev"
va falloir que je me remette au gout du jour
bon bref le même code met #include <linux/devfs_fs_kernel.h>
:~/Desktop/Mydriver$ make make -C /lib/modules/`uname -r`/build/ M=/home/remy/Desktop/Mydriver modules make[1]: entrant dans le répertoire « /usr/src/linux-headers-2.6.20-16-generic » CC [M] /home/remy/Desktop/Mydriver/mydriver.o /home/remy/Desktop/Mydriver/mydriver.c:9:35: erreur: linux/devfs_fs_kernel.h : Aucun fichier ou répertoire de ce type
Regarde dans tes options de compilation pour avoir le chemin vers les includes du noyau. Aucune idée si la façon dont tu compiles est la bonne ou non car je ne fais pas comme cela du tout.
je dois avoir un truc à la con bête comme chou mais quoi ?
Déjà tes options de compilation...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
remy
el.h : Aucun fichier ou répertoire de ce type
Regarde dans tes options de compilation pour avoir le chemin vers les includes du noyau. Aucune idée si la façon dont tu compiles est la bonne ou non car je ne fais pas comme cela du tout.
je n'ai pas le fichier qui va bien devfs_fs_kernel.h et il n'y a aucun fichier qui contient la chaîne "devfs_mk_cdev"
cela sans la macro qui a changé du tout au tout sinon tu es sous quelle version du noyau
et les options de compilation elles sont dans le makefile en gros par défaut
el.h : Aucun fichier ou répertoire de ce type
Regarde dans tes options de compilation pour avoir le chemin vers les
includes du noyau. Aucune idée si la façon dont tu compiles est la bonne ou
non car je ne fais pas comme cela du tout.
Regarde dans tes options de compilation pour avoir le chemin vers les includes du noyau. Aucune idée si la façon dont tu compiles est la bonne ou non car je ne fais pas comme cela du tout.
je n'ai pas le fichier qui va bien devfs_fs_kernel.h et il n'y a aucun fichier qui contient la chaîne "devfs_mk_cdev"
cela sans la macro qui a changé du tout au tout sinon tu es sous quelle version du noyau
et les options de compilation elles sont dans le makefile en gros par défaut
Eric Levenez
Le 27/05/08 14:08, dans <g1gqfs$pb0$, « remy » a écrit :
je pense que c'est pire que ça
:/usr$ find -name devfs_fs_kernel.h :/usr$
Ok. Je viens de vérifier. Encore un coup de Linus :-<
Cette fonction a disparu du noyau et les dizaines de drivers (56 sur ma version de Linux) qui utilisaient cette fonction dans les premières versions du noyau 2.6 ont dû être réécrit pour faire autrement.
C'est tout à fait typique de Linux : à chaque version, sous version, ou sous-sous version, un driver qui compilait, peut ne plus marcher ou ne plus compiler du tout. Linus trouve sera super car il ne veut pas d'API stables.
Maintenant il faut trouver comment faire la même chose qu'avant (à condition que Linus n'est pas aussi supprimé cette fonctionnalité tout simplement). Pour l'instant je ne vais pas chercher la réponse car je n'en ai pas besoin pour mon driver, mais il faudra bien que le fasse un jour ou l'autre.
Pour ton driver, je réitère mon conseil : demande sur un groupe dédié à Linux et pas sur ce NG dédié au C standard.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 27/05/08 14:08, dans <g1gqfs$pb0$1@s1.news.oleane.net>, « remy »
<remy@fctpas.fr> a écrit :
Ok. Je viens de vérifier. Encore un coup de Linus :-<
Cette fonction a disparu du noyau et les dizaines de drivers (56 sur ma
version de Linux) qui utilisaient cette fonction dans les premières versions
du noyau 2.6 ont dû être réécrit pour faire autrement.
C'est tout à fait typique de Linux : à chaque version, sous version, ou
sous-sous version, un driver qui compilait, peut ne plus marcher ou ne plus
compiler du tout. Linus trouve sera super car il ne veut pas d'API stables.
Maintenant il faut trouver comment faire la même chose qu'avant (à condition
que Linus n'est pas aussi supprimé cette fonctionnalité tout simplement).
Pour l'instant je ne vais pas chercher la réponse car je n'en ai pas besoin
pour mon driver, mais il faudra bien que le fasse un jour ou l'autre.
Pour ton driver, je réitère mon conseil : demande sur un groupe dédié à
Linux et pas sur ce NG dédié au C standard.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 27/05/08 14:08, dans <g1gqfs$pb0$, « remy » a écrit :
je pense que c'est pire que ça
:/usr$ find -name devfs_fs_kernel.h :/usr$
Ok. Je viens de vérifier. Encore un coup de Linus :-<
Cette fonction a disparu du noyau et les dizaines de drivers (56 sur ma version de Linux) qui utilisaient cette fonction dans les premières versions du noyau 2.6 ont dû être réécrit pour faire autrement.
C'est tout à fait typique de Linux : à chaque version, sous version, ou sous-sous version, un driver qui compilait, peut ne plus marcher ou ne plus compiler du tout. Linus trouve sera super car il ne veut pas d'API stables.
Maintenant il faut trouver comment faire la même chose qu'avant (à condition que Linus n'est pas aussi supprimé cette fonctionnalité tout simplement). Pour l'instant je ne vais pas chercher la réponse car je n'en ai pas besoin pour mon driver, mais il faudra bien que le fasse un jour ou l'autre.
Pour ton driver, je réitère mon conseil : demande sur un groupe dédié à Linux et pas sur ce NG dédié au C standard.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
remy
Le 27/05/08 14:08, dans <g1gqfs$pb0$, « remy »
je pense que c'est pire que ça
:/usr$ find -name devfs_fs_kernel.h :/usr$
Ok. Je viens de vérifier. Encore un coup de Linus :-<
Cette fonction a disparu du noyau et les dizaines de drivers (56 sur ma version de Linux) qui utilisaient cette fonction dans les premières versions du noyau 2.6 ont dû être réécrit pour faire autrement.
C'est tout à fait typique de Linux : à chaque version, sous version, ou sous-sous version, un driver qui compilait, peut ne plus marcher ou ne plus compiler du tout. Linus trouve sera super car il ne veut pas d'API stables.
Maintenant il faut trouver comment faire la même chose qu'avant (à condition que Linus n'est pas aussi supprimé cette fonctionnalité tout simplement). Pour l'instant je ne vais pas chercher la réponse car je n'en ai pas besoin pour mon driver, mais il faudra bien que le fasse un jour ou l'autre.
je teste la semaine prochaine j'ai pas trop le temps because boulot http://doc.ubuntu-fr.org/udev
Pour ton driver, je réitère mon conseil : demande sur un groupe dédié à Linux et pas sur ce NG dédié au C standard.
ok
Le 27/05/08 14:08, dans <g1gqfs$pb0$1@s1.news.oleane.net>, « remy »
Ok. Je viens de vérifier. Encore un coup de Linus :-<
Cette fonction a disparu du noyau et les dizaines de drivers (56 sur ma
version de Linux) qui utilisaient cette fonction dans les premières versions
du noyau 2.6 ont dû être réécrit pour faire autrement.
C'est tout à fait typique de Linux : à chaque version, sous version, ou
sous-sous version, un driver qui compilait, peut ne plus marcher ou ne plus
compiler du tout. Linus trouve sera super car il ne veut pas d'API stables.
Maintenant il faut trouver comment faire la même chose qu'avant (à condition
que Linus n'est pas aussi supprimé cette fonctionnalité tout simplement).
Pour l'instant je ne vais pas chercher la réponse car je n'en ai pas besoin
pour mon driver, mais il faudra bien que le fasse un jour ou l'autre.
je teste la semaine prochaine j'ai pas trop le temps because boulot
http://doc.ubuntu-fr.org/udev
Pour ton driver, je réitère mon conseil : demande sur un groupe dédié à
Linux et pas sur ce NG dédié au C standard.
Ok. Je viens de vérifier. Encore un coup de Linus :-<
Cette fonction a disparu du noyau et les dizaines de drivers (56 sur ma version de Linux) qui utilisaient cette fonction dans les premières versions du noyau 2.6 ont dû être réécrit pour faire autrement.
C'est tout à fait typique de Linux : à chaque version, sous version, ou sous-sous version, un driver qui compilait, peut ne plus marcher ou ne plus compiler du tout. Linus trouve sera super car il ne veut pas d'API stables.
Maintenant il faut trouver comment faire la même chose qu'avant (à condition que Linus n'est pas aussi supprimé cette fonctionnalité tout simplement). Pour l'instant je ne vais pas chercher la réponse car je n'en ai pas besoin pour mon driver, mais il faudra bien que le fasse un jour ou l'autre.
je teste la semaine prochaine j'ai pas trop le temps because boulot http://doc.ubuntu-fr.org/udev
Pour ton driver, je réitère mon conseil : demande sur un groupe dédié à Linux et pas sur ce NG dédié au C standard.
ok
remy
Le 27/05/08 14:08, dans <g1gqfs$pb0$, « remy »
je pense que c'est pire que ça
:/usr$ find -name devfs_fs_kernel.h :/usr$
Ok. Je viens de vérifier. Encore un coup de Linus :-<
Cette fonction a disparu du noyau et les dizaines de drivers (56 sur ma version de Linux) qui utilisaient cette fonction dans les premières versions du noyau 2.6 ont dû être réécrit pour faire autrement.
C'est tout à fait typique de Linux : à chaque version, sous version, ou sous-sous version, un driver qui compilait, peut ne plus marcher ou ne plus compiler du tout. Linus trouve sera super car il ne veut pas d'API stables.
vivement que quelques notions d'objets intégrent le noyau comme cela ils pourront faire tout se qu'ils veulent tout en gardant une certaine compatibilité ascendante }
Maintenant il faut trouver comment faire la même chose qu'avant (à condition que Linus n'est pas aussi supprimé cette fonctionnalité tout simplement). Pour l'instant je ne vais pas chercher la réponse car je n'en ai pas besoin pour mon driver, mais il faudra bien que le fasse un jour ou l'autre.
tout se que j'ai trouvé fait référence à l'usb si tu trouves quelque chose je suis preneur add email valide
rien vu sur http://kernelnewbies.org/Linux_2_6_20
Le 27/05/08 14:08, dans <g1gqfs$pb0$1@s1.news.oleane.net>, « remy »
Ok. Je viens de vérifier. Encore un coup de Linus :-<
Cette fonction a disparu du noyau et les dizaines de drivers (56 sur ma
version de Linux) qui utilisaient cette fonction dans les premières versions
du noyau 2.6 ont dû être réécrit pour faire autrement.
C'est tout à fait typique de Linux : à chaque version, sous version, ou
sous-sous version, un driver qui compilait, peut ne plus marcher ou ne plus
compiler du tout. Linus trouve sera super car il ne veut pas d'API stables.
vivement que quelques notions d'objets intégrent le noyau
comme cela ils pourront faire tout se qu'ils veulent tout en gardant
une certaine compatibilité ascendante
}
Maintenant il faut trouver comment faire la même chose qu'avant (à condition
que Linus n'est pas aussi supprimé cette fonctionnalité tout simplement).
Pour l'instant je ne vais pas chercher la réponse car je n'en ai pas besoin
pour mon driver, mais il faudra bien que le fasse un jour ou l'autre.
tout se que j'ai trouvé fait référence à l'usb
si tu trouves quelque chose je suis preneur
add email valide remy.aumeunier@libertysurf.fr
Ok. Je viens de vérifier. Encore un coup de Linus :-<
Cette fonction a disparu du noyau et les dizaines de drivers (56 sur ma version de Linux) qui utilisaient cette fonction dans les premières versions du noyau 2.6 ont dû être réécrit pour faire autrement.
C'est tout à fait typique de Linux : à chaque version, sous version, ou sous-sous version, un driver qui compilait, peut ne plus marcher ou ne plus compiler du tout. Linus trouve sera super car il ne veut pas d'API stables.
vivement que quelques notions d'objets intégrent le noyau comme cela ils pourront faire tout se qu'ils veulent tout en gardant une certaine compatibilité ascendante }
Maintenant il faut trouver comment faire la même chose qu'avant (à condition que Linus n'est pas aussi supprimé cette fonctionnalité tout simplement). Pour l'instant je ne vais pas chercher la réponse car je n'en ai pas besoin pour mon driver, mais il faudra bien que le fasse un jour ou l'autre.
tout se que j'ai trouvé fait référence à l'usb si tu trouves quelque chose je suis preneur add email valide
rien vu sur http://kernelnewbies.org/Linux_2_6_20
Eric Levenez
Le 28/05/08 16:50, dans <g1jobm$1bt$, « remy » a écrit :
vivement que quelques notions d'objets intégrent le noyau comme cela ils pourront faire tout se qu'ils veulent tout en gardant une certaine compatibilité ascendante
Ceci est en contradiction totale avec ce que veut Linus : "surtout ne pas avoir de compatibilité entre versions car cela bride l'évolutivité" (en substance). C'est bien sûr idiot, mais c'est comme cela hélas, et les programmeurs sur Linux en font les frais tous les jours.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 28/05/08 16:50, dans <g1jobm$1bt$1@s1.news.oleane.net>, « remy »
<remy@fctpas.fr> a écrit :
vivement que quelques notions d'objets intégrent le noyau
comme cela ils pourront faire tout se qu'ils veulent tout en gardant
une certaine compatibilité ascendante
Ceci est en contradiction totale avec ce que veut Linus : "surtout ne pas
avoir de compatibilité entre versions car cela bride l'évolutivité" (en
substance). C'est bien sûr idiot, mais c'est comme cela hélas, et les
programmeurs sur Linux en font les frais tous les jours.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 28/05/08 16:50, dans <g1jobm$1bt$, « remy » a écrit :
vivement que quelques notions d'objets intégrent le noyau comme cela ils pourront faire tout se qu'ils veulent tout en gardant une certaine compatibilité ascendante
Ceci est en contradiction totale avec ce que veut Linus : "surtout ne pas avoir de compatibilité entre versions car cela bride l'évolutivité" (en substance). C'est bien sûr idiot, mais c'est comme cela hélas, et les programmeurs sur Linux en font les frais tous les jours.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
