Fonctionnement réel de ndiswrapper
Résolu/Fermé
ed
-
15 mai 2015 à 09:25
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 17 mai 2015 à 14:42
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 17 mai 2015 à 14:42
6 réponses
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
Modifié par mamiemando le 15/05/2015 à 12:57
Modifié par mamiemando le 15/05/2015 à 12:57
J'ai entendu dire que c'était une machine virtuelle de pilotes Windows : c'est faux non ?
En effet c'est faux. Car ndiswrapper produit un module, chargé par le noyau linux, et donc il ne s'agit pas d'une machine virtuelle.
Il consiste à envelopper (wrapper) un pilote windows pour le rendre conforme à l'API (interface) NDIS qui va être utilisée par le noyau linux pour faire appel au pilote. Il n'y a aucune virtualisation car c'est directement linké, donc il n'y a pas de machine virtuelle pour permettre au pilote et au noyau de se parler :
https://en.wikipedia.org/wiki/NDISwrapper
De toute façon les pilotes ne fonctionnent pas tant que ndis n'est pas lancé, ce qui me laisse à supposer qu'il lance des plugins à lui.
En fait il garder à l'esprit qu'un module est un moceau de noyau. Son homologue windows le plus proche serait un pilote, mais un module est une notion plus générale, notamment car :
- contrairement à un pilote on peut le charger ou décharger à volonté,
- certains modules ne sont pas forcément dédiés à prendre en charge du matériel (ça peut être par exemple un système de fichiers)
- les modules peuvent s'appuyer les uns sur les autres
- etc...
Tu peux avoir un aperçu de la liste des modules qui sont chargés avec la commande
Si un module est déchargé, ce qu'il gère n'est plus pris en charge. Dans ton cas si ta carte wifi est prise en charge par ndiswrapper, alors si tu décharges ce module, alors elle n'est plus supportée.
De toute façon les pilotes ne fonctionnent pas tant que ndis n'est pas lancé, ce qui me laisse à supposer qu'il lance des plugins à lui.
Normalement à ce stade tu as dû comprendre qu'il n'y a pas de plugins ou autre, juste un module. De plus on ne pourrait pas dans le cas d'un noyau ou de modules parler de plugins, ce n'est pas le bon terme.
Un plugin (ou greffon) est relatif à une application (un navigateur, un lecteur de vidéo, un lecteur de musique) pour lui permettre de supporter des fonctionnalités supplémentaires (un format de vidéo ou de musique, des outils supplémentaires, etc.)
Dans le cas qui nous intéresse il y a juste le noyau et des modules.
Bonne chance
En effet c'est faux. Car ndiswrapper produit un module, chargé par le noyau linux, et donc il ne s'agit pas d'une machine virtuelle.
Il consiste à envelopper (wrapper) un pilote windows pour le rendre conforme à l'API (interface) NDIS qui va être utilisée par le noyau linux pour faire appel au pilote. Il n'y a aucune virtualisation car c'est directement linké, donc il n'y a pas de machine virtuelle pour permettre au pilote et au noyau de se parler :
https://en.wikipedia.org/wiki/NDISwrapper
De toute façon les pilotes ne fonctionnent pas tant que ndis n'est pas lancé, ce qui me laisse à supposer qu'il lance des plugins à lui.
En fait il garder à l'esprit qu'un module est un moceau de noyau. Son homologue windows le plus proche serait un pilote, mais un module est une notion plus générale, notamment car :
- contrairement à un pilote on peut le charger ou décharger à volonté,
- certains modules ne sont pas forcément dédiés à prendre en charge du matériel (ça peut être par exemple un système de fichiers)
- les modules peuvent s'appuyer les uns sur les autres
- etc...
Tu peux avoir un aperçu de la liste des modules qui sont chargés avec la commande
lsmod.
Si un module est déchargé, ce qu'il gère n'est plus pris en charge. Dans ton cas si ta carte wifi est prise en charge par ndiswrapper, alors si tu décharges ce module, alors elle n'est plus supportée.
De toute façon les pilotes ne fonctionnent pas tant que ndis n'est pas lancé, ce qui me laisse à supposer qu'il lance des plugins à lui.
Normalement à ce stade tu as dû comprendre qu'il n'y a pas de plugins ou autre, juste un module. De plus on ne pourrait pas dans le cas d'un noyau ou de modules parler de plugins, ce n'est pas le bon terme.
Un plugin (ou greffon) est relatif à une application (un navigateur, un lecteur de vidéo, un lecteur de musique) pour lui permettre de supporter des fonctionnalités supplémentaires (un format de vidéo ou de musique, des outils supplémentaires, etc.)
Dans le cas qui nous intéresse il y a juste le noyau et des modules.
Bonne chance
En fait, pour reprendre la terminologie de Windows, un module est un "driver" et un "service" (système ou non) à la fois c'est ça ?
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
15 mai 2015 à 21:45
15 mai 2015 à 21:45
Disons plutôt qu'un driver est un cas particulier de module. Comme je le disais avant, un module est un morceau de noyau externalisé, qu'on peut charger ou décharger à volonté. Il peut prendre en charge du matériel, un système de fichiers, certaines primitives réseau ou de cryptographie, etc.
Ensuite on passe dans le monde du système d'exploitation, qui fait l'interface entre l'utilisateur et les couches inférieures (le noyau + les modules, et encore en dessous le matériel). Cette interface peut consister à fournir des logiciels à l'utilisateur, graphiques ou en mode texte (qui sont alors tout simplement des commandes, comme
Certains logiciels doivent être lancés ou éteints sous certaines conditions (par exemple au démarrage ou à l'extinction de la machine). Dans ce cas, il faut les intégrer dans la chaîne de démarrage du système d'exploitation, et c'est le rôle des services.
Un service a à peu près le même sens sous linux ou windows : il sert à lancer en arrière plan un programme. C'est donc une notion propre au système d'exploitation (et donc pas au noyau). La différence principale réside dans la manière dont c'est réalisé.
- Sous windows c'est une fenêtre qui permet de gérer de manière opaque ce qui se passe en arrière boutique
- Sous linux, un service est instancié conformément aux liens symboliques définis dans les répertoires
Chacun de ces liens symboliques pointe sur un script stocké dans
Exemple : le service
Note que de nos jours on peut souvent écrire :
Un démon est un programme qui tourne en arrière plan, par exemple un serveur (ssh, ftp, web, etc...) mais il existe des services qui ont d'autres rôle (tu peux aller voir dans
Bonne chance
Ensuite on passe dans le monde du système d'exploitation, qui fait l'interface entre l'utilisateur et les couches inférieures (le noyau + les modules, et encore en dessous le matériel). Cette interface peut consister à fournir des logiciels à l'utilisateur, graphiques ou en mode texte (qui sont alors tout simplement des commandes, comme
lsou
rm).
Certains logiciels doivent être lancés ou éteints sous certaines conditions (par exemple au démarrage ou à l'extinction de la machine). Dans ce cas, il faut les intégrer dans la chaîne de démarrage du système d'exploitation, et c'est le rôle des services.
Un service a à peu près le même sens sous linux ou windows : il sert à lancer en arrière plan un programme. C'est donc une notion propre au système d'exploitation (et donc pas au noyau). La différence principale réside dans la manière dont c'est réalisé.
- Sous windows c'est une fenêtre qui permet de gérer de manière opaque ce qui se passe en arrière boutique
- Sous linux, un service est instancié conformément aux liens symboliques définis dans les répertoires
/etc/rc*.d, dont chacun correspond à un runlevel. En outre l'un des runlevel consiste à "la machine démarre avec un minimum de service", "la machine démarre normalement", "la machine s'éteint", "la machine redémarre" etc.
Chacun de ces liens symboliques pointe sur un script stocké dans
/etc/init.d. Ce script est appelé service le script et permet de lancer, stopper, ou redémarrer un démon.
Exemple : le service
/etc/init.d/sshpermet de piloter le démon
/usr/sbin/sshd(serveur ssh).
/etc/init.d/ssh start
/etc/init.d/ssh stop
/etc/init.d/ssh restart
Note que de nos jours on peut souvent écrire :
service ssh start
service ssh stop
service ssh restart
Un démon est un programme qui tourne en arrière plan, par exemple un serveur (ssh, ftp, web, etc...) mais il existe des services qui ont d'autres rôle (tu peux aller voir dans
/etc/init.dpour te faire une idée). Généralement son nom se termine généralement par d, comme daemon.
Bonne chance
Merci à toi pour la réponse.
Une petite minute : sur la doc d'Ubuntu ils disent que le fichier xorg.conf est utilisé QUAND LE SERVEUR X11 SE LANCE : il est bien naturelle que si je lance ndis en spécifiant le pilote ça foire.
Non : ce qu'il faudrait c'est que je réussisse à lancer ndis AVANT QUE LE SERVEUR X11 NE SE LANCE.
De cette manière le pilote graphique serait exploitable je pense.
Maintenant comment lancer ndis avant X11 ? Là-dessus je pense que tu peux m'aider ;)
Une petite minute : sur la doc d'Ubuntu ils disent que le fichier xorg.conf est utilisé QUAND LE SERVEUR X11 SE LANCE : il est bien naturelle que si je lance ndis en spécifiant le pilote ça foire.
Non : ce qu'il faudrait c'est que je réussisse à lancer ndis AVANT QUE LE SERVEUR X11 NE SE LANCE.
De cette manière le pilote graphique serait exploitable je pense.
Maintenant comment lancer ndis avant X11 ? Là-dessus je pense que tu peux m'aider ;)
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
Modifié par mamiemando le 16/05/2015 à 11:58
Modifié par mamiemando le 16/05/2015 à 11:58
Tu mélanges deux choses qui sont indépendantes. X11 est le serveur graphique. Il n'a rien à avoir avec ndiswrapper, ils vivent une existence en parallèle.
ndiswrapper est un module donc il n'a aucunement besoin que X11 soit lancé. C'est assez logique, car ta carte wifi est sensée pouvoir marcher même si tu n'as pas installé de mode graphique.
Les modules sont parmi les premières choses chargées au démarrage de linux. Au besoin tu peux en expliciter certains dans
Ceci dit, les noyaux actuels sont capables de charger automatiquement les modules dont ils ont besoin, donc en général tu n'as même plus besoin de configurer ce fichier. Une fois le noyau chargé, celui-ci lance le système d'exploitation a proprement parler en lançant le processus
Ceci est réalisé par
Parmi tous ces scripts, si tu installes une interface graphique, se trouvera un gestionnaire de connexion dont les noms sont de la forme
Comme tu le vois, le chargement de X11 arrive bien après celui des modules, dont ndiswrapper. Ceci dit, rien n'empêcherait de laisser la machine démarrer normalement, et si ndiswrapper n'a pas été chargé automatiquement, lancé a posteriori la commande
Enfin concernant
Quoi qu'il en soit le module de ta carte vidéo à proprement parlé est probablement déjà chargé à ce stade (par exemple
Bonne chance
ndiswrapper est un module donc il n'a aucunement besoin que X11 soit lancé. C'est assez logique, car ta carte wifi est sensée pouvoir marcher même si tu n'as pas installé de mode graphique.
Les modules sont parmi les premières choses chargées au démarrage de linux. Au besoin tu peux en expliciter certains dans
/etc/modules(par exemple en ajoutant
ndiswrapper, si c'est le nom du module, en fin de fichier).
Ceci dit, les noyaux actuels sont capables de charger automatiquement les modules dont ils ont besoin, donc en général tu n'as même plus besoin de configurer ce fichier. Une fois le noyau chargé, celui-ci lance le système d'exploitation a proprement parler en lançant le processus
init. C'est lui qui va notamment lire
/etc/inittab, en déduire quel runlevel utiliser et donc quel
/etc/rc*.dexaminer.
Ceci est réalisé par
/etc/init.d/rc. Ce script va, à partir des noms des liens symboliques qui y sont stockés, déterminer dans quel ordre piloter les services, puis leur passer le paramètre
startou
stop. Rappelons que ces liens pointe sur un script contenu dans
/etc/init.d
Parmi tous ces scripts, si tu installes une interface graphique, se trouvera un gestionnaire de connexion dont les noms sont de la forme
/etc/init.d/*dm(typiquement
gdm,
kdm,
xdm,
lightdm). Le gestionnaire de connexion lance ensuite xorg (alias X11) en faisant l'équivalent d'un
startxen y affichant la fenêtre de connexion.
Comme tu le vois, le chargement de X11 arrive bien après celui des modules, dont ndiswrapper. Ceci dit, rien n'empêcherait de laisser la machine démarrer normalement, et si ndiswrapper n'a pas été chargé automatiquement, lancé a posteriori la commande
modprobe ndiswrapper(en root ou avec
sudo).
Enfin concernant
/etc/X11/xorg.conf, il s'agit du fichier qui spécifie quel "confgure" xorg utilisé. De nos jours il est très souvent optionnel car Xorg se paramètre automatiquement, même s'il peut arriver dans de rare cas qu'il faille lui expliciter deux trois paramètres. C'est uniquement dans ce cas que le fichier devient pertinent.
Quoi qu'il en soit le module de ta carte vidéo à proprement parlé est probablement déjà chargé à ce stade (par exemple
nouveauou
nvidiapour une carte nvidia). Ce module n'a, quoi qu'il en soit, aucune dépendance avec ndiswrapper (ni le contraire). Ce sont encore une fois deux choses qui vivent indépendamment. Du coup, chercher un rapport entre X11 et ndiswrapper est une fausse piste.
Bonne chance
Bonjour,
Peut-on poursuivre la conversion dans ce topic : https://forums.commentcamarche.net/forum/affich-31964022-ndiswrapper-pilote-graphique-comment-specifier ?
Merci à toi.
Peut-on poursuivre la conversion dans ce topic : https://forums.commentcamarche.net/forum/affich-31964022-ndiswrapper-pilote-graphique-comment-specifier ?
Merci à toi.
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
17 mai 2015 à 14:42
17 mai 2015 à 14:42
Ok je clos celui-ci.
