TheBreton a écrit 926 commentaires

Je vais tenter d'eclairer quelque point.
Les modules sont une partie du noyeau non fondamental a son fonctionnement mais permettant de faire fonctionner un materiel bien particulier, ou une fonctionnalitée du noyeau dont certains prefere ce passer.
c'est un peut l'equivalent d'un driver sous win32.
Car le principe du noyeau c'est que ce qui est dedans est residant permanent en memoire RAM, ce qui peut imposer du swap sur le disk (ram dispo insuffisante) si on prenait l'habitude de construire de noyeau enorme comprenant tout les modules en static.
Comme sous linux un module et en fait un linkage du prog avec le kernel les modules peuvent (et souvent le font) appeller directement des fonctions presentes dans d'autre modules (soit our empiler des drivers ex : console->fb, ou encore usb-core->usb-input->usbmouse.
Donc les utilitaires comme depmod, modprobe verifie au chargement d'un module si les modules dont les fonctions sont utilisé par celui en train d'etre charge sont deja present en memoire et s'il sont absent de les charges.
insmod est l'outil de base de linkage d'un module avec le kernel et il echoue tout de suite en cas de dependance non resolu.

quand a alias c'est l'outil qui permet de corriger les fote d'orthographe quand on tape trop rapidement :-)
il permet en fait de definir sous ton bash le remplacement d'une commande par une autre sequence.
ex : alias 'll'='ls -l'
permet quand on tape ll d'avoir le resultat de la commande 'ls-l'

moi pour mettre en forme mes sources apres avoir tapé au kilometre j'utilise un petit soft tres bien qui connait toutes les regles de presentation (et tu peut definir les tiennes si tu veux)
c'est indent (un petit google et tu le trouveras)

linux est portable et optimisable a volontée.
Il suffit juste que quelqu'un se penche la dessus et se bouge un peut pour faire la chose.
Forcement, si personne ne se bouge cela ne se feras pas.
sur le dev x86 de nombreuse optimisation et utilisation de particularité en asm sont faite. au possesseur de G3/4 de faire pareille dans le kernel tree ou dans gcc.

sur le site
http://www.findsabrina.org/altivec/(...)
un point de depart pour patcher le gcc3.3 de yellow dog pour la prise en charge de l'altivec.
une recompil de l'appli en question pour la prise en compte et hop...
recompiler le kernel directement est une mauvaise(idée pour moi) car je crois qu'il faut le patcher d'abord

Point de vue host->device peut importe le chipset du device puisque c'est le resultat de l'enumeration qui donne les caracteristique des EP pour le dialogue.
Apres quand a savoir quoi mettre dans les donnée est un autre combat.
En general les gros devices (imprimante,modem,tunner tv) sont tres propriétaire et les petits devices (keyboard,mouse,joystick,masse storage) sont tres facile a porter.

je site au passage un produits comme

http://www.hhdsoftware.com/usbmon.html(...)
proprio sous windows mais existe en trial version

qui permet de sniffer les echanges usb entre un drivers windows et le device et qui devrait te permettre d'avancer pour reproduire la phase d'init de com pour ton modem

Les couches basses de win---s sont tres peut documentés et depende de beaucoup des couches superieures.
Donc meme avec un drivers qui tournerait tu n'aurais aucun logiciel sous linux qui pourrait s'en servir, les standard de communication linux/driver et windows/driver etant par trop different.
A ma connaissance, seul un soft commercial orienté couche réseau (qui elle sont similaire entre les deux OS) permet de faire tourner une certaine partie des drivers carte reseau win sous linux.
La meuilleur solution est d'ecrire un drivers pour ton peripherique USB qui par chance est beaucoup plus standardiser que les autres peripheriques...
il y a de grande chance qu'en utilisant un driver generique (mass storage,scanner, mouse,keyboard) tu dispose de suffisement de chose...

anchois, rockfort(tm) et chorizo.
Tu n'as qu'as bien la pliée pour la faire passer dans les fils et les tirez vers le haut, la pesanteur feras les reste pour qu'elle arrive chez moi.
Plus serieusement, les ricains toujours a la recherche d'une nouvelle methode pour grossir sans effort...

ce qui pourrait etre la premiere trace historique d'une recherche de mots par frequence d'emploi de certaine lettre dans une langue.
D'ailleur pour le francais je crois que c'est le E le plus utilisé, quelqu'un connait un site ou trouver les frequences de chaque lettre pour les langues les plus repandues ?

on fait tout aussi bien avec un peut de marc de café, une carte au mur et une flechette....

[X] j'aime bien le format papier

il me permet de lire avachi sur mon canapé alors que mon ecran me fait mal au ventre quand j'essaye de faire pareil avec un doc pdf

>un particulier peut-il diffuser ces albums achetés sans verser de droits ?
non bien sur, ce que tu achete c'est le medium et le droit d'écoute dans un cercle familiale. En aucun cas des droit sur la musique que tu achete.
Le principe va loin, si tu est dans une boutique (donc acessible a du public) et que tu ecoute la radio tu dois payer des droit a la sacem.
Pour la diffusion de musique sur internet c'est a eux que tu doit t'adresser.

methode la plus simpe c'est retour au vendeur de la carte en disant "marche plus et pourtant j'ai rien fait!"

Quoi des robots votent maintenant ou une certaine parano s'installe...
c'est vrai que vachement c'est vachement bien mais ca date un peut maintenant. Pour parler jeune's faut dire c'est top !

c'est pas hors de porter d'espionner ton truc si tu as de noitions de communication usb.
A priori un joystick comme ca devrait declarer un ou plusieur ep en interrupt.
en ecrivant un dirver qui interroge et affiche le contenu du ep puis en bougant les axe, appuyant sur les boutons du devrait facilement retrouver dans la trame le contenu et la signification des commandes.
Ensuite, l'ecriture du driver et l'inscription dans les input device est l'histoire d'un autre journal.
Pour voir comment ton joystick se presente branche le puis fait un 'lsusb' pour avoir sa config.

Comme deja repondu sur ton journal precedant, des sources directement exploitable sont usb-skelethon.c qui sont fourni avec les sources du kernel dans la rubrique drivers.
il gere parfaitement les transferts bulk et seul le vid et pid sont a changer pour que ca marche directement .
modifie ton firmware pour fonctionner avec un ep bulk in et un ep bulk out et tu n'auras qu'a compiler le drvers tel quel

Au contraire, la disponibilité des sources pretent a de multiple version et customisation d'un soft "standard" avec personnalisation pour chaque client.
Que chacun dispose des sources permet de changer de prestataire a volonté bien sur, si les prix ne corresponde pas au attente, si la qualité du service est insuffisante....
Donc oui, si les ssii continue de travailler comme aujourd'hui en traitant les gens comme des pigeons une fois la commande passé alors ces boites la fermeront.
C'est un tournant dans le metier qu'il faut savoir negocier et ceux qui iront tout droit finiront dans le mur!
signé: un dinosaure de l'informatique

Plein d'emmerde avec une i865 et auparavent une i810.
Bref, pour linux j'eviterais les cartes intel a l'avenir, le driver qui est fourni ne tourne pas sous les noyaux 2.6.
Au moins avec mes cartes nvidia je n'ai jamais eut de soucis !!!!
(lapubsaitmaljeleferaispupromis)

Le reverse engineering est parfaitement legal dans la CEE (pour l'instant) du moment que le resultat ne donne pas les moyens de contrefaire le materiel etudiée.
On a tous a fait le droit de demonter un engin electronique pour en analyse le fonctionnement du materiel et du logiciel, et de le refaire avec des composants materiel et ou logiciel different sans que cela soit de la contrefacon.
Un grand site pour l'electronique libre est www.opencores.org

j'ai le meme pb avec la carte graphique voisine I865G.
apres plein d'essais voila a quoi j'en suis arrivé.
Xfree 4.3, drivers carte graphique "vesa" et non i810, au boot de xfree l'affichage est tordu, je fais un CTRL+ALT+F1 pour aller en console et un ALT+F7 pour revenir en graphique et voila l'affichage et bon.

Extrait de ce qu'il te faut suivre ABSOLUMENT pour remettre
a la norme ton module qui viens du 2.4.xx
doc consultable en ligne a:
http://www-106.ibm.com/developerworks/linux/library/l-inside.html(...)

Driver porting to Linux 2.6
The 2.6 kernel has brought along with it a pretty significant list of changes for driver developers. This section highlights some of the important aspects of device driver porting from the 2.4 to 2.6 kernel.

First, the kernel build system has been improved for quicker builds compared with 2.4. Improved graphical tools have been added: make xconfig (requires Qt libraries) and make gconfig (requiring GTK libraries).

The following are some of the highlights of the 2.6 build system:

Creates arch-zImage and modules by default when just make is issued
For parallel make, make -jN is the preferred choice
make is not verbose by default (set KBUILD_VERBOSE=1 or use make V=1 to change this)
make subdir/ will compile all the files within subdir/ and below
make help will provide the make targets supported
make dep need not be run at any stage
The kernel module loader has also been completely reimplemented in 2.5, which means that the module-building mechanism is much different compared to 2.4. A new set of module utilities is needed for module loading and unloading (please see Resources for a download link for those). Old 2.4 makefiles will no longer work as of 2.6.

The new kernel module loader is the work of Rusty Russel. It makes use of the kernel build mechanism and produces a .ko (kernel object) module object instead of an .o module object. The kernel build system compiles the module first and then links to vermagic.o. This creates a special section in the object module that contains information like the compiler version used, the kernel version, whether kernel preemption is used, and so on.

Now let's take an example and analyze how the new kernel build system should be used to compile and load a simple module. The module concerned is a "hello world" module and is similar to 2.4 module code except that module_init and module_exit need to be used instead of init_module and cleanup_module (kernel 2.4.10 modules onwards use this mechanism). The module is named hello.c and the Makefile is as follows:

Listing 3. Example driver makefile

KERNEL_SRC = /usr/src/linux
SUBDIR = $(KERNEL_SRC)/drivers/char/hello/
all: modules

obj-m := module.o
hello-objs := hello.o

EXTRA_FLAGS += -DDEBUG=1

modules:
$(MAKE) -C $(KERNEL_SRC) SUBDIR=$(SUBDIR) modules



This makefile uses the kernel build mechanism to build the module. The compiled module will be named module.ko and is obtained by compiling hello.c and linking with vermagic. KERNEL_SRC indicates the kernel source directory and SUBDIR indicates the directory where the module is located. EXTRA_FLAGS indicate any compile-time flags that need to be given.

Once the new module (module.ko) is created, it can be loaded and unloaded by using the new module utilities. Older module utilities used in 2.4 cannot be used for loading and unloading the 2.6 kernel modules. The new module loading utility tries to minimize the occurrence of race conditions that may occur when a device is opened while the corresponding module is being unloaded, but after the module has made sure that no one is using it. One of the reasons for these race conditions is that the module usage count is manipulated within the module code itself (via MOD_DEC/INC_USE_COUNT).

In 2.6, the module need not do this step of increasing/decreasing the reference count. Instead, this is now done outside of module code. Any code that tries to reference the module has to call try_module_get(&module), and upon success can access the module; this call will fail if the module is being unloaded. Correspondingly, references to the module can be released by using module_put().

une url a lire:
http://lwn.net/Articles/driver-porting/(...)

avec le 2.6 le fichier de sortie n'est plus un .o mais un .ko si ma memoire est bonne.

oui...mais c'est rare et cela signifie en general que le hardware est concu bancalement.
ce qui m'etonnerait de la part d'amd a vrai dire

sans doute un probleme de priorité d'operateur
au lieu de
spin_lock_init(&(*ppKhal_dev->blktra_spinlock));
essaie
spin_lock_init(&( (*ppKhal_dev)->blktra_spinlock));

J'ai pas lu toute les sources (immenses comme archive)
mais un drivers 2.4 recent et bien ecris ce porte facilement sur un 2.6.
Quand tu le compile tu as quoi d'autre comme message d'erreur ?
La structure pci_dev->driver_data etait une zone de stockage que le driver utilisait pour ces donnes a lui et a ca sauce.
en general on faisait un kmalloc d'une structure et l'adresse de resultat etait mémorisée dans pci_dev->driver_data.
Pour s'en debarasser remplace toute les references vers une variable globale de la structure en question.
Quand au modification du driver, si on te donnne les sources , que tu les modifie et ne les redistribue pas ca m'etonnerait que tu ai des soucis legaux.