Bonsoir,
 
J'ai déjà posé ma question dans la section Programmation-C mais je viens la poser également ici car je crains que la réponse à mon problème ne soit pas que C.
 
Je souhaite effectuer la détection de l'insertion d'un disque dans un ( ou plusieurs) lecteurs , et également détecter l'éjection de ce même disque.
 
Il faudrait pour cela que je puisse récupérer par je ne sais quel moyen des notifications ( sous forme d'événement ou autre) qui me permettrait d'appeler des callbacks.
 
Seulement, je n'ai pas trouvé suffisamment de documentation sur internet me permettant d'effectuer ce que je souhaite.
 
J'ai trouvé la bibliothèque inotify qui me permet de récupérer des événements sur l'état d'un fichier ( ouverture, modification, déplacement , suppression etc ...) mais je ne sais pas si je peux appliquer cette règle à un fichier de périphérique.
 
Par exemple, je pourrais configurer udev pour lui indiquer de me créer un noeud de périphérique bien précis à l'insertion d'un disque, et de me le supprimer à l'éjection. Puis je fais un monitoring avec inotify sur ce fichier de périphérique, et sa présence ou non m'indiquerait que le disque est présent ou non.
 
Peut-on faire ça avec udev ?
 
J'aimerais faire également la différence entre l'insertion d'un disque dans un lecteur existant, et également l'insertion d'un nouveau lecteur (généralement usb)
 
Enfin,est-il possible de fixer une règle qui va me nommer mes disques détectés dans l'ordre d'apparition, par exemple /dev/dvd1 , /dev/dvd2 etc ... ou bien une règle qui va me mettre toujours le même numéro en fonction du lecteur physique dans lequel le disque est inséré ( l'une et l'autre sont contradictoire, je choisirai celle qui sera la plus appropriée à mon projet ).
 
 
Avez-vous des pistes ou de la littérature à me conseiller, car je ne vois vraiment pas comment m'y prendre ( je n'ai pas encore la possibilité de me créer une maquette pour faire des tests, je commence déjà par récolter des informations pour évaluer la faisabilité).
 
Merci d'avance  

Un début serait de commencer par regarder du côté udev, hal et d-bus ainsi que gnome-volume-manager par exemple
http://www.unixgarden.com/index.ph [...] s-gnulinux
http://git.gnome.org/browse/gnome-volume-manager

Très intéressant, j'ai commencé à lire les sources de gnome volume manager, ça ressemble à ce que je voudrais faire.
 
Mais je n'ai pas tout compris pour le moment, surtout le fonctionnement entre HAL , UDEV, D-BUS , et automount et lequel me servirait à quoi.
 
Je sens que je vais rencontrer des difficultés car :
 
 - je serai sur un système linux sur lequel il n'y aura qu'Xorg . le window manager est désinstallé je ne pourrai donc pas bénéficier de tout ce qu'il peut proposer.
 - je ne sais pas encore si le système sur lequel mon application tournera, aura les services HAL , D-BUS , UDEV etc ... correctement configurés.
 - j'ai vu dans les sources de gnome volume manager qu'il y a une partie qui utilise automount. J'ai peur que cela rentre en conflit avec l'application que je souhaite faire, car j'aimerai controler le mount seulement quand je l'aurai décidé et non pas sur tous les volumes.
 
Je vais commencer par écrire une application basique faisant appel à des bouts de code venant de gnome manager, il faudrait que j'essaie ça sur un système dont je suis sur du fonctionnement. Mandriva 2010 pourrait convenir par exemple ?  
 
Merci en tout cas pour les liens

N'importe quelle distribution récente dispose de ces trucs.

Après si je m'exprime sur Mandriva je vais me faire sanctionner par la modération  

Il me parait a moi inutile d'étudier Hal plus avant étant donné que ce dernier va être supprimé sous peu (sauf sous debian, mais c'est normal ils ont généralement 5 ans de retard).

Certes, j'avais pensé à le préciser mais c'est en haut de la première page que l'on trouve sur hal.
 
Sinon pour Mandriva... vu l'état actuelle de la distribution et surtout du contexte autour. Je ne pense pas utile de baser ses réflexions dessus. Autant prendre une distribution qui a été un minimum éprouvée et qui ne risque pas de disparaitre suite à une faillite/un rachat ou autre...  

je n'ai pas spécialement de préférence pour mandriva, mais l'application que l'on a écrite est basé sur un moteur graphique opengl multithread. Or , dans les versions récentes d'ubuntu, opengl ne fonctionne plus qu'en monothread , et pas sur mandriva. C'est donc un point bloquant que je ne sais pas résoudre pour le moment ( il n'est pas envisageable de réécrire le moteur graphique pour le moment même si c'est prévu). Les autres distributions, je ne les connais pas assez
 
 
Je prends note de vos remarques concernant HAL  

udev doit permettre ce que tu veux (j'ai quand même un doute pour le nommage 1,2,3...):
http://wiki.archlinux.org/index.php/Udev
http://www.reactivated.net/writing_udev_rules.html (même si ca semble ancien, ca comprend la logique pour utiliser udev)

Il te suffit de  configurer une règle udev qui fait appelle à un script externe. Ce script listerait les périphs existant et récupèrerait le dernier indice. Il suffirait de l'incrémenter.
J'ai vu un tel script passer il n'y a pas longtemps.
 
Pour peu, ça serait même le comportement par défaut.

Oui en passant par un script appelé par udev, mais je ne sais pas si c'est faisable directement dans la règle en elle même.

 
Tu peux préciser ?
Il y a plusieurs contextes ?  
Un seul contexte passé d'un thread à l'autre à coup de glXMakeCurrent() ?

 
 
Je ne suis pas la personne qui a écrit le moteur graphique, je ne pourrai donc pas expliquer avec précision ce qui ne fonctionne pas.  
 
Cependant, je peux au moins dire qu'il m'a expliqué que certains appels ne sont pas pris en compte parce qu'ils ne sont pas appelé à partir du même thread avec lequel on a initialisé opengl. La conséquence est que notre programme tourne bien sur les vieilles versions d'ubuntu , et la dernière mandriva, par contre sur les ubuntus version 9.04 et plus , on a un écran noir.
 
De plus, c'est apparemment détaillé clairement dans la doc d'opengl, j'essaierai de retrouver le lien lundi quand je retournerai au boulot.

 
OpenGL n'est pas thread-safe. Le seul moyen d'appeler des fonctions depuis un autre thread est de changer le "contexte de rendu" de thread. Cela impose de verrouiller l'accès à l'aide d'un mutex par exemple, ce qui empêche la parallélisation du code (pas possible d'avoir un thread de rendu et un même temps un deuxième thread qui charge des textures dans la mémoire graphique par exemple).  
 
Si la personne qui a écrit le moteur graphique a trouvé une parade, je suis très intéressé
 
(Désolé pour le HS )

Oh le méchant multiposte

 
 
Je l'ai précisé dans les 2 topics, j'ai pas pris les gens en traitre  

T'as testé GIO alors ?

 
 
Salut non pas encore car je travaille sur un sujet plus urgent. Je mets cependant l'info de coté, et je viendrai en reparler lorsque j'attaquerai le sujet.