Développement USB

[JeromeLS]

Bonjour à tous,
je suis nouveau sur ce forum, et j'aimerai vous demandé des conseils.
J'ai un code écrit en c, qui permet de dumper et de copier des fichiers images disquettes d'un format particulier .
Ce code a été développé sur une plateforme linux (compilateur gcc), utilisant des fonctions comme ioctl (gestion de périphérique).
Sur cette plateforme, le lecteur disquette le device est /dev/fd.
Ce qui permet d'attaqué ce périphérique comme un fichier.
Voila, maintenant, j'aimerai porté ce code sur mon mac (man mini Macos 10.4), mais mon lecteur disquette est un lecteur USB.
Comme je ne connais pas le développement hard sur Macos, je vous demande des conseils pour porter ce programme (langage, niveau d'écriture hard du code ...).
Comment procéde t'on pour développer un programme de ce style sur Macos.

Merci à vous.

Jerome

 

[tatouille]

Bonjour à tous,
je suis nouveau sur ce forum, et j'aimerai vous demandé des conseils.
J'ai un code écrit en c, qui permet de dumper et de copier des fichiers images disquettes d'un format particulier .
Ce code a été développé sur une plateforme linux (compilateur gcc), utilisant des fonctions comme ioctl (gestion de périphérique).
Sur cette plateforme, le lecteur disquette le device est /dev/fd.
Ce qui permet d'attaqué ce périphérique comme un fichier.
Voila, maintenant, j'aimerai porté ce code sur mon mac (man mini Macos 10.4), mais mon lecteur disquette est un lecteur USB.
Comme je ne connais pas le développement hard sur Macos, je vous demande des conseils pour porter ce programme (langage, niveau d'écriture hard du code ...).
Comment procéde t'on pour développer un programme de ce style sur Macos.

Merci à vous.

Jerome

KPI Kernel Programming Interface

il n'existe pas de physical device
http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/About/chapter_1_section_2.html#//apple_ref/doc/uid/TP30000905-CH204-TPXREF102
http://developer.apple.com/documentation/Darwin/Kernel-date.html#//apple_ref/doc/uid/TP30000440-TP30000422-TP30000532

tu as des exemples /Developer pour la class IOKIT USB

http://developer.apple.com/documentation/Darwin/Reference/KernelIOKitFramework/USB/

pour ioctl il existe quelques différences entre linux et bsd
voir le man

http://lists.apple.com/mailman/listinfo/darwin-drivers

:zen:

 

[JeromeLS]

Merci de m'avoir répondu .
Mais existe t'il un moyen simple d'attaquer le lecteur disquette en USB, oui dois je implementer moi -même cette gestion ?

 

[SuperCed]

Tu dois passer par IOKit.
Evite par contre le KPI, ici, tu n'es pas obligé et ça t'éviteras de développer dans l'environnement noyau de MacOS X.

IOKit au niveau applicatif devrait suffire et c'est beaucoup plus simple à débuguer.

Il y avait un exemple sur le site Apple, je crois que c'était IOUSBSimpleExample .
Il explique bien comment récupérer les flux USB.

Je me souviens pas de tout, et je ne connais pas toutes les évolutions actuelles, mais il y a quelques années, j'avais fait quelques drivers USB pour les modem ADSL sur MacOS X.

Par contre, oublie le code Linux bas niveau, ça n'a rien à voir.

 

[GrandGibus]

[Question CON]

Quand on branche un lecteur USB type clé, le volume n'est-il pas monté dans le file system ?

Du coup, je pensais naïvement qu'il suffisait d'accédère par le chemin du point de montage (/Volumes....)

[\Question CON]


Merci de soigner mon ignorance ignare en ce domaine ...

 

[ntx]

[Question CON]

Quand on branche un lecteur USB type clé, le volume n'est-il pas monté dans le file system ?

Du coup, je pensais naïvement qu'il suffisait d'accédère par le chemin du point de montage (/Volumes....)

[\Question CON]

Si : il apparaît dans /Volumes.

 

[tatouille]

Tu dois passer par IOKit.
Evite par contre le KPI, ici, tu n'es pas obligé et ça t'éviteras de développer dans l'environnement noyau de MacOS X.

IOKit au niveau applicatif devrait suffire et c'est beaucoup plus simple à débuguer.

Il y avait un exemple sur le site Apple, je crois que c'était IOUSBSimpleExample .
Il explique bien comment récupérer les flux USB.

Je me souviens pas de tout, et je ne connais pas toutes les évolutions actuelles, mais il y a quelques années, j'avais fait quelques drivers USB pour les modem ADSL sur MacOS X.

Par contre, oublie le code Linux bas niveau, ça n'a rien à voir.

le IOkit fait partie de se qu'on appel une kpi ...
il ne faut pas confondre certains discours d'Apple parfois un peu trop newbies ...

bon rien ne t'inderdit de lier un physical device et device virtuel
beaucoup de gens le font surtout pour gerer des applis en network qui voudrenait acceder
à ce dit device ( comme un client linux )

si tu commence de zero -> IOKIT et que tu veux etre seulement OSX
si tu projettes d'etre cross unix/platform regarde les nouvelles facilités du coter de
com.apple.kpi.bsd

http://libusb.sourceforge.net/

donc ds ton cas utilises cette espace pour faire un client IOkit
et je pense quelques aménagements

#ifdef __APPLE__ || __BSD__ ? ça depends de ce que tu veux

:zen:

 

[SuperCed]

le IOkit fait partie de se qu'on appel une kpi ...
il ne faut pas confondre certains discours d'Apple parfois un peu trop newbies ...

Pour moi, le KPI contient les API des applis tournant dans le noyau. IOKit possède une version tournant en effet dans le noyau, et une autre au niveau applicatif. Enfin, c'était comme ça il y a quelques années quand je faisais des drivers.
Je me plante peut-être un peu dans mon vocabulaire.

En fait, tout ça, c'était pour dire qu'on était pas obligé de faire un driver et de coder dans le noyau pour accéder aux devices USB.

 

[tatouille]

Pour moi, le KPI contient les API des applis tournant dans le noyau. IOKit possède une version tournant en effet dans le noyau, et une autre au niveau applicatif. Enfin, c'était comme ça il y a quelques années quand je faisais des drivers.
Je me plante peut-être un peu dans mon vocabulaire.

En fait, tout ça, c'était pour dire qu'on était pas obligé de faire un driver et de coder dans le noyau pour accéder aux devices USB.

En fait le IOKIT est un IO Device Model
moderne qui redefinie la couche de base (MACH/BSD IO DEVICE INTERFACE ) qui n'est pas tres pratique
déjà Apple est révolutionnaire car elle impose le cpp au niveau du bas system
plutot que "traditionnellement" le C

IOKIT est une interface pour faciliter le travail ;
mais il faut noter que celle-ci travail ds ton [Kernel Space] m^me si tu n'as pas à utiliser
explicitement les méthodes c'est le principe de l'interface te macher le travail
avec des bibliothèques normées pour accéder à certains standards ,
gérer les interruptions ecetera

une interface USB
une interface Ethernet

ecetera

tu n'as pas besoin de réécrire les commandes génériques ce
qui allège véritablement les devs juste à implémenter , si cela t'interresse l'équipe de DragonFlyBSD a lancé un projet similaire de IO Device Model afin de faciliter le travail des developpeurs de drivers

le IOKIT est une interface ouverte ? quid deviendra t'elle un model que l'on pourrait avoir sous tout type d'unix ? afin d'accroitre la portabilité du code driver , je pense que c'était le but recherché
afin de faciliter le travail des card makers et autres , quand je sors un driver pour Linux, freebsd ou pour OSX (de mon matériel ) je n'ai que faire de l'implementation du IOKit et mon code est portable , mais cela semble compromis ... à suivre (Apple est autant coupable que la communauté opensource qui se refuse à utiliser les frameworks opensource d'Apple pourtant très puissant ... )

:zen:

 

[Gallenza]

Le plus simple serait que OS X passe enfin sous noyau Linux.

 

[tatouille]

Le plus simple serait que OS X passe enfin sous noyau Linux.

Linux est sous GPL et pas lesser
XNU est très bien et est plus moderne
moins que L4 soite mais cela va venir

deplus il ya une impossibilité
technique à passer d'un KERNEL Modifié (hybride) à un kernel monolithique / semi modulaire

voir notions micro kernel IPC et avantages et
possibilités techniques ( que Darwin (et OSX) utilise à tous les niveaux )

à moins de voir la simplicité dans : réécrire
Mac OSX entièrement avec beaucoup moins d'options

et surtout ce n'est pas le propos de cette discussion
ici on parle de portabilité code driver entre différents NIX