oui mais c'est un module (dynamique) par default, donc rien à changer quand on fait un make menuconfig (sauf quelques options de debogage!)
Par contre qu'est ce qui fait qu'un module se charge par un insmod et non par un modprobe! et comment le charger au démarrage!

correction : le alias seul ne suffit pas dans /etc/modprobe.conf (il faut que le module soit chargé par une autre commande!)

Pour installer les sources des modules modifié sans casser quoi que ce soit, l'ideal serait de mettre un lien symbolique vers le repertoire des modules ( /lib/modules/2.6.16-1.2096_FC5 par exemple!

Les sources du kernel recuperes par yum sont incomplets (pas de main.c sous init par exemple). Je pense qu'ils servent simplement de stub pour compiler un driver n'appartenant pas au noyau (come ipw2200). il faut donc charger les sources du noyau officiels.

oui, par defaut, c'est un module...
le modprobe gere les dependances d'un module par rapportaux autres en regardant le fichier modules.dep cree par depmod.
la detection d'un module est fait par le noyau, kudzu...sur mon pc, j'ai ieee1394 de charge, detecte par le VID,DID PCI de mon controleur. Ca paut etre le VID,DID en USB. Une fois que l'on a ca, on regarde les dependances des modules (sous /lib/modules/kernelxxxx/modules.dep), on regarde le fichier /etc/modules.conf pour les paramtres des modules et voila....
y a aussi le fichier /etc/sysconfig/hwconf qui contient la liste des materiels detectes...

tu peux compiler les sources du modules de facon independante (pour une version du noyau en cours) puis le mettre a la place de celui par defaut sous /lib/modules/kernel...

++

Avec le noyau Linux de base :
# uname -r
2.6.16-1.2096_FC5


j'ai les modules ieee1394 suivants :
lsmod|grep 1394
ohci1394 31749 0
ieee1394 288665 1 ohci1394

# lspci -v me donne pour le 1394 :
00:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. A8V Deluxe
Flags: bus master, medium devsel, latency 64, IRQ 21
Memory at fda00000 (32-bit, non-prefetchable) [size=2K]
I/O ports at dc00 [size=128]
Capabilities: [50] Power Management version 2

donc mon controleur IEEE1394 est un peripherique PCI

Le fichier /etc/sysconfig/hwconf me donne son VID/DID (1106/3044):
class: FIREWIRE
bus: PCI
detached: 0
driver: ohci1394
desc: "VIA Technologies, Inc. IEEE 1394 Host Controller"
vendorId: 1106
deviceId: 3044
subVendorId: 1043
subDeviceId: 808a
pciType: 1
pcidom: 0
pcibus: 0
pcidev: 7
pcifn: 0

Voila ce qui doit me charger les modules par le noyau...

ensuite, je vais sous /lib/modules/2.6.16-1.2096_FC5/kernel/drivers/ieee1394
et je charge le module eth1394 :
# insmod eth1394
# lsmod|grep 1394
eth1394 19525 0
ohci1394 31749 0
ieee1394 288665 2 eth1394,ohci1394


dmesg me donne en plus :
eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)

Je me fais un :
# ifconfig eth1 up :
et ifconfig me donne :

eth0 blablabla

eth1 Link encap:UNSPEC HWaddr 00-E0-18-00-00-31-47-D6-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1147 errors:0 dropped:0 overruns:0 frame:0
TX packets:1147 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1881940 (1.7 MiB) TX bytes:1881940 (1.7 MiB)

# ifconfig eth1 192.168.1.1
# ifconfig
eth0 blablabla

eth1 Link encap:UNSPEC HWaddr 00-E0-18-00-00-31-47-D6-00-00-00-00-00-00-00-00
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:1546 (1.5 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1147 errors:0 dropped:0 overruns:0 frame:0
TX packets:1147 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1881940 (1.7 MiB) TX bytes:1881940 (1.7 MiB)

Voila, ca me semble operationnel sur mon PC.
Peut etre que ton controleur IEEE1394 n'est pas detecte...
que te donne lspci ,
++

Oui effectivement, la seule chose qui reste c'est de pouvoir charger le module au démarrage!

J'ai fait un man depmod mais pas moyen de comprendre comment marche cette commande. Si j'ai bien compris, il faut la lancer pour qu'elle crée un fichier d'information (pour les dépendance, par exemple ieee1394 et compagnie dans ce cas)ainsi la commande modprobe pourra lancer le module au démarrage(en faisant un alias eth3 eth1394 dans /etc/modprobe.conf !)

Je me trompe? Comment marche depmod?

insmod installe un module. Si ce module depend d'un autre module qui n'est pas charge, alors tu as une erreur.
On fait en fait des editions de liens dynamiques.
modprobe permet lui de gerer les dependances entre modules. Si un module a besoin d'un autre, alors il charge l'autre puis le module.
http://machard.org/traductions/module-init-tools/html/modprobe.html

eth1394 : une affaire reglee !
++

Tu cree un shell script appele eth1394 que tu mets sous /etc/init.d dans lequel tu mets ton insmod
ensuite tu cree un lien symbolique dessus dans /etc/rc5.d si tu vaux que ca soit lancer au level 5 (cad avec l'environnement graphique).
# ln -s /etc/init.d/eth1394 /etc/rc5.d/S99eth1394

le nombre, 99 ici, est l'ordre dans lequel est lance le script, ici en dernier...
++

De rien !

++

J'ai un peu joué avec eth1394... voilà mes 2 balles:

- effectivement, modprobe eth1394 ne marche pas, la solution, déjà mentionnée plus haut, est insmod /chemin/absolu/eth1394.ko
- dhcp ne marche pas avec une interface eth1394 (enfin, ça fait semblant de marcher mais les dhclient de l'autre côté ne voit rien), il faut configurer statiquement 🙁
- ça marche que entre 2 machines linux.. je n'ai pas réussi le tandem linux (FC5)/windows(XP)

voili voilà....

S'il y a qq1 qui est arrivé à faire mieux, je suis preneur.

J'ai essayé de faire :

insmod /lib/modules/$(uname -r)/kernel/drivers/ieee1394/eth1394.ko
Ceci afin de ne pas avoir a modifier le lancement lors d'un changemeent de noyau.

Sinon tout est fonctionnel dans mon cas! (sauf le nom des interfaces eth3-00 pour le firewire alors qu'il devrais être eth3 et parfois un mélange avec les autres dans la configuration reseau

ok, pour que modprobe eth1394 marche tout seul, il faut ajouter ça dans /etc/modprobe.conf:

alias eth1 eth1394
install eth1394 /sbin/insmod /lib/modules/`uname -r`/kernel/drivers/ieee1394/eth1394.ko

Mon problème, encore, dhcpd ne réponds pas aux requetes sur eth1394... probablement passqu'il dit :

eth1: unknown hardware address type 24

et pour cause:

[root@cygn ~]# ifconfig eth1
eth1      Link encap:UNSPEC  ...

des idées ??

Il y a une différence entre 'uname -r' et $(uname -r)?, dans mon cas cela marchais en copiant ce texte dans /etc/init.d/eth1394 (permissions modifiées par chmod a+x !). Par contre j'avais un message puisque j'avais un alias définit dans modprobe.conf et lorsqu'il définissait l'alias eth1394 n'était pas encore chargé (Erreur, chargement du périphérique retardé...)
Je vais tester cela...

il faut qu'un serveur dhcp soit lancé sur le firewire de ton XP. Je ne sais pas le faire mais en principe, tu ne peux pas utiliser celui de la freebox pour cette interface. Il me semble que le firewire doit être sur un sous reseau séparé. si tu as 0.254 pour la freebox ton pc fixe à 0.1 pour l'ethernet essaie d'avoir 5.1 pour le fixe en firewire via la passrelle.

kwizart a écrit :
Il y a une différence entre 'uname -r' et $(uname -r)?

je pense que c pareil... attention, les ` sont des "Alt_gr + 7" pas des ' !

dans mon cas cela marchais en copiant ce texte dans /etc/init.d/eth1394 (permissions modifiées par chmod a+x !). Par contre j'avais un message puisque j'avais un alias définit dans modprobe.conf et lorsqu'il définissait l'alias eth1394 n'était pas encore chargé (Erreur, chargement du périphérique retardé...)
Je vais tester cela...

Justement, la modif dans modprobe.conf evite cet erreur, en gros, elle te fait un alias global insmod /../eth1394.ko qui remplace modprobe eth1394.

il faut qu'un serveur dhcp soit lancé sur le firewire de ton XP. Je ne sais pas le faire mais en principe, tu ne peux pas utiliser celui de la freebox pour cette interface. Il me semble que le firewire doit être sur un sous reseau séparé. si tu as 0.254 pour la freebox ton pc fixe à 0.1 pour l'ethernet essaie d'avoir 5.1 pour le fixe en firewire via la passrelle.

Non,non c pas du tout ça.. je nai pas de freebox ni rien... mon serveur, FC5 est sur le réseau de mon labo et je branche mon portable dessus pare firewire. le bridge eth0 - eth1394 du serveur est fait par firestarter et marche nickel. Donc c le serveur FC5 qui doit attribuer un IP par DHCP à XP sur l'interface 1394, mais le serveur DHCPD n'aime pas les interface eth1394 on dirait. Donc, pour le moment je fait ça en statique et ça marche...

OK

Effectivement j'ai une inversion entre eth2 ipw2200 et eth3 eth1394. Je pense que c'est plus due à ipw2200 car au lancement il apparait comme dev10842 malgré eth2 dans le modprobe.conf (rmmod et modprobe ipw2200 le fait apparaitre comme eth3 et eth1394 comme eth2-00 ce qui est l'inverse de ce que je veux.)
Cela marche malgré le fait que eth3 est prévu pour avoir la configuration donnée au firewire.

Ce qui est étrange, c'est que j'ai cru que lors d'un reboot il avait bien prit eth3 pour le firewire. (et la bonne configuration ip ainsi que l'erreur de chargement du module que j'ai toujours, mais retardée).

Pas moyen de trouver pourquoi ipw2200 prend dev10842 au lieu d'eth2, j'utilise la version atrpms 1.1.0 du module, je ne sais pas si cela fonctionne mieux avec la version 1.1.2 mais cette version n'est pas disponible chez atrms-testing pour le dernier noyau (et j'arrive pas à compiler le src.rpm)