Ce qui m'inquiete d'avantage c'est que c'est du 1mega et que ce n'est qu'en experimentation... Le temps que ca sorte pour le grand public, l'adsl 2 sera bien répendu je pense et pourquoi pas d'autres solutions techniques.
C'est sans doute vrai dans pas mal d'endroit mais il ne faut pas oublier que dans pas mal de bled pour cause de distance du DLAM trop grande l'ADSL ne sera jamais disponible (trop cher de construire un DLAM pour chaque petit bled eloigné de 5km). Alors que justement chaque petit bled dispose d'un poste transformateur edf.
Cette techno est aujourd'hui deployer non pas pour concurencer l'adsl dans les villes mais pour permettre au chose que du 56k dans les campagnes.
et bien il n'y as pas grand chose a faire avec ca.
Comme le dis l'autre poste en USB 1.0 (qui d'ailleurs serait plutot 1.1) ca m'etonnerait qu'il puisse booter sur une clef usb.
Mon conseil :
Avec un tournvis demonte le disque dur, on trouve des adaptateurs 2pouce et demi (format standard des portable) vers 3pouce et demi(format standard des PC de table) monte ton disque dur dans un PC complet (chez un copains peut etre) et fais un installe sans configurer le demarrage en mode graphique surtout.
Ensuite remets ton disque dur dans le portable et fini la configuration de X a la main.
Pour la distrib choisi la en fonction de la place et de ce que tu veux faire.
Vu la faible taille regarde du cote de damn Small linux ou de beatrix qui sont connue pour etre econome en tout.
software: logiciel tournant sur ton processeur
firmware:logiciel à téléchargé dans le processeur de la carte d'acquisition pour qu'elle marche.
Bon j'ai du mal expliqué, une fois que ton fichier existe sur le disque dur tu insmod simplement le module dvb_ttpci et du regarde si le message d'erreur dans le dmesg a bien disparu, avec le firmware qu'il iras chercher sur ton disque tout devrait aller bien.
l'emplacement du fichier ne depends pas de la distrib.
voila les infos utiles ! dvb-ttpci: cannot request firmware!
a premiere vue l'ancien driver contenait un firmware proprio, dans le 2.6 une grande vague de nettoyage a eut lieu pour assainir le kernel de toute trace de code ferme et proprio.
if te faut un fichier "dvb-ttpci-01.fw"
qui est la http://www.linuxtv.org/download/dvb/firmware/(...)
a installer la /usr/lib/hotplug/firmware/dvb-ttpci-01.fw par defaut. note:il te faut hotplug dans le kernel
pour savoir comment donner l'information au module que tu charge pour lui dire ou est le firmware si tu le mets ailleurs fait un
modinfo "nom_du_module" -p ou -h
voila, et maintenant ca marche ?
et son interface a changée ?
un petit examen avec
dmesg
des messages d'info que le module renvoit pourrais donner beaucoup plus d'information.
Je sait que l'interface video4linux a changer entre le 2.4 et 2.6 mais j'ai suivi ca d'un oeil tres distrait.
tzap c'est quoi ? il y as une option pour lui specifier le chemin du device a utiliser ? il n'y aurait pas un mise a jour a faire de ce logiciel pour les kernel 2.6 ?
je pense que ce qu'il attend c'est un chemin de type linux.
Sous linux le disque dur IDE-Primaire (sous windows C:\)
ce decris "/dev/hda1" si tu veut rajoute un repertoire derriere
/dev/hda1/mandrake (attention au majuscule / minuscule).
au essaye directement hda1/mandrake dans l'installeur, je ne connais pas la syntaxe qu'il attend.
Je pense que ton probleme vient que ta version de faire un module
(gcc -c...) ne correspond plus a la facon de faire.
Cela ressemble a l'ancienne facon de faire pour les kernel 2.0,2.2 et 2.4 mais avec la 2.6 les regles d'ecriture des modules on changées.
tu trouvers ici https://linuxfr.org/forums/31/7904.html(...)
un makefile de base pour compiler un modules et ici http://lwn.net/Kernel/LDD3/(...)
une version a jour du livre d'ecriture des drivers linux (vu qu'a premiere vu tu travaille avec la seconde edition du livre)
Pour faire tres simple (ne hurler pas pour l'approximation).
Dans un proc tout est cadencé par l'horloge, chaque instruction prend un temps multiple de l'horologe pour s'executer.
Par exemple une division va prendre 10 coups d'horloge pour s'exectuer.
Que ce passe t-il si l'operation ne prend en realité que 9.5 coups d'horloge ? et bien on attend le 10eme coups d'horloge pour executer l'instruction suivante.
Dans un proc asynchrone le principe et que quand une instruction est finie on passe a la suivante car il n'y as pas d'horloge.
Si on as besoin d'une reference temporel (pour une horloge) on pause un circuit externe avec en frequence la base de temps souhaité.Pourquoi avoir un proc a 300MHZ pour faire une IT toutes les 1millisecondes ? Autant avoir une IT toutes les milli.
si tu as des registres à l'interieur du proc dont la valeurs varie ils sont composés des cellules de type RAM. Ce qui revient a dire que la depose de transistor et de capacité sur le plastique est realisable, pour faire une ROM il suffit de deposer des parties conductrice et non conductrice(par exemple les premieres ROM etait des matrices a fusible).
Effectivement un systeme qui en plus de ces registres contient de la RAM adressable et des peripheriques (ex UART) est plutot considéré comme un microcontrolleur.
Quand je parle d'un systeme en un seul chip pour le procos je veux simplement dire qu'il contient toute les technos electronique de depose (a tres petite echelle) que l'on retrouve en general dans le silicium alors que la depose est ici faites sur du plastique.
il y as un truc ou j'ai pas trop compris ce que ca faisait https://linuxfr.org/2005/04/05/18655.html(...)
mais ca devrait couvrir les besoins standard d'une PME comme ca (enfin la je m'avance)
un processeur regroupe l'ensemble des technos necessaire a un système complet en un seul chip (partie figée->rom,decodage, partie volatile->ram,alu,mmu...).
Donc arrivé a faire un proc sur circuit souple permet d'envisager que toute partie du vetement et non une partie "dur" fasse partie du systeme.
[A bientot l'expression: la ram j'en ai plein le dos :-).]
Le vetement n'est qu'un exemple qui m'est venue a l'esprit en tapant, a l'avenir on pourrait mettre de l'intelligence dans tout ce qui est souple et qui nous entoure tout les jours.Les applications sont encore a trouver.
En theorie en recouvrant de plastique souple et etanche ca devrait passer en machine sans pb un proc comme ca.
Je voudrais savoir si quelqu'un sait comment faire pour compiler un module noyau en utilisant une bibliothèque externe (du genre ../meslibrairies/maLib.a). on ne le fait pas.
En effet le code que tu insere dans le noyeaux doit etre le plus petit, le plus efficace et le moins bugger que possible.
La programmation dans le noyeaux impose certaines regles, et interdit l'utilisation des libc normales.
Les bilbiotheques sont des sources compilée d'une certaine maniere, les modules sont des programmes compilé d'une autre donc fatalement tout est incompatible.
Si tu avais besoin de scinder ton modules en plusieurs fichiers C et les linker entre eux c'est faisable en faisant dependre ton .o de plusieurs .o mais je ne vois pas de raison d'utiliser une bilbiotheque de truc tout fait dans le kernel.
The fate of 80386 is in your hands
----------------------------------
Currently, the 80386 sub-architecture for i386 is unmaintained.
Although sarge will include kernels capable of emulating certain 486+
instructions needed by current userspace libraries, this emulation
includes known root security holes; therefore, we cannot offer any
assurances that 80386 is supported in the tradition of Debian stable
releases.
This is a last call for volunteers: if 80386 is to be supported for
sarge, we need someone with knowledge of this architecture to step
forward to provide a secure solution (in kernel or in userspace), test
upgrade paths, and handle various other tasks necessary to get the
subarch in shape for sarge. If no one steps forward, we will be forced
to drop official support for 80386 in sarge.
If 80386 will not be officially supported for sarge, we will also not
provide an upgrade path for existing 80386 users of woody.
En clair :
1) l'emulation du 486 avec un 386 (indispensable pour certaine lib user) a des trous de securité connu pour sur les 386
2)Il ne trouve pas de volontaire pour les corriger et les tester (en clair ca n'interesse personne de le faire)
donc il annonce que faute de personne desireuse d'aider et disposant du materiel il ne peuvent garantir le resultat.
AMHA le plus simple et le plus transparent est d'aller provoquer dans les sources de ton kernel: linux/drivers/char/keyboard.c une inversion de valeurs pour E0_DEL et E0_HOLD.
En effet tout viens de ce fichiers pour la gestion du clavier donc en provoquant une inversion dans le kernel toute les autres applications en profiteront.(enfin a mon avis, je ne sait pas ou X va piocher ces infos mais ca m'etonnerait qu'il fasse autrement que s'adresser au drivers du kernel).
Pour aider dans une recompile du kernel de nombreuse source internet sont disponible
la serie 2.6 du kernel est encore en developpement, la derniere version stable est la 2.6.11.6 (www.kernel.org), il est possible que dans la 2.6.8.1 l'ipv6 ne soit pas encore implementé dans tous les modules.
Si tu le peut la demarche a suivre est :
-passer en derniere version de kernel
-refaire l'essai
-si le probleme persiste dans le fichiers tun.c tu as le mail du mainteneur du module, lui ecrire en lui detaillant les messages d'erreurs.
ouais mais ca fait longtemp que l'ont a pas fait de revolution sanglante en europe tu trouve pas que ca manque un peut ?
Tous a vos espadons pour embrocher qui vous vouler
j'suis pas tres bien reveiller mais voila ce que je pense de ton soucis.
Les modules (.ko) sont des programmes qui sont compilé dans un format specifique et ne sont linké qu'au moment du chargement du module par un insmod ou modprobe.
En l'occurence comme tu le dis la compilation est OK, et au chargement tu as des erreurs donc le linkage echoue.
En general c'est du au changement de prototype de fonction entre le moment ou le module a ete ecris et le kernel sur le quel tu essaye de l'integrer.
tun: disagrees about version of symbol skb_dequeue
tun: Unknown symbol skb_dequeue
viens de
#include <linux/skbuff.h>
je pense que l'ipV6 demande que le module tun soit patché a moins que ce soit le kernel.
désolé si je ne me baisse pas j'ai mal au dos ;-)
Il faut voir le pb autrement, ce machin la ne sert a rien tout seul.
Mais par sont faible encombrement il peut faire qu'un appareil tout simple (mais avec un micro et une liaison serie pour bien faire) (voir meme sans micro puisque sont port serie peut etre configure en 5 Input/Output) se connecte en trois coup de cuillere a pot sur TCP/IP.
Exemple, tu peut connecte le machin pour pilote un petit relais qui mets en route ta caffetiere, ton grille pain,une pompe pour commander le robinet de ton bain, la porte electrique de ton garage etc etc.
Dans ce cadre d'emploi peut importe la puissance, cela en fait un petit module d'I/O TCP/IP.
Autre exemple tu dispose d'une petite carte micro dans une machine outils dont tu est tres content mais tu souhaite la commander a distance via le reseau ethernet, dans ce cas comme la grande majorité des design prevoit une liaison serie tu te connecte dessus et hop via une page web du meut mettre a jour ta carte, jouer avec ces parametres et tout ca.
> Comment on fait pour le mettre à jour ?
Deux methodes:
1)Il y a un serveur apache qui tourne dessus, tu peut consulter les pages webs de config et retelecharger un kernel/des fichiers par l'ethernet( bien sur tout cela est proteger par un mots de passe que le fabricant te donne et que tu peut changer)
2)Par la liaison serie suivant un protocole particulier (mode boot strap a la mise sous tension de quelque seconde avant de lancer le kernel)
>Pis faut faire gaffe de pas marcher dessus...
ouais bin la ca fais crack....
note en relisant ta prose il me semble voir un petit probleme, ton module utilise ces zones memoires, donc ce qu'il te faut c'est plutot un acces en ecriture au travers de ton module non ?
En tout cas, si ton module fait une reservation de la zone memoire tu ne pourras pas faire un mmap dessus par /dev/mem car cette requete echoueras (mmap ne fonctionne que sur une zone libre).
Deux solutions soit tu redeveloppe tout le drivers de l'epld en user space avec le mmap via le /dev/mem soit tu rajoute l'acces en ecriture dans le fil-op de ton module.
Donc effectivement si personne n'utilise cette place memoire un programme s'executant en user=root peut faire un mmap sur une zone libre
voir l'exemple ici
je ne vois pas trop exactement ce que tu veux faire et ne pas faire.
Pour autant que je me rapelle il existe plusieurs facon dans la ligne de commande du kernel de lui dire de ne pas acceder a une zone memoire (ISA hole) par exemple ou reserver la zone memoire acessible (lui dire d'acceder 128MO meme si 512Mo sont present sur la machine).
MAIS (le voila) tout ceci servait a l'epoque de l'ISA (et de la gestion des 16 permier Mo de la memoire) a adresser des cartes ISA directement par adresse. Tout ceci n'est PAS utilisable avec des cartes PCI.
Une appli standard ne peut pas acceder a une zone memoire de sont choix sans passer par une passerelle situer dans le kernel.
En clair ton peripherique c'est quoi ? car il est tout a fait possible qu'une tel techno soit existante dans le kernel et qu'il te faille juste savoir comment la declencher ?
a l'heure actuel c'est une technologie en cours d'echantillonage dans des tailles de 16Mb (soit 2Mo) par boitier (depuis juin dernier voir infineon, en 4Mb pour motorola). Autant dire que l'on est tres loin dans le rapport (taille,cout)/(densite) d'un disque dur.
Les premiers composants valident les resultat attendue , mais leur SOP (start of production) est planifié pour 2010. Avant de trouver une densité d'inter-connexion suffisante pour tenir dans un boitier taille 3p1/2 il faudra attendre encore. En terme de debit ca devrait mathematiquement exploser les performances des ordinateurs de leur epoque (bande d'acces mémoire superieurs d'un facteur 10 au memoire DRAM actuel) tout en assurant le stockage permanent des infos (disque dur) SAUF qu'as l'heure actuel le bus processeur n'est bon qu'as gere la bande passante que pour de la memoire dynamique (en clair les Ix86 serait jete a la poubelle pour passer sur des PPC).
Dans une si lointaine perspective (p.d.v. evolutation informatique de table) cela reste du stade conjoncture et l'embarque (telephone portable..etc.. devrait en beneficier dans de proches annees)
plus d'info sur l'annonce ici http://www.infineon.com/cgi/ecrm.dll/jsp/showfrontend.do?lang=EN&am(...)
>combien ça va pouvoir coûter ?
sans doute un max de brouzouf...c'est du matos de pro > Est-ce que 2 millions de cycles c'est suffisant ou pas
c'est un nombre de cycle en ecriture @25°C, en lecture en general on a des temps de retentions d'info de l'ordre de 10ans.
Sur ce genre de matos evite de mettre une bdd, du swap ou autre joyeuseté.
La bonne solution pour un mini system c'est de tourner en RAM pour tous ce qui est ecriture et de sauver les fichiers sur le support a l'extinction du systeme.
>J'en veux un !!!
si le bruit te gene et que tu est pres a mettre 300euros dans un disque dur 2Go regarde du coté des compacts flash+adaptateur IDE et d'investir dans de la RAM, tu peut facilement mettre un linux dessus et sauver tes user-data. Tu peux coupler avec un disque dur dont tu commande la mise sous tension pour swapper les fichiers a backup de second niveau (ou les appli rarement utiliser).
La croissance de densitée des flash ne rattrape pas encore les disques dur, mais tu commence a pouvoir monté des OS complets (encore une fois tous les fichiers de log, et les fichiers souvent acceder en ecriture doivent etre dans la ram systeme) permette des petit poste sympa en basse conso.
[^] # Re: Bon point?
Posté par TheBreton . En réponse au journal Les doigts dans la prise II. Évalué à 4.
C'est sans doute vrai dans pas mal d'endroit mais il ne faut pas oublier que dans pas mal de bled pour cause de distance du DLAM trop grande l'ADSL ne sera jamais disponible (trop cher de construire un DLAM pour chaque petit bled eloigné de 5km). Alors que justement chaque petit bled dispose d'un poste transformateur edf.
Cette techno est aujourd'hui deployer non pas pour concurencer l'adsl dans les villes mais pour permettre au chose que du 56k dans les campagnes.
# ni réseau, ni lecteur disquette, ni lecteur CD ?
Posté par TheBreton . En réponse au message Choix distribution. Évalué à 2.
Comme le dis l'autre poste en USB 1.0 (qui d'ailleurs serait plutot 1.1) ca m'etonnerait qu'il puisse booter sur une clef usb.
Mon conseil :
Avec un tournvis demonte le disque dur, on trouve des adaptateurs 2pouce et demi (format standard des portable) vers 3pouce et demi(format standard des PC de table) monte ton disque dur dans un PC complet (chez un copains peut etre) et fais un installe sans configurer le demarrage en mode graphique surtout.
Ensuite remets ton disque dur dans le portable et fini la configuration de X a la main.
Pour la distrib choisi la en fonction de la place et de ce que tu veux faire.
Vu la faible taille regarde du cote de damn Small linux ou de beatrix qui sont connue pour etre econome en tout.
[^] # Re: le module a évolué peut etre ?
Posté par TheBreton . En réponse au message installer une carte acquisition sous Debian kernel 2.6.8.1. Évalué à 2.
firmware:logiciel à téléchargé dans le processeur de la carte d'acquisition pour qu'elle marche.
Bon j'ai du mal expliqué, une fois que ton fichier existe sur le disque dur tu insmod simplement le module dvb_ttpci et du regarde si le message d'erreur dans le dmesg a bien disparu, avec le firmware qu'il iras chercher sur ton disque tout devrait aller bien.
l'emplacement du fichier ne depends pas de la distrib.
[^] # Re: le module a évolué peut etre ?
Posté par TheBreton . En réponse au message installer une carte acquisition sous Debian kernel 2.6.8.1. Évalué à 2.
dvb-ttpci: cannot request firmware!
a premiere vue l'ancien driver contenait un firmware proprio, dans le 2.6 une grande vague de nettoyage a eut lieu pour assainir le kernel de toute trace de code ferme et proprio.
if te faut un fichier "dvb-ttpci-01.fw"
qui est la http://www.linuxtv.org/download/dvb/firmware/(...)
a installer la
/usr/lib/hotplug/firmware/dvb-ttpci-01.fw par defaut.
note:il te faut hotplug dans le kernel
pour savoir comment donner l'information au module que tu charge pour lui dire ou est le firmware si tu le mets ailleurs fait un
modinfo "nom_du_module" -p ou -h
voila, et maintenant ca marche ?
# le module a évolué peut etre ?
Posté par TheBreton . En réponse au message installer une carte acquisition sous Debian kernel 2.6.8.1. Évalué à 2.
un petit examen avec
dmesg
des messages d'info que le module renvoit pourrais donner beaucoup plus d'information.
Je sait que l'interface video4linux a changer entre le 2.4 et 2.6 mais j'ai suivi ca d'un oeil tres distrait.
tzap c'est quoi ? il y as une option pour lui specifier le chemin du device a utiliser ? il n'y aurait pas un mise a jour a faire de ce logiciel pour les kernel 2.6 ?
[^] # Re: suite
Posté par TheBreton . En réponse au message Pb install !!!. Évalué à 2.
Sous linux le disque dur IDE-Primaire (sous windows C:\)
ce decris "/dev/hda1" si tu veut rajoute un repertoire derriere
/dev/hda1/mandrake (attention au majuscule / minuscule).
au essaye directement hda1/mandrake dans l'installeur, je ne connais pas la syntaxe qu'il attend.
# Version
Posté par TheBreton . En réponse au message problème de création de module. Évalué à 3.
(gcc -c...) ne correspond plus a la facon de faire.
Cela ressemble a l'ancienne facon de faire pour les kernel 2.0,2.2 et 2.4 mais avec la 2.6 les regles d'ecriture des modules on changées.
tu trouvers ici
https://linuxfr.org/forums/31/7904.html(...)
un makefile de base pour compiler un modules et ici
http://lwn.net/Kernel/LDD3/(...)
une version a jour du livre d'ecriture des drivers linux (vu qu'a premiere vu tu travaille avec la seconde edition du livre)
[^] # Re: Asynchrone?
Posté par TheBreton . En réponse au journal Micro-processeur mou le futur ?. Évalué à 2.
Dans un proc tout est cadencé par l'horloge, chaque instruction prend un temps multiple de l'horologe pour s'executer.
Par exemple une division va prendre 10 coups d'horloge pour s'exectuer.
Que ce passe t-il si l'operation ne prend en realité que 9.5 coups d'horloge ? et bien on attend le 10eme coups d'horloge pour executer l'instruction suivante.
Dans un proc asynchrone le principe et que quand une instruction est finie on passe a la suivante car il n'y as pas d'horloge.
Si on as besoin d'une reference temporel (pour une horloge) on pause un circuit externe avec en frequence la base de temps souhaité.Pourquoi avoir un proc a 300MHZ pour faire une IT toutes les 1millisecondes ? Autant avoir une IT toutes les milli.
[^] # Re: Mou, mouif...
Posté par TheBreton . En réponse au journal Micro-processeur mou le futur ?. Évalué à 2.
Effectivement un systeme qui en plus de ces registres contient de la RAM adressable et des peripheriques (ex UART) est plutot considéré comme un microcontrolleur.
Quand je parle d'un systeme en un seul chip pour le procos je veux simplement dire qu'il contient toute les technos electronique de depose (a tres petite echelle) que l'on retrouve en general dans le silicium alors que la depose est ici faites sur du plastique.
# et en tout pres
Posté par TheBreton . En réponse au journal MS Access - Demande de conseils. Évalué à 1.
https://linuxfr.org/2005/04/05/18655.html(...)
mais ca devrait couvrir les besoins standard d'une PME comme ca (enfin la je m'avance)
[^] # Re: Mou, mouif...
Posté par TheBreton . En réponse au journal Micro-processeur mou le futur ?. Évalué à 3.
Donc arrivé a faire un proc sur circuit souple permet d'envisager que toute partie du vetement et non une partie "dur" fasse partie du systeme.
[A bientot l'expression: la ram j'en ai plein le dos :-).]
Le vetement n'est qu'un exemple qui m'est venue a l'esprit en tapant, a l'avenir on pourrait mettre de l'intelligence dans tout ce qui est souple et qui nous entoure tout les jours.Les applications sont encore a trouver.
En theorie en recouvrant de plastique souple et etanche ca devrait passer en machine sans pb un proc comme ca.
# c'est simple
Posté par TheBreton . En réponse au message makefile modules noyau 2.6. Évalué à 2.
on ne le fait pas.
En effet le code que tu insere dans le noyeaux doit etre le plus petit, le plus efficace et le moins bugger que possible.
La programmation dans le noyeaux impose certaines regles, et interdit l'utilisation des libc normales.
Les bilbiotheques sont des sources compilée d'une certaine maniere, les modules sont des programmes compilé d'une autre donc fatalement tout est incompatible.
Si tu avais besoin de scinder ton modules en plusieurs fichiers C et les linker entre eux c'est faisable en faisant dependre ton .o de plusieurs .o mais je ne vois pas de raison d'utiliser une bilbiotheque de truc tout fait dans le kernel.
[^] # Re: Cible i386 ? - ya pas que les ordis perso
Posté par TheBreton . En réponse au journal Sarge serait bientôt 'freezée'. Évalué à 6.
En clair :
1) l'emulation du 486 avec un 386 (indispensable pour certaine lib user) a des trous de securité connu pour sur les 386
2)Il ne trouve pas de volontaire pour les corriger et les tester (en clair ca n'interesse personne de le faire)
donc il annonce que faute de personne desireuse d'aider et disposant du materiel il ne peuvent garantir le resultat.
# tout en douceur a la source de tout...
Posté par TheBreton . En réponse au message Inverser deux touches du clavier. Évalué à 2.
En effet tout viens de ce fichiers pour la gestion du clavier donc en provoquant une inversion dans le kernel toute les autres applications en profiteront.(enfin a mon avis, je ne sait pas ou X va piocher ces infos mais ca m'etonnerait qu'il fasse autrement que s'adresser au drivers du kernel).
Pour aider dans une recompile du kernel de nombreuse source internet sont disponible
[^] # Re: un petit pas ...
Posté par TheBreton . En réponse au message Problème avec le Module tun. Évalué à 2.
Si tu le peut la demarche a suivre est :
-passer en derniere version de kernel
-refaire l'essai
-si le probleme persiste dans le fichiers tun.c tu as le mail du mainteneur du module, lui ecrire en lui detaillant les messages d'erreurs.
[^] # Re: [:totoz]
Posté par TheBreton . En réponse à la dépêche FACT, un projet de directive européenne pour une dictature numérique ?. Évalué à 10.
Tous a vos espadons pour embrocher qui vous vouler
# un petit pas ...
Posté par TheBreton . En réponse au message Problème avec le Module tun. Évalué à 2.
Les modules (.ko) sont des programmes qui sont compilé dans un format specifique et ne sont linké qu'au moment du chargement du module par un insmod ou modprobe.
En l'occurence comme tu le dis la compilation est OK, et au chargement tu as des erreurs donc le linkage echoue.
En general c'est du au changement de prototype de fonction entre le moment ou le module a ete ecris et le kernel sur le quel tu essaye de l'integrer.
tun: disagrees about version of symbol skb_dequeue
tun: Unknown symbol skb_dequeue
viens de
#include <linux/skbuff.h>
je pense que l'ipV6 demande que le module tun soit patché a moins que ce soit le kernel.
[^] # Re: c'est quoi ce machin ?
Posté par TheBreton . En réponse au journal Vous avez dit petit ???. Évalué à 4.
Il faut voir le pb autrement, ce machin la ne sert a rien tout seul.
Mais par sont faible encombrement il peut faire qu'un appareil tout simple (mais avec un micro et une liaison serie pour bien faire) (voir meme sans micro puisque sont port serie peut etre configure en 5 Input/Output) se connecte en trois coup de cuillere a pot sur TCP/IP.
Exemple, tu peut connecte le machin pour pilote un petit relais qui mets en route ta caffetiere, ton grille pain,une pompe pour commander le robinet de ton bain, la porte electrique de ton garage etc etc.
Dans ce cadre d'emploi peut importe la puissance, cela en fait un petit module d'I/O TCP/IP.
Autre exemple tu dispose d'une petite carte micro dans une machine outils dont tu est tres content mais tu souhaite la commander a distance via le reseau ethernet, dans ce cas comme la grande majorité des design prevoit une liaison serie tu te connecte dessus et hop via une page web du meut mettre a jour ta carte, jouer avec ces parametres et tout ca.
[^] # Re: Question
Posté par TheBreton . En réponse au journal Vous avez dit petit ???. Évalué à 6.
Deux methodes:
1)Il y a un serveur apache qui tourne dessus, tu peut consulter les pages webs de config et retelecharger un kernel/des fichiers par l'ethernet( bien sur tout cela est proteger par un mots de passe que le fabricant te donne et que tu peut changer)
2)Par la liaison serie suivant un protocole particulier (mode boot strap a la mise sous tension de quelque seconde avant de lancer le kernel)
>Pis faut faire gaffe de pas marcher dessus...
ouais bin la ca fais crack....
# Comme c'est dit sur leur site
Posté par TheBreton . En réponse au message Chargement du Module Ndiswrapper. Évalué à 2.
source http://ndiswrapper.sourceforge.net/phpwiki/index.php/Installation(...)
ta version est 2.4.20 soit inferieur au minimum requis
Je te conseille si tu le peut de passer sur la serie 2.6
[^] # Re: gni?
Posté par TheBreton . En réponse au message dev/mem mémoire physique. Évalué à 2.
En tout cas, si ton module fait une reservation de la zone memoire tu ne pourras pas faire un mmap dessus par /dev/mem car cette requete echoueras (mmap ne fonctionne que sur une zone libre).
Deux solutions soit tu redeveloppe tout le drivers de l'epld en user space avec le mmap via le /dev/mem soit tu rajoute l'acces en ecriture dans le fil-op de ton module.
[^] # Re: gni?
Posté par TheBreton . En réponse au message dev/mem mémoire physique. Évalué à 2.
voir l'exemple ici
http://www.tldp.org/LDP/khg/HyperNews/get/devices/fake.html(...)
# gni?
Posté par TheBreton . En réponse au message dev/mem mémoire physique. Évalué à 2.
Pour autant que je me rapelle il existe plusieurs facon dans la ligne de commande du kernel de lui dire de ne pas acceder a une zone memoire (ISA hole) par exemple ou reserver la zone memoire acessible (lui dire d'acceder 128MO meme si 512Mo sont present sur la machine).
MAIS (le voila) tout ceci servait a l'epoque de l'ISA (et de la gestion des 16 permier Mo de la memoire) a adresser des cartes ISA directement par adresse. Tout ceci n'est PAS utilisable avec des cartes PCI.
Une appli standard ne peut pas acceder a une zone memoire de sont choix sans passer par une passerelle situer dans le kernel.
En clair ton peripherique c'est quoi ? car il est tout a fait possible qu'une tel techno soit existante dans le kernel et qu'il te faille juste savoir comment la declencher ?
[^] # Re: on peut toujours rever...
Posté par TheBreton . En réponse au journal Disque dur état solide. Évalué à 10.
Les premiers composants valident les resultat attendue , mais leur SOP (start of production) est planifié pour 2010. Avant de trouver une densité d'inter-connexion suffisante pour tenir dans un boitier taille 3p1/2 il faudra attendre encore. En terme de debit ca devrait mathematiquement exploser les performances des ordinateurs de leur epoque (bande d'acces mémoire superieurs d'un facteur 10 au memoire DRAM actuel) tout en assurant le stockage permanent des infos (disque dur) SAUF qu'as l'heure actuel le bus processeur n'est bon qu'as gere la bande passante que pour de la memoire dynamique (en clair les Ix86 serait jete a la poubelle pour passer sur des PPC).
Dans une si lointaine perspective (p.d.v. evolutation informatique de table) cela reste du stade conjoncture et l'embarque (telephone portable..etc.. devrait en beneficier dans de proches annees)
plus d'info sur l'annonce ici
http://www.infineon.com/cgi/ecrm.dll/jsp/showfrontend.do?lang=EN&am(...)
# on peut toujours rever...
Posté par TheBreton . En réponse au journal Disque dur état solide. Évalué à 6.
sans doute un max de brouzouf...c'est du matos de pro
> Est-ce que 2 millions de cycles c'est suffisant ou pas
c'est un nombre de cycle en ecriture @25°C, en lecture en general on a des temps de retentions d'info de l'ordre de 10ans.
Sur ce genre de matos evite de mettre une bdd, du swap ou autre joyeuseté.
La bonne solution pour un mini system c'est de tourner en RAM pour tous ce qui est ecriture et de sauver les fichiers sur le support a l'extinction du systeme.
>J'en veux un !!!
si le bruit te gene et que tu est pres a mettre 300euros dans un disque dur 2Go regarde du coté des compacts flash+adaptateur IDE et d'investir dans de la RAM, tu peut facilement mettre un linux dessus et sauver tes user-data. Tu peux coupler avec un disque dur dont tu commande la mise sous tension pour swapper les fichiers a backup de second niveau (ou les appli rarement utiliser).
La croissance de densitée des flash ne rattrape pas encore les disques dur, mais tu commence a pouvoir monté des OS complets (encore une fois tous les fichiers de log, et les fichiers souvent acceder en ecriture doivent etre dans la ram systeme) permette des petit poste sympa en basse conso.