TheBreton a écrit 925 commentaires

Non helas c'est pas celui la.
Cet un putain de chipset graphique de merdre pour lequel aucun driver Xfree ne marche.
Pourquoi l'avoir pris alors ?
Pas le choix c'est le PC du boulot qui est un putain de Dell de merde sans slot AGP pour pouvoir mettre une carte graphique descente !
A moi les joie de la console !!!!grrrrr

Autant pour moi, il semble qu'il fallait upgrader en Xfree4.4 pour que cela marche.
J'essaie ca ce midi et poste le resultat.

Brutal attack :
Allez faire un tour dans le driver serial de ton kernel, intercepter par des printk (par exemple) les transfert recu/emis
une tite recompil du kernel
et hop, le tour est joué
c'est pour ca que l'acces au source de l'os est si jouissif !

mon ami google a dit :
http://libusb.sourceforge.net/(...)
mais /proc n'est qu'un des moyen de communiquer entre un driver et l'espace utilisateur.
les ioctl en sont un autre.
Mais je pense que tu reussisse a te passer de l'ecriture d'un driver pour gerer ton device, et dans ce cas la l'usb-sketlon (je sait plus ou est le H dans le mot) sera le point de depart obliger pour toi.
Tes EP gerent quoi ? de quel type sont il (bulk/inter/iso)?
de quel class est ton device ?(c'est quoi que tu gere?)

libsub existe en version 0.1 mais faut savoir ce que l'on veut faire.
libusb permet facilement , depuis l'espace user de relayer des requete USB c'est vrai,et c'est facile.
Mais un driver ne fait pas que ca !!
-quand on branche le device USB le driver devient actif (si charge par un insmod), avec libusb c'est quand tu demarre ton programme que tu parcours l'arbre usb pour trouver ton device.
-un driver dispose de toute l'attention du proc quand il en as besoin et des qu'un evenement surivent(callback completion sur les transfert), pas libusb
-tu recois tout les packet interrupt que ton device envoie des que disponible sans lattence, avec libusb c'est a toi de gere la lecture (et ce se ressent d'autant dans les performances).
bref j'arrete la mais la liste est longue.
libusb est un bel effort pour que tous les materiels usb fonctionne sous linux mais avec au depriment des performances (on peut pas tout avoir).

Oula dans quoi tu te lance ?
Pour la gestion d'un driver USB c'est tout simple !
(j'en ai deja fais quelques un)
je ne sait pas les caracterisque tes EP, mais si tu n'as que des transfert bulk a gere c'est meme deja tout fais, tu n'as cas allez voir dans les sources de ton kernel
/usr/src/linux/drivers/usb/usb-skeleton.c
ce driver intergre l'enumeration dans usbfs, le support devfs...
tout ce dont tu as besoin.
Si tu as des questions...

Le site c'est plutot : http://www.aideinfo.net(...) non ?

C'est largement mieux que les conneries habituel que l'on vois sur certaine chaine ou c'est des humains dans un role qui va tres bien au sangliers....

L'esprit du libre c'est justement de repandre au plus grand nombre les connaissances informatique.
Résultat, on devient de la compétence au kilo que les SSII vendent aux entreprises qui ont des besoins
rien en t'empeche si tu est jaloux de tes connaissance de faire de l'argent avec en expliquant jamais rien.
La GPL n'est pas imcompatible avec l'argument financier (faire de l'argent en vendant du logiciel), simplement elle impose que tu en distribue les sources.
Il reste cependant des niches comme la maintenance des grandes bases de données par ex. Ou le savoir s'acquierent encore par voie orale et au bon gré des personnes.

Rien ne vaut une bonne ampoule de 75W dans les yeux pour faire avouer un pierre tramo....

Moi je prefere tout faire en englais, comme je parle tres peut (et plutot mal) la langue j'ai tendance a faire simple dans les explications et du coup c'est plus facilement compris par mes collegues

En fait le message indique que le module nvidia n'as pas ete chargé.
Essaye de faire un
insmod /lib/modules/2.4.6/nvidia.o
puis relance X pour voir

Salut, normalement le dev d'un drivers est a la porte de tous.
Par contre un rapide (peut etre trop) tour sur le site d'amd ne m'as pas permis de trouver le datasheet (element indispensable de demarrage) et il faut peut etre signer un truc avec eux (nda) pour se lancer la dedans.
Le site de base pour demander si quelqu'un n'as pas deja fais la demarche de coder le drivers c'est de s'incrire sur la mailing liste kernel.org, de parcourir les archives puis si tu ne trouve pas de poser la question.
Perso je te conseille l'abonnement a la lettre condenser d'information car la list est vraiment tres vivante et tourne a 100 poste par jour.

Entierement d'accord, mieux vaut etre saoul que con...ca dure moins longtemps.

Trop gros comme poisson d'avril....tout le monde sait qu'un virus sous linux est toujours localisé entre la chaise et le clavier

Faut ouvrir ton fichier avec les attribut "+rb" pour dir que tu traite un fichier sous forme de flux binaire, ensuite tu lis octet par octet tu applique ton xor puis ecris le resultat dans un fichier destination de nom different. ensuite un appel system à rm et ensuite mv et ton fichier source a disparu pour etre remplace par ton fichier codé par un xor.
je suppose que c'est ca que tu cherche a faire ?

c'est de la faute au vodoo qui ont lancé une malédiction et tout ce qui s'apelle *indows est condamné a mentir ?

Quelques mot sur les modules pour te repondre de facon clair:
Le kernel est bati a partir d'element indispensable et d'autres facultatif.
Les elements indipensable ne sont pas demontable et n'apparaisse pas dans la liste des modules.
A coter de ca, les modules sont des bouts de programme qui fonctionne avec le kernel qui sont compilé une fois quand tu construit le kernel, puis linker statiquement (donc la fonction gerer par ce module est activée au demarrage) au kernel ou alors linker dynamiquement au kernel (insmod, modprobe et autre, la fonction qu'assume ce module ne fonctionne que quand elle est demandé par le root).
Helas, tout n'est pas aussi beau et certain programmeur n'on pas implementé la double interface avec le kernel et donc le module est obligatoirement static ou dynamique mais pas les deux.
La solutions retenue pour les distribs est un mixe....un kernel de grosse taille avec tous les modules compilés pour que des logiciels d'autodetection puisse chargé le module adéquat pour la gestion du materiel detecté, l'inconvenient est qu'il faut une bonne connaissance de toutes les cartes y compris exotique pour ne pas charger un module pour une mauvaise utilisation.
Autre inconvenient , deux modules qui rendent le meme service (interface sonore par exemple) non jamais ete ecris pour cohabiter avec un copains qui fais la meme chose donc cela pause de probleme.....
Bref la liste est longue pour expliquer l'etat des choses, je m'egare un peut.
-Pour resumer, la compilation a la volée, non le linkage a la volé oui,c'est deja fait.
-La detection d'un nouveau peripherique...besoin d'info des contructeurs qui n'en fournisse generalement pas...donc non.
-Choisir soit meme le bon module, le lier avec le kernel pour que la carte fonctionne..c'est deja fait (si tu as pris la precaution de contruire tout les modules du kernel en mode module lors de ta derniere compil)
Voila, j'espere avoir repondu a tes questions

C'est sur que pour s'aligner sur les prix d'un OS gratuit il faut vendre apascher...

je connais pas gethrtime mais sous un linux std la notion de temps nano n'existe pas (en dehors du tick de scheduler qui varie d'une machine a l'autre).
Par contre, sur des machines de type Pentium et ulterieur, il existe un registre 64bits qui depend de la frequence du coeur qui s'incremente tous les tick micros (donc toute les x nano), il est possible de le lire au niveau kernel avec les macros assembleurs qui vont bien (le registre s'apelle TSC et est lu par les macro du fichier /usr/src/linux/asm/msr.h )
Par contre, la valeur du TSC n'est pas transmis au user space a ma connaissance.
Il est possible facilement d'ecrire un module qui le ferait mais le temps entre la lecture du registre et la prise en compte de la valeur par l'appli est inconnu, donc le temps lu serait faux.
c'est pour ca que la fonction n'as pas ete porté sans doute.
Et c'est aussi pour ca que chaque fonction temps-reel ce fait au niveau kernel et non-userspace.
J'ai repondu rapidement et j'espere avoir fais assez simple
y a des questions ?

c'est surtout sur le fait que l'utilisation du C++ rajoute des lourdeurs en taille dans le code, l'inclusion de fonction d'allocation dynamique de mémoire (qui sont une horreur)...et plein d'autre chose joyeuse alors que on essaye par tous les moyens de reduire la taille du code (et donc aussi le temps d'execution globale)...
le travail a ete fait par jesaitpusqui et le kernel grossissait globalement de 20%.Le rajout des fonctionnalitée du C++ ne se justifiant pas cette idée a ete gelée.

Au pire (et apres 3 bouteilles de wiskey), est-il envisageable de developper soi-meme le driver ? J'ai programme pas mal d'applications de gestions en utilisant divers langages, mais je n'ai aucune idee des contraintes liees au dev d'un driver pour un tel materiel...

Bin un drivers c'est pas *si* difficile que ca as faire quand on connait bien le truc.
Par contre si tu ne connais pas du tout le composant, ni sa doc, ni la programmation kernel (qui ne peut se faire qu'en C)...tu auras tombé plus que 3 boutanche de whiskey avant que ca marche.
Perso je fais des drivers USB/PCI pour nos cartes et je te conseille le bouquin 'writing device drivers' d'alexandro rubini pour bien commencer. Le bouquin est au format PDF est telechargable gratuitement sur le sit o'reylli.
Sache toutefois qu'il traite les interfaces kernel->modules du kernel 2.4 et que ca as changé dans le 2.6, c'est pourquoi une grande partie des drivers ont du etre re-ecris......
Bref c'est une autre discution que tout ca, sache (cerise sur le gateau) que le dev d'un drivers se traduit souvent par pas mal de crash du kernel avec en prime corruption du disque dur local, donc je prefere utiliser une machine uniquement destiné a debugger les drivers plutot que ma machine principale....
si tu as des questions....

Deuxième problème majeur: Ma clé USB ne marche plus. Lorsque l'insère dans le port USB, ellle n'est même pas activé.

Par activée tu entend quoi ?
- L'automount ne fonctionne plus ?
- Impossible de faire un mount à la main ?
- Pas de détection de la clef au moyen d'un lsusb ?

je crois saisir mais sans etre sur, tu as des machines avec pas mal de process et tu te plaint de leur manque de reactivité quand tu bouge la souris par exemple ?
Tout est une question de compromis:
tes applis consomme le temps que l'on leur donne et s'execute en un certain temps.
Si tu veut que ton systeme donne moins de temps a tes applis pour en consommer plus a etre reactif c'est possible en modifiant le time-slice dans le scheduler ce qui donnera plus de tache execute en 1seconde mais avec moins de temps pour chaque tache.
Au resultat, un systeme peut reactif mais ou toute les taches s'execute en une heure peut se transformer en systeme hyper reactif toutes les taches s'execute en deux heures (c'est des exemples).
Si par contre tu travaille sur des parcs de machines, le principe est different, une machine qui fais l'interface avec l'humain et plusieurs machine ne sont que des centres de calcul (pas de carte graphic,ni clavier, ni souris donc pas de temps machine consommé pour leur gestions, juste un CPU, de la memoire, une carte reseau,un kernel light, un config minimal....en gros tu les utilises comme des CPU a qui tu envoie une suite de calcul et qui te renvoie la liste de resultat....

Ca depend quel est ton besoin de temps reel ?
mais des solutions existe.
Si c'est pour une lecture video plus fluide sur une petitg config , il n'y a rien a attendre.
Si tu as besoin d'une tache (ou plusieurs) bien precise avec des imperatif temps-reel regarde pour utiliser RTAI ou RTLinux qui sont des patchs systemes pour lequel Linux et ces appli sont des taches de moyenne importance et qui permette une communication par des pipe entre des taches temps reel et des taches linux.

un arping -a 00:C0:9f:0d:03:73 devrait fonctionner si ta version n'est pas trop vieille

http://freshmeat.net/projects/arping/?branch_id=385&release_id=(...)