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 David Decotigny . En réponse au message Ouvrir une socket dans un module. Évalué à 4.
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" ;)