Forum Linux.noyau Ouvrir une socket dans un module

Posté par  .
Étiquettes : aucune
0
17
nov.
2006
Salut,
Je souhaite ouvrir une socket cliente pour me connecter sur une machine distante.
En mode user, ouvrir une socket qui se connecte à un serveur, il n'y a aucun problème....Mais dans un module Noyau, les foncions traditionnels (socket, connect, close, write et inet_aton) ne sont pas connues...

Les messages d'erreurs que j'ai lorsque j'essais de charger le module sont les suivant :
unresolved symbol socket
unresolved symbol connect
unresolved symbol close
etc...

voici mes includes :

#include <linux/module.h>
#include <asm/uaccess.h>
#include <asm-i386/io.h>
#include <linux/fs.h>
#iunclude <linux/socket.h>
#include <linux/in.h>


je me casse les dents dessus depuis ce matin....

Quelqu'un a déjà t il utilisé les sockets dans un module?

  • # mettre ça en userland ?

    Posté par  (site web personnel) . Évalué à 2.

    À mon avis, tu ferais mieux de faire cette partie réseau en userland avec une interface vers ton module noyau qui ferait le minimum.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: mettre ça en userland ?

      Posté par  . Évalué à 1.

      Et non je ne peux pas le faire en mode user, car je dois faire un driver...la couche TCP/IP devra être transparente car je ne connais pas le programme qui viendra se connecter sur mon device.

      • [^] # Re: mettre ça en userland ?

        Posté par  (site web personnel) . Évalué à 4.

        Je vais surement dire une betise puisque je ne connais pas ton projet. Et en plus je vais repeter ce qui vient d'etre dit. Bref, ce message est nul et sans interet mais mes petits doigts sont en verve ce matin.

        Normalement un driver se contente de... piloter un peripherique, c'est-a-dire le rendre accessible aux applis. Si, en plus de piloter le periph, il doit dialoguer avec les applis via le reseau, c'est plus un "driver", ca devient une appli. Pourquoi dans ce cas ne pas avoir une hierarchie :
        periph <--> driver | /dev/machin | appli de controle <--> reseau
        C'est certainement moins efficace que periph <---> driver <---> reseau, mais c'est plus elegant et plus "evolutif" (maintennable). Et sans doute aussi plus resistant aux bugs.

        A une epoque ou la tendance est d'externaliser le maximum de choses en userland (udev, hibernate, libusb et fuse bien sur), ton idee n'est plus tres "hype" ;)

        • [^] # Re: mettre ça en userland ?

          Posté par  . Évalué à 1.

          Bon......j'explique :

          J'ai un appareil (maison) qui a plusieurs port série et qui se pilote en TCP/IP.
          Un utilisateur quelconque doit pourvoir acceder aux ports série de cet appareil comme s'ils étaient dans le PC....donc la couche TCP/IP doit être transparente et donc elle doit être dans le module et non à Userland.

          le pilotage du périphéique se fera obligatoirement par le réseau, donc dans le module.

          merci.

          • [^] # Re: mettre ça en userland ?

            Posté par  (site web personnel) . Évalué à 1.

            Regarde le code du client NFS, il sait manipuler des sockets UDP et TCP.

            Toutefois, vu qu'il n'y a pas de pb de perfs, ça vaudrait effectivement le coup
            de voir à passer ce code en userland avec des redirections d'ioctl. Il y avait
            un driver qui faisait exactement ça dans le temps, ça s'appelait des ports
            série virtuels. Je crois que le plus emmerdant à traiter était la gestion des TTY.

            willy

  • # #include <net/sock.h>

    Posté par  . Évalué à 1.

    C'est par là que ça se passe...

Suivre le flux des commentaires

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