Forum Linux.noyau comportement de select dans un module?

Posté par  .
Étiquettes : aucune
0
24
mar.
2006
Bonjour, bonjour,

Avant toute choses je viens de m'inscrire sur linuxfr, donc je ne sais pas si ma question est déjà traitée. Désolé si c'est le cas. (y a pas une fonction recherche des forums??)

Je suis en train d'écrire un pilote (c'est mon premier...) pour interpreter des trames GPS. J'ai déjà développé un programme executable au niveau userland qui réalise avec succès les traitements néscessaires, maintenant je souhaite adapter ce programme pour le faire tourner en tant que drivers au niveau noyau.

Comme mon prog est à l'écoute permanente du port RS232, j'utilise la fonction select() à l'interieur d'une boucle de lecture infinie. Select() suspend le processus en cours, et attend un evenement sur RS232. Quand des données se présentent mon processus est réveillé, une lecture est faite suivi des traitement, et je retourne au début de ma boucle infinie, et je reviens en attente sur Select()

Mais comment va se comporter select() en mode noyau? Si elle bloque le processus en cours, au niveau noyau est ce que cela pose problème? Est ce que cela risque de suspendre tout le noyau? ou d'en perturber son fonctionnement? Ou est ce que chaque module est vu par le noyau comme un "processus' indépendant?



Voili, voilou. Merci d'avance.

  • # Euh...

    Posté par  . Évalué à 2.

    Desole si je me trompe, mais je ne suis pas certain que select() existe en tant que tel en mode noyau.

    Il va surement falloir que ton driver demande a etre notifie d'une arrivee de donnee, en esperant que le pilote serie autorise se genre de demande depuis le kernel directement. En fait, je ne suis pas certain que ton driver ai sa place dans le noyau, puisqu'il s'agit plus d'un traitement de donne qu'un pilote hardware. Maintenant, je ne connais pas les tenants et les aboutissants de ton projet.

    • [^] # Re: Euh...

      Posté par  . Évalué à 1.

      ben non en effet je viens de me faire jeter par insmod.

      Je pensais qu'on pouvait acceder, aux fonctions userland en mode noyau? D'aillerus c'est quoi syscall??

      Je voudrais d'une part avoir mon application principale qui tourne en boucle pour gerer les interactions utilisateur, l'affichage sur ecran et quelques traitements annexes.
      Cette application à plusieurs sources de données totalement assychrones comme des trames en provenance d'un GPS via RS232.

      Mon idée était donc de développer un pseudo drivers, qui mette à disposition de mon application les trames GPS quand mon application en à besoin, c'est à dire quand elle vient elle même lire les données.

      Et comme le reste des sources de données proviennent de capteurs electroniques, j'aurai de toute facon besoin de développer d'autres drivers. Donc par souci de de cohérence, je voudrais un pseudo drivers (une surcouche du drivers RS232)

      • [^] # Re: Euh...

        Posté par  . Évalué à 2.

        syscall = Appel systeme

        Pour ce qui est de ton pseudo-driver, ca depend du nombre d'applications clientes. Si ca se limite a un seul client, tu peux avoir une application "userland" qui exporte les trames GPS a travers un tube nomme. En incluent le descripteur de ton tube nomme dans select, tu sais que ton client veut lire une trame lorsque le tube est accessible en ecriture.

      • [^] # Re: Euh...

        Posté par  . Évalué à 0.

        Je pensais qu'on pouvait acceder, aux fonctions userland en mode noyau?

        En programmation C, le noyau tourne dans une "freestanding implementation"(*), car il tourne directement au-dessus du matériel, et ne peut utiliser toutes les possibilités du langage C (une telle implémentation n'est pas obligée de fournir une grande partie de la bibliothèque standard, ni les types complexes). Un programme "normal", qui tourne au-dessus de l'OS est lui dans une hosted implementation, c'est-à-dire une implémentation complète du C (bibliothèque standard entière, et tout et tout).

        Ca, c'est pour le début. Ensuite, select() est défini par POSIX, qui fournit une extension au C. Pour celle-ci, la distinction freestanding/hosted est délibérément plus floue, ce qui fait que le noyau peut fournir un certain nombre de fonctions de POSIX, mais pas forcément toutes. Voici ce que dit POSIX.1, au paragraphehosted implementation ( http://www.opengroup.org/onlinepubs/009695399/nframe.html ) :
        Note that the line between a hosted implementation and a native implementation is blurred, since most implementations will provide some services directly from the kernel and others through some indirect path. (For example, fopen() might use open(); or mkfifo() might use mknod().) There is no necessary relationship between the type of implementation and its correctness, performance, and/or reliability.


        En bref, tu ne peux pas programmer un module noyau avec la doc POSIX sous les yeux, mais la doc du noyau elle-même...

        (*) Bon, peut-être pas strictement conforme, je n'en sais rien, et après tout on s'en fiche, un noyau c'est plein de trucs non-portables par définition, mais on va dire...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.