Linux - notification d'insertion disque

Linux - notification d'insertion disque - Codes et scripts - Linux et OS Alternatifs

Marsh Posté le 24-09-2010 à 21:01:04    

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  :jap:

Reply

Marsh Posté le 24-09-2010 à 21:01:04   

Reply

Marsh Posté le 24-09-2010 à 21:23:12    

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


Message édité par o'gure le 24-09-2010 à 21:28:17

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 24-09-2010 à 22:02:59    

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 :)

Reply

Marsh Posté le 24-09-2010 à 22:07:15    

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  [:axxan]


Message édité par o'gure le 24-09-2010 à 22:07:38

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 24-09-2010 à 22:22:56    

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).


---------------
Intermittent du GNU
Reply

Marsh Posté le 24-09-2010 à 22:31:18    

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...  [:zedlefou:1]


Message édité par o'gure le 24-09-2010 à 22:32:15

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 25-09-2010 à 07:57:36    

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  :jap:

Reply

Marsh Posté le 25-09-2010 à 09:17:24    

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)

Reply

Marsh Posté le 25-09-2010 à 09:20:06    

thana54 a écrit :

udev doit permettre ce que tu veux (j'ai quand même un doute pour le nommage 1,2,3...):


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.


---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 25-09-2010 à 09:21:29    

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.

Reply

Marsh Posté le 25-09-2010 à 09:21:29   

Reply

Marsh Posté le 26-09-2010 à 01:22:29    

xilebo a écrit :

un moteur graphique opengl multithread. Or , dans les versions récentes d'ubuntu, opengl ne fonctionne plus qu'en monothread


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

Reply

Marsh Posté le 26-09-2010 à 11:49:11    

404 Not Found a écrit :


 
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.

Reply

Marsh Posté le 26-09-2010 à 15:03:29    

xilebo a écrit :

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


 
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
 
(Désolé pour le HS :o )


Message édité par 404 Not Found le 26-09-2010 à 15:05:21
Reply

Marsh Posté le 27-09-2010 à 14:35:36    

Oh le méchant multiposte

Reply

Marsh Posté le 27-09-2010 à 16:07:56    

Taz a écrit :

Oh le méchant multiposte


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

Reply

Marsh Posté le 28-09-2010 à 15:21:46    

T'as testé GIO alors ?

Reply

Marsh Posté le 29-09-2010 à 08:38:15    

Taz a écrit :

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.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed