David Decotigny a écrit 103 commentaires

Apparemment il y a erreur. C'est bizarre, d'apres ta photo d'ecran, il a l'air d'etre pris en charge, et donc d'apres cette photo tu es au bout de tes peines.

Essaye un 'fdisk -l /dev/sda' en tant que root dans une console (ou 'sudo fdisk -l /dev/sda' en tant que toi). S'il t'affiche une liste de partitions, tu essayes de les monter, ou tu repartitionnes le disque (il y a des machins graphiques qui font ca mais je les connais pas). Si pas possible (DD pas formate ?), alors repartitionne/reformate le disque (idem : il y a des choses graphiques).

Avec ncurses, y'a ca dans la doc :
http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/init.html#RA(...)
Et avec la libc de base, cf info libc :
http://www.gnu.org/software/libc/manual/html_node/Canonical-(...)

http://www.math.union.edu/~dpvc/jsMath/welcome.html

Il y en a tellement maintenant, le problème n'est plus de savoir "comment faire ?", mais "lequel choisir ?".

Je ne sais pas exactement pourquoi tu veux acceder a /dev/mem. En general on survit tres bien en s'en abstenant. Je ne sais pas non plus a quel niveau se produit ton erreur (ouverture ? lecture des le debut ? lecture au-dela du premier mega ?). En tous les cas, en 2.6 sur x86_32, tu vas difficielement pouvoir depasser le 1er mega de RAM (les autres acces hors ram sont permis, si ils ont un sens bien sur). Extrait de arch/i386/mm/init.c :

/*
 * devmem_is_allowed() checks to see if /dev/mem access to a certain address is
 * valid. The argument is a physical page number.
 *
 *
 * On x86, access has to be given to the first megabyte of ram because that area
 * contains bios code and data regions used by X and dosemu and similar apps.
 * Access has to be given to non-kernel-ram areas as well, these contain the PCI
 * mmio resources as well as potential bios/acpi data regions.
 */
int devmem_is_allowed(unsigned long pagenr)
{
   if (pagenr <= 256)
       return 1;
   if (!page_is_ram(pagenr))
       return 1;
   return 0;
}

On dirait que c'est une limitation propre au x86 (32 et 64), sur les autres archi, visiblement pas de limitation. Mais, encore une fois, je me demande bien a quoi ca peut te servir. A mon sens, /dev/mem ne devrait pas exister autrement qu'"a but educatif".

Non non, pas du tout. Si /dev/hda1, /dev/hda2, /dev/ttyS0, /dev/pts/1, /dev/pts/2, etc. existent avec des numeros differents, c'est pas parce qu'ils peuvent être utilisés par plusieurs applications, c'est parce qu'il s'agit de plusieurs peripheriques differents (/devhda1 c'est le periph "partition 1 du disque IDE0 primaire", /dev/hda2 le periph "partoche 2", /dev/pts/1 le periph "terminal virtuel 1", etc.).

Dans l'absolu, tout peripherique doit pouvoir etre ouvert et utilisé par plusieurs applications en meme temps. Si certains drivers (ie ce qui est derriere les /dev/machin) ne permettent pas cela, ce n'est /que/ parce que le *driver* ne le permet pas, pas parce que le systeme "en general" ne le permet pas. Par exemple, plusieurs applis peuvent ouvrir /dev/hda1 en meme temps si elles le veulent, et meme ecrire "en meme temps" (il y aura en fait sans doute une serialisation par le noyau, on a rarement vu un HD traiter plusieurs requetes venant du meme systeme en parallele). Il fut un temps ou, effectivement, certains periph tels /dev/audio, ne pouvaient pas etre ouverts par plusieurs applis en meme temps. Il y en a d'autres (je pense aux /dev/ttySX, a verifier). Mais c'est loin d'etre une generalite.

Et, comme suggere, le LDD est une excellente source pour comprendre comment une telle magie est possible. Une autre source (pub) : http://sos.enix.org .

Normalement il suffit de rajouter les résolutions qui vont bien dans le xorg.conf. Par exemple, chez moi j'ai :

        SubSection "Display"
                Depth           24
                Modes           "1920x1200" "1440x900" "1024x768" "800x600" "640x480"
        EndSubSection

Pour que la carte sache comment generer ces resolutions, j'uitilise 915resolution qui s'occupe de (presque) tout. Eventuellement, pour forcer la sortie sur l'ecran externe, on peut utiliser une ligne du genre : Option "MonitorLayout" "DFP,NONE" (sortie DVI, man i810 pour le reste) dans la section "Device".

J'ai le même problème, problème que je n'avais pas avec une airport de base d'un ibook de base. La solution que j'ai adoptée est de préciser un essid avant de lancer le client dhcp. Et ça marche, ce message en est la preuve.

Comme j'en avais marre d'utiliser iwlist puis de modifier /etc/network/interfaces (j'ai installé une u****u et je n'utilise la Scientific Linux qu'en chroot) à chaque fois, j'utilise un wifi-radar modifié pour que ça marche. Si ça t'intéresse, que mon patch n'a pas été intégré et que ça marche pas chez toi, fais-moi signe.

J'en connais qui utilisent Mercurial ("hg" pour les intimes), il paraît que c'est très bien. En tout cas il vient avec cet outil très sexy qui permet de visualiser les branches ("hgk" je crois) et qui devrait suffire a décider n'importe quel décideur. M'enfin perso j'ai jamais testé hg.

Il y a aussi TLA (GNU arch). Lui non plus, jamais testé.

Ce serait pas un "addr" (avec deux 'd', comme dans "d2") dans ton awk, plutot que "adr" ? Bref, un classique probleme de locale (tu es en locale "FR", mais ton script est execute en locale "C").

Ah oui, très juste, je l'avais corrigée celle-là mais j'avais oublié d'en causer.

Juste pour pinailler : dans le "write(0, ...)" que tu proposes, il y a une erreur. Un indice : grep STDOUT_FILENO /usr/include/unistd.h

> attention, ca fait 2 ans que j'ai plus fait de C, et j'ai jamais été vraiment bon

Ca s'est vu ;)

ça ressemble tellement a un exo que je vais pas donner la solution que j'ai sous les yeux. Juste un début de correction à la place.

Premier problème : il y a un ';' en trop.

Deuxième problème, il est liè à la condition du "while" : tu utilises la virgule. Mais la virgule, ce n'est jamais qu'un opérateur de séquence, et la valeur de la séquence (c'est ce qui nous intéresse principalement pour ton problème) correspond à la valeur du dernier élément de la séquence : ici c'est "!NULL". Bref, ton while ne termine jamais, comme tu as pu le voir. Faire la négation, comme suggéré, n'est pas la bonne solution... le corps du while ne sera plus jamais exécuté, c'est tout. Bref, un indice quand même : on peut écrire la condition du while sans utiliser la virgule. Autre indice : man read.

Troisième problème, tu pourras éviter d'afficher le contenu du binaire, ça fera moins mal au terminal. Indice : regarde ta boucle for et la définition de argc/argv dans un bouquin.

Quatrième problème : si on te demande d'éviter les fputs & co, alors "printf" fait aussi partie du lot (surtout que ce que tu affiches n'est pas ce qui est demandé). Indice : trouver une fonction comme "read" mais qui écrit au lieu de lire... je te préviens, c'est pas évident.

Du pinaillage : éviter les appels intempestifs à "exit", surtout quand on est dans le "main". Autre pinaillage : plutôt que d'écrire "1024" en dur dans le read, essaye de faire un truc genre : une macro qui vaut 1024 et qui est utilisée à la fois dans la def du tampon et dans le write, et/ou utilise sizeof() dans la read.

Oui, on peut meme utiliser ca pour faire un peu de reflexivite, par exemple avec SEAL/Reflex (http://seal-reflex.web.cern.ch/seal-reflex/index.html ).

Une autre solution est de partir du code compile, ou plus precisement des infos de debuggage. Il y a enoooooormement d'infos qui sont generees pour le debuggage, on l'oublie souvent. Sous Unix, il y a par exemple libdwarf qui permet d'y avoir acces relativement simplement (http://reality.sgiweb.org/davea/dwarf.html ). L'avantage, c'est qu'on est assure (modulo bugs) que ces infos sont exactes, puisque c'est le compilo qui les genere a la compilation. Alors qu'avec des outils comme gccxml, les infos sont generes par /un/ gcc, certes, mais c'est parfois difficile de faire en sorte que ce soit la /meme/ version de gcc (memes patches, etc).

Je vais surement dire une betise puisque je ne connais pas ton projet. Et en plus je vais repeter ce qui vient d'etre dit. Bref, ce message est nul et sans interet mais mes petits doigts sont en verve ce matin.

Normalement un driver se contente de... piloter un peripherique, c'est-a-dire le rendre accessible aux applis. Si, en plus de piloter le periph, il doit dialoguer avec les applis via le reseau, c'est plus un "driver", ca devient une appli. Pourquoi dans ce cas ne pas avoir une hierarchie :
periph <--> driver | /dev/machin | appli de controle <--> reseau
C'est certainement moins efficace que periph <---> driver <---> reseau, mais c'est plus elegant et plus "evolutif" (maintennable). Et sans doute aussi plus resistant aux bugs.

A une epoque ou la tendance est d'externaliser le maximum de choses en userland (udev, hibernate, libusb et fuse bien sur), ton idee n'est plus tres "hype" ;)

S'il faut absolument passer par des fichiers qui doivent etre plus ou moins en RAM, pourquoi ne pas les mmap()er en MAP_SHARED plutot que de passer par un RAMFS ? Et apres, pour la signalisation, un coup de semaphores IPC devrait faire l'affaire (voire named socket ou pipes avec quelques select() bien sentis).

Comme dit au-dessus, si c'est pour piloter la carte normalement, besoin de rien en partituclier. Par contre si c'est pour piloter la carte depuis RTAI dans le domaine temps-réel (avec partage éventuel avec le monde non temps-réel), voir rtnet : http://www.rtnet.org/

Non, j'ai télédéclaré aujourd'hui et ça a bien marché : dchroot sarge 32 a partir d'une sarge amd64 : firefox sarge + plugin jre 1.5 06 de base. J'ai pas mal navigué dans les differentes pages impots du minefi (affichage de mon compte, de ma declaration, etc.) : aucun plantage.

Je ne sais pas pour xorg, mais pour xfree (sarge amd64), j'ai été obligé de préciser une modeline. Ce qui donne :

Section "Monitor"
        Identifier      "Zorglub"
        HorizSync    30.0 - 130.0
        VertRefresh  60.0 - 90.0
        DisplaySize     495 310
        Modeline "1920x1200" 155.0 1920 1984 2016 2144 1200 1203 1206 1212
        Option          "DPMS"
EndSection

Finalement c'est peut-etre pas si inintéressant que ça ces modifs. Si ça intéresse les debianeux, ça vaut peut-etre quand meme le detour : http://david.decotigny.free.fr/wiki/wakka.php?wiki=FreeCorde(...)

Faites comme ci cette news n'existait pas : j'avais pas vu la derniere version du soft sur http://manatlan.online.fr/fricorder.php
Bref, n'utilisez pas ma version !

Je me pose la même question, avec a peu pres les memes criteres (Ogg, USB host, radio et cohabitation avec un Linux). J'avais donc repere le iaudio, le iriver H340 (de tete), et... le samsung YH-J70. J'avoue que je suis assez interesse par le dernier mais je me pose une question : est-ce qu'on peut facilement lui faire manger des mp3/ogg depuis un Linux ? Il semble que les modeles Samsung utilisant une flash reposent sur une base de donnee des fichiers, qu'on doit mettre a jour par un programme special (Yepp sous Linux) quand on ajoute des fichiers. Je me demande si ca fonctionne bien comme ça egalement avec le modele YH-J70...

Des retours d'experience ?

Tu peux effectivement faire comme tu proposes : 2 threads, un specialisé dans la gestion de ttyS, l'autre dans la GUI. Eviter d'envoyer des trames ttyS a partir de la GUI : preferer une bonne vieille synchro pour reveiller le thread ttyS a partir de la GUI afin de lui faire transmettre les donnees sur le port serie (message queue posix, ou plus simplement write dans la GUI / select au niveau du thread ttyS). Comme ca le thread GUI ne s'occupe que des fenetres et pas des subtilites de l'acces au ttyS, le thread ttyS gere tout seul comme un grand le port serie, et il n'y a de facto pas de probleme de synchro sur le port serie puisque c'est le thread ttyS qui centralise et regule tous ces acces.

Mais c'est un peu lourdingue, il n'y a pas besoin de sortir l'artillerie lourde pour ca. Une GUI, c'est ni plus ni moins qu'une boucle d'evenements. Il suffit donc de faire entrer les evenements ttyS dans cette boucle. En plus comme on est en multitache cooperatif dans ce cas, on n'a pas a craindre les acces concurrents sur le port serie. Par exemple, si la gui est en gtk, on utilisera g_main_add_poll/g_source_add de la glib. Presque tous les toolkits graphiques permettent de rajouter des file descriptors dans la boucle.

Modifier le fichier /etc/network/interfaces. Genre :

iface eth0 inet dhcp
        up /usr/sbin/ethtool -s eth0 autoneg off duplex full

(les puristes trouveront que c'est une catastrophe cette ligne, il y a moyen de faire beaucoup plus élégant)

> est-ce que il est possible de construire un pilote de cette façon?
Oui

> je vous que vous m'orientez;
Tu il nous vous elle.

Pour recuperer les infos sur les ports, adresses de bases et IRQ, y'a pas de solution universelle. Disons qu'avec les bus plug and play ça se fait tres bien. Comme PCI est de type pnp et comme je pense que tu causes d'une carte PCI, c'est donc tres simple de recuperer ces infos.

Quelques docs : specs PCI 2.3, http://lwn.net/Kernel/LDD3/ ... (et bien sûr http://sos.enix.org d'ici quelques mois ;).

> doit-on installer ssh coté Windows aussi pour que tout marche comme sous Linux?

Non. Il suffit d'avoir installé un client ssh sur le windows (et un serveur ssh sur le *NIX bien sûr). Je me demande meme si le client ssh en question n'est pas fourni avec les binaires unison (?). Ensuite : on est sous windows, on lance unison, et hop ! le tour est joué, ça fait la synchro (dans les deux sens).

Par contre, pour faire l'inverse (je suis sous *NIX et je veux synchroniser mon borderl avec fenetres XP), il faut certainement un serveur ssh sur le windows.

Avec RTLinux je sais pas. Il semble que la version pro supporte pas mal de matos mais la version libre c'est moins sûr (a confirmer).

Cote libre tu as RTAI qui a l'air bien mûr et maintenant Xenomai2 qui est tres seduisant (mais un peu moins mûr, ça ne m'empêche pas de le faire tourner en ce moment même ;) :
http://www.rtai.org
http://www.xenomai.org/

Côté reseau, les deux supportent rtnet : http://www.rtnet.org/ qui gère des cartes ethernet très répandues, ainsi que l'IP sur ieee1394 avec rt-firewire : http://rtfirewire.dynamized.com/ . Je n'ai pas essayé mais j'ai l'impression qu'il est possible de partager la même carte réseau entre tâches RT et noyau Linux normal.