Discussion :

[Mokhtar BEN MESSAOUD]

Bonjour

Est-il possible d'utiliser le module /proc pour communiquer entre deux process
cad => creer un module kernel qui gere les entrees dasn le repertoire /proc

et le premier module va ecrire des informatiosn dasn les differentes entreee et le deuxieme module va aller les lire

Comment cette methode peut etre comparee par rapport a l'utilisation de la memoire partagee?

Est-il necessaire d'utiliser des semaphores dans le module kernel pour gerer la concurrence d'acces? ou bien l ekernel gere bien la concurrence d'acces des entrees du repertoire /proc

Tout commentaire est le bienvenu

[Sve@r]

Bonjour

Est-il possible d'utiliser le module /proc pour communiquer entre deux process
cad => creer un module kernel qui gere les entrees dasn le repertoire /proc

et le premier module va ecrire des informatiosn dasn les differentes entreee et le deuxieme module va aller les lire

Ben c'est une bête communication via fichier. Un processus écrit un fichier et un autre va le lire. Que ce soit dans /proc ou ailleurs le principe ne change pas (sauf que /proc n'est pas fait pour ça)

Comment cette methode peut etre comparee par rapport a l'utilisation de la memoire partagee?

Ah ben entre des accès mémoires et des accès disques, à ton avis qui est le plus rapide ???

Est-il necessaire d'utiliser des semaphores dans le module kernel pour gerer la concurrence d'acces? ou bien l ekernel gere bien la concurrence d'acces des entrees du repertoire /proc

Le kernel ne gère que la concurrence d'accès sur les fichiers pipe. C'est d'ailleurs le principe des impressions => un processus "lpr" va écrire le fichier dans le pipe et un second processus "lpd" lit le pipe et l'envoie à l'imprimante. Et tant que l'un des deux n'a pas fini, l'autre est bloqué (ce qui évite le mélange de plusieurs fichiers dans l'imprimante). Donc pour tout autre pb de concurrence, tu peux utiliser les sémaphores ou les outils plus spécifiques comme lock() et flock()

[Mokhtar BEN MESSAOUD]

Ben c'est une bête communication via fichier. Un processus écrit un fichier et un autre va le lire. Que ce soit dans /proc ou ailleurs le principe ne change pas (sauf que /proc n'est pas fait pour ça)
Ah ben entre des accès mémoires et des accès disques, à ton avis qui est le plus rapide ???

Je suis pas d'accord les fichiers sous /proc ne sont pas des fichiers ordinaires sur le disque c'est plutot une interface avec les structures de données du noyau
http://man.developpez.com/man5/proc.5.php

[souviron34]

oui, mais inversement :

• c'est normalement réservé au système
  
  
• il faut que tu connaisses le pid (donc dynamique)...

Question :


Que veux-tu faire exactement ?

Il est TRES TRES rare d'avoir , en dehors du Kernel, BESOIN de ce genre de choses...

[Mokhtar BEN MESSAOUD]

il faut que tu connaisses le pid

pourquoi on a besoin de connaitre le pid

Que veux-tu faire exactement ?

J'ai besoin de recuperer des statistiques d'un module de communication a partir d'un GUI donc les deux solutions envisagees c'est utiliser la memoire partagee et verrouileer l'acces par semaphore
le probleme qui se pose c'est que l eprocess de communication doit attendre la liberation de la semaphore pour pouvoi ecrire ce qui deteriore les performances du process de communication
une autre soultion envisagee est de creer un module kernel qui n efait que lire et ecrire des entree sur /proc
le module de communication met a jour les parametres de statistiques sous /proc et le le GUI n'a qu'aller les recuperer de facon periodique mais je pense que meme dans cette solution on a besoin de verrouiller par semaphore

[souviron34]

pourquoi on a besoin de connaitre le pid

Dans le lien que tu as toi-même cité :

/proc est un pseudo-système de fichiers qui est utilisé comme interface avec les structures de données du noyau pour éviter d'avoir à interpréter /dev/kmem. La plupart des fichiers sont en lecture seule, mais quelques uns permettent la modification de variables du noyau.
La description suivante fournit un aperçu de la hiérarchie /proc.

[nombre]
Il existe un sous-répertoire pour chaque processus en cours. Le sous-répertoire prend comme nom le PID du processus. Chaque sous-répertoire contient les pseudo-fichiers et pseudo-répertoires suivants.

J'ai besoin de recuperer des statistiques d'un module de communication a partir d'un GUI donc les deux solutions envisagees c'est utiliser la memoire partagee et verrouileer l'acces par semaphore
le probleme qui se pose c'est que l eprocess de communication doit attendre la liberation de la semaphore pour pouvoi ecrire ce qui deteriore les performances du process de communication
une autre soultion envisagee est de creer un module kernel qui n efait que lire et ecrire des entree sur /proc
le module de communication met a jour les parametres de statistiques sous /proc et le le GUI n'a qu'aller les recuperer de facon periodique mais je pense que meme dans cette solution on a besoin de verrouiller par semaphore

pourquoi faire simple quand on peut faire compliqué

je ne vois pas ce qui t'empêche d'écrire dans un fichier normal, et de lire !!!

Mauvaise (très mauvaise) conception....

[alavoler]

le mieux c est l'utilisation des IPC


tu definis un channel unique et tu communiques directement (je crois que ca utilise un system de pipe donc de fichier)


c'est rapide et efficace pour des ptites donnée, apres si t'a besoin d'un truc plus chiader y a d-bus

[tamiel]

Ton module de communication ne peut pas tout simplement écrire de façon régulière les statistiques dans un fichier plat ?
On trouve par exemple pas mal de stats du noyau dans /proc, ces stats sont mis à jour au fur et à mesure et un simple "cat" permet de lire les données de ce fichier .

Donc au niveau de ton modulede communication, tu écris dans le fichier et tu flush.

Au niveau de la GUI tu lis ce fichier toutes les 5 secondes par exemple.

Du moment qu'avec la GUI tu ouvre le fichier en mode lecture seule ("r"), pas besoin de verrous .

[Mokhtar BEN MESSAOUD]

Ton module de communication ne peut pas tout simplement écrire de façon régulière les statistiques dans un fichier plat ?
On trouve par exemple pas mal de stats du noyau dans /proc, ces stats sont mis à jour au fur et à mesure et un simple "cat" permet de lire les données de ce fichier .

Au niveau de la GUI tu lis ce fichier toutes les 5 secondes par exemple.

Oui c'est ca la conception que je preconise
mais y-t-il un probleme d'acces concurrent aux entree stat qui seront defini sous /proc ou bien c'est le kernel qui gere ca