Voila, j'aimerai vos avis du coup, quand et pourquoi implementer des pilotes,
Concevoir puis implémenter des pilotes de périphériques est en soi une chose assez stimulante. C'est aussi une bonne occasion de plonger dans le code de bas niveau, voire carrément la programmation noyau et, en plus, les objectifs à atteindre sont relativement bien délimités : il s'agit en gros d'honorer une API (généralement déjà existante) dans sa totalité, pour permettre ensuite à des applications non spécifiquement écrites pour de pouvoir exploiter ton matériel à travers lesdits pilotes.
La première question est donc : qu'est-ce que tu pilotes, fût-ce via une liaison RS/232 ou 485 ? Il y des chances pour que ce soit en atelier, donc peut-être des machines outils... Et là encore, ça n'a d'intérêt que si ton pilote permet d'adapter l'utilisation du matériel à quelque chose de générique, ou à la limite à un niveau d'utilisation simplifié. Ça peut être intéressant également si tu as une grande gamme de matériels différents mais censés être, in fine, exploités de la même façon par l'utilisateur.
Par contre, si tu exploites du matériel spécifique dans un seul cas d'utilisation avec un logiciel dédié exclusivement, ça ne sert à rien d'intercaler un pilote entre les deux.
et user-space ou kernel-space?
À priori user space quand même, surtout si c'est au travers d'une liaison RS/232 qui, elle, est déjà bien prise en charge par le kernel. Non seulement la programmation peut être un cauchemar à déboguer (si ton pilote plante, c'est tout le système qui s'écrase. Ça ne se finira pas en simple segfault...) mais en plus, il faudra faire des appels internes pour aller revendiquer temporairement l'interface qui est faite pour être appelée via des appels système utilisateur normaux. Ça compliquerait un développement qui est censé être facilité quand il fait en user space.
# Pour quelles applications ?
Posté par Obsidian . En réponse au message quand et pourquoi implementer un pilote?. Évalué à 9.
Salut,
Concevoir puis implémenter des pilotes de périphériques est en soi une chose assez stimulante. C'est aussi une bonne occasion de plonger dans le code de bas niveau, voire carrément la programmation noyau et, en plus, les objectifs à atteindre sont relativement bien délimités : il s'agit en gros d'honorer une API (généralement déjà existante) dans sa totalité, pour permettre ensuite à des applications non spécifiquement écrites pour de pouvoir exploiter ton matériel à travers lesdits pilotes.
La première question est donc : qu'est-ce que tu pilotes, fût-ce via une liaison RS/232 ou 485 ? Il y des chances pour que ce soit en atelier, donc peut-être des machines outils... Et là encore, ça n'a d'intérêt que si ton pilote permet d'adapter l'utilisation du matériel à quelque chose de générique, ou à la limite à un niveau d'utilisation simplifié. Ça peut être intéressant également si tu as une grande gamme de matériels différents mais censés être, in fine, exploités de la même façon par l'utilisateur.
Par contre, si tu exploites du matériel spécifique dans un seul cas d'utilisation avec un logiciel dédié exclusivement, ça ne sert à rien d'intercaler un pilote entre les deux.
À priori user space quand même, surtout si c'est au travers d'une liaison RS/232 qui, elle, est déjà bien prise en charge par le kernel. Non seulement la programmation peut être un cauchemar à déboguer (si ton pilote plante, c'est tout le système qui s'écrase. Ça ne se finira pas en simple segfault...) mais en plus, il faudra faire des appels internes pour aller revendiquer temporairement l'interface qui est faite pour être appelée via des appels système utilisateur normaux. Ça compliquerait un développement qui est censé être facilité quand il fait en user space.