TheBreton a écrit 932 commentaires

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.

Encore un docteur yavaitqua !
Heuresement que j'avais pas voté pour lui la derniere fois (sans plus trop savoir pourquoi maintenant) mais je m'en souviendrais pour la prochaine fois.

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...