Salut,
J'ai une machine sous Debian GNU/Linux sur laquelle je ne veux pas udev
et qui s'en porte très bien ainsi.
Salut,
J'ai une machine sous Debian GNU/Linux sur laquelle je ne veux pas udev
et qui s'en porte très bien ainsi.
Salut,
J'ai une machine sous Debian GNU/Linux sur laquelle je ne veux pas udev
et qui s'en porte très bien ainsi.
J'ai une machine sous Debian GNU/Linux sur laquelle je ne veux pas udev
et qui s'en porte très bien ainsi. Mais je dois maintenant y connecter
un périphérique qui a besoin de firmwares, or apparemment c'est
normalement à udev qu'est dévolue la tâche de les charger à la demande
du noyau.
Existe-t-il une alternative simple qui ne ferait que ça ? Ou bien
devrais-je gribouiller un script infâme qui lit et écrit dans
/sys/class/firmware/, ou me résoudre à installer udev et apprendre
comment désactiver tous ses automatismes sauf le chargement des firmwares ?
ou me résoudre à installer udev et apprendre
comment désactiver tous ses automatismes sauf le chargement des firmwares ?
J'ai une machine sous Debian GNU/Linux sur laquelle je ne veux pas udev
et qui s'en porte très bien ainsi. Mais je dois maintenant y connecter
un périphérique qui a besoin de firmwares, or apparemment c'est
normalement à udev qu'est dévolue la tâche de les charger à la demande
du noyau.
Existe-t-il une alternative simple qui ne ferait que ça ? Ou bien
devrais-je gribouiller un script infâme qui lit et écrit dans
/sys/class/firmware/, ou me résoudre à installer udev et apprendre
comment désactiver tous ses automatismes sauf le chargement des firmwares ?
ou me résoudre à installer udev et apprendre
comment désactiver tous ses automatismes sauf le chargement des firmwares ?
J'ai une machine sous Debian GNU/Linux sur laquelle je ne veux pas udev
et qui s'en porte très bien ainsi. Mais je dois maintenant y connecter
un périphérique qui a besoin de firmwares, or apparemment c'est
normalement à udev qu'est dévolue la tâche de les charger à la demande
du noyau.
Existe-t-il une alternative simple qui ne ferait que ça ? Ou bien
devrais-je gribouiller un script infâme qui lit et écrit dans
/sys/class/firmware/, ou me résoudre à installer udev et apprendre
comment désactiver tous ses automatismes sauf le chargement des firmwares ?
ou me résoudre à installer udev et apprendre
comment désactiver tous ses automatismes sauf le chargement des firmwares ?
Pascal Hambourg wrote:J'ai une machine sous Debian GNU/Linux sur laquelle je ne veux pas udev
et qui s'en porte très bien ainsi.
Ton /dev est statique ou bien tu utilise un autre mécanisme pour le
peupler ?
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
J'ai une machine sous Debian GNU/Linux sur laquelle je ne veux pas udev
et qui s'en porte très bien ainsi.
Ton /dev est statique ou bien tu utilise un autre mécanisme pour le
peupler ?
Pascal Hambourg wrote:J'ai une machine sous Debian GNU/Linux sur laquelle je ne veux pas udev
et qui s'en porte très bien ainsi.
Ton /dev est statique ou bien tu utilise un autre mécanisme pour le
peupler ?
Pascal Hambourg wrote in message <i313m4$qtm$:J'ai une machine sous Debian GNU/Linux sur laquelle je ne veux pas udev
et qui s'en porte très bien ainsi. Mais je dois maintenant y connecter
un périphérique qui a besoin de firmwares, or apparemment c'est
normalement à udev qu'est dévolue la tâche de les charger à la demande
du noyau.
Existe-t-il une alternative simple qui ne ferait que ça ? Ou bien
devrais-je gribouiller un script infâme qui lit et écrit dans
/sys/class/firmware/, ou me résoudre à installer udev et apprendre
comment désactiver tous ses automatismes sauf le chargement des firmwares ?
Il y a deux choses :
- savoir quand le noyau demande un firmware ;
- charger le firmware demandé.
Pour le premier point, quand le noyau a besoin d'un firmware, il génère un
uevent, qui est communiqué à l'userland de deux manières différentes :
- En exécutant le programme pointé par le sysctl kernel.hotplug (par défaut
/sbin/hotplug, mais on peut le changer, statiquement ou dynamiquement).
Les paramètres sont alors dans les arguments ou l'environnement.
- En envoyant un message sur une socket netlink.
Le premier est clairement plus simple, mais il faut faire attention que les
uevents sont assez nombreux : chaque ajout ou suppression de matériel, mais
aussi chaque ajout ou suppression d'UID (parmi les processus existants).
Le second est plus compliqué, ne serait-ce que parce qu'il faut se
documenter sur comment les socket netlink marchent, mais il n'a pas cet
inconvénient. C'est pourquoi udev utilise netlink et désactive
kernel.hotplug. Mais ça exige un démon présent en permanence.
Pour le second point, charger le firmware, mon udev par défaut a la règle :
SUBSYSTEM=="firmware", RUN+="firmware.agent"
Et firmware.agent est un script qui, après quelques tests, fait :
echo 1 > /sys/$DEVPATH/loading
cat "$DIR/$FIRMWARE" > /sys/$DEVPATH/data
echo 0 > /sys/$DEVPATH/loading
Assez facile donc.
ou me résoudre à installer udev et apprendre
comment désactiver tous ses automatismes sauf le chargement des firmwares ?
C'est en fait assez facile : udev, c'est essentiellement udevd, un démon qui
écoute les uevents sur une socket netlink, et exécute des programmes ou crée
des noeuds en réaction à ces uevents.
Tout ce qu'udevd fait, il le fait en suivant une règle. Si ses répertoires
de règles sont vides, udevd ne fait strictement rien.
Après, il faut aussi dépatouiller un peu les scripts de lancement d'udevd,
parce que ce sont eux qui montent un tmpfs sur /dev/.
Pascal Hambourg wrote in message <i313m4$qtm$1@saria.nerim.net>:
J'ai une machine sous Debian GNU/Linux sur laquelle je ne veux pas udev
et qui s'en porte très bien ainsi. Mais je dois maintenant y connecter
un périphérique qui a besoin de firmwares, or apparemment c'est
normalement à udev qu'est dévolue la tâche de les charger à la demande
du noyau.
Existe-t-il une alternative simple qui ne ferait que ça ? Ou bien
devrais-je gribouiller un script infâme qui lit et écrit dans
/sys/class/firmware/, ou me résoudre à installer udev et apprendre
comment désactiver tous ses automatismes sauf le chargement des firmwares ?
Il y a deux choses :
- savoir quand le noyau demande un firmware ;
- charger le firmware demandé.
Pour le premier point, quand le noyau a besoin d'un firmware, il génère un
uevent, qui est communiqué à l'userland de deux manières différentes :
- En exécutant le programme pointé par le sysctl kernel.hotplug (par défaut
/sbin/hotplug, mais on peut le changer, statiquement ou dynamiquement).
Les paramètres sont alors dans les arguments ou l'environnement.
- En envoyant un message sur une socket netlink.
Le premier est clairement plus simple, mais il faut faire attention que les
uevents sont assez nombreux : chaque ajout ou suppression de matériel, mais
aussi chaque ajout ou suppression d'UID (parmi les processus existants).
Le second est plus compliqué, ne serait-ce que parce qu'il faut se
documenter sur comment les socket netlink marchent, mais il n'a pas cet
inconvénient. C'est pourquoi udev utilise netlink et désactive
kernel.hotplug. Mais ça exige un démon présent en permanence.
Pour le second point, charger le firmware, mon udev par défaut a la règle :
SUBSYSTEM=="firmware", RUN+="firmware.agent"
Et firmware.agent est un script qui, après quelques tests, fait :
echo 1 > /sys/$DEVPATH/loading
cat "$DIR/$FIRMWARE" > /sys/$DEVPATH/data
echo 0 > /sys/$DEVPATH/loading
Assez facile donc.
ou me résoudre à installer udev et apprendre
comment désactiver tous ses automatismes sauf le chargement des firmwares ?
C'est en fait assez facile : udev, c'est essentiellement udevd, un démon qui
écoute les uevents sur une socket netlink, et exécute des programmes ou crée
des noeuds en réaction à ces uevents.
Tout ce qu'udevd fait, il le fait en suivant une règle. Si ses répertoires
de règles sont vides, udevd ne fait strictement rien.
Après, il faut aussi dépatouiller un peu les scripts de lancement d'udevd,
parce que ce sont eux qui montent un tmpfs sur /dev/.
Pascal Hambourg wrote in message <i313m4$qtm$:J'ai une machine sous Debian GNU/Linux sur laquelle je ne veux pas udev
et qui s'en porte très bien ainsi. Mais je dois maintenant y connecter
un périphérique qui a besoin de firmwares, or apparemment c'est
normalement à udev qu'est dévolue la tâche de les charger à la demande
du noyau.
Existe-t-il une alternative simple qui ne ferait que ça ? Ou bien
devrais-je gribouiller un script infâme qui lit et écrit dans
/sys/class/firmware/, ou me résoudre à installer udev et apprendre
comment désactiver tous ses automatismes sauf le chargement des firmwares ?
Il y a deux choses :
- savoir quand le noyau demande un firmware ;
- charger le firmware demandé.
Pour le premier point, quand le noyau a besoin d'un firmware, il génère un
uevent, qui est communiqué à l'userland de deux manières différentes :
- En exécutant le programme pointé par le sysctl kernel.hotplug (par défaut
/sbin/hotplug, mais on peut le changer, statiquement ou dynamiquement).
Les paramètres sont alors dans les arguments ou l'environnement.
- En envoyant un message sur une socket netlink.
Le premier est clairement plus simple, mais il faut faire attention que les
uevents sont assez nombreux : chaque ajout ou suppression de matériel, mais
aussi chaque ajout ou suppression d'UID (parmi les processus existants).
Le second est plus compliqué, ne serait-ce que parce qu'il faut se
documenter sur comment les socket netlink marchent, mais il n'a pas cet
inconvénient. C'est pourquoi udev utilise netlink et désactive
kernel.hotplug. Mais ça exige un démon présent en permanence.
Pour le second point, charger le firmware, mon udev par défaut a la règle :
SUBSYSTEM=="firmware", RUN+="firmware.agent"
Et firmware.agent est un script qui, après quelques tests, fait :
echo 1 > /sys/$DEVPATH/loading
cat "$DIR/$FIRMWARE" > /sys/$DEVPATH/data
echo 0 > /sys/$DEVPATH/loading
Assez facile donc.
ou me résoudre à installer udev et apprendre
comment désactiver tous ses automatismes sauf le chargement des firmwares ?
C'est en fait assez facile : udev, c'est essentiellement udevd, un démon qui
écoute les uevents sur une socket netlink, et exécute des programmes ou crée
des noeuds en réaction à ces uevents.
Tout ce qu'udevd fait, il le fait en suivant une règle. Si ses répertoires
de règles sont vides, udevd ne fait strictement rien.
Après, il faut aussi dépatouiller un peu les scripts de lancement d'udevd,
parce que ce sont eux qui montent un tmpfs sur /dev/.
Le programme peut être
un script shell ?
Qu'entends-tu par là au juste ?
Oui, entre autres, c'est le genre de chose qui me fait un peu peur et me
retient d'y mettre le nez. Encore une usine à gaz qui ne me sert à
presque rien.
Le programme peut être
un script shell ?
Qu'entends-tu par là au juste ?
Oui, entre autres, c'est le genre de chose qui me fait un peu peur et me
retient d'y mettre le nez. Encore une usine à gaz qui ne me sert à
presque rien.
Le programme peut être
un script shell ?
Qu'entends-tu par là au juste ?
Oui, entre autres, c'est le genre de chose qui me fait un peu peur et me
retient d'y mettre le nez. Encore une usine à gaz qui ne me sert à
presque rien.
Donc par exemple, sur un serveur de mail, quand le MTA invoque le MDA sous
l'identité du destinataire, ça va provisoirement créer l'UID correspondant
au destinataire, donc générer deux uevents.
Oui, entre autres, c'est le genre de chose qui me fait un peu peur et me
retient d'y mettre le nez. Encore une usine à gaz qui ne me sert à
presque rien.
Justement, ce n'est pas tant une usine à gaz que ça. C'est même relativement
simple et élégant, comme design. Il y a un peu d'usine à gaz au niveau des
scripts qui usuellement l'invoquent, mais justement tu n'en veux pas.
Donc par exemple, sur un serveur de mail, quand le MTA invoque le MDA sous
l'identité du destinataire, ça va provisoirement créer l'UID correspondant
au destinataire, donc générer deux uevents.
Oui, entre autres, c'est le genre de chose qui me fait un peu peur et me
retient d'y mettre le nez. Encore une usine à gaz qui ne me sert à
presque rien.
Justement, ce n'est pas tant une usine à gaz que ça. C'est même relativement
simple et élégant, comme design. Il y a un peu d'usine à gaz au niveau des
scripts qui usuellement l'invoquent, mais justement tu n'en veux pas.
Donc par exemple, sur un serveur de mail, quand le MTA invoque le MDA sous
l'identité du destinataire, ça va provisoirement créer l'UID correspondant
au destinataire, donc générer deux uevents.
Oui, entre autres, c'est le genre de chose qui me fait un peu peur et me
retient d'y mettre le nez. Encore une usine à gaz qui ne me sert à
presque rien.
Justement, ce n'est pas tant une usine à gaz que ça. C'est même relativement
simple et élégant, comme design. Il y a un peu d'usine à gaz au niveau des
scripts qui usuellement l'invoquent, mais justement tu n'en veux pas.
Pour le premier point, quand le noyau a besoin d'un firmware, il génère un
uevent, qui est communiqué à l'userland de deux manières différentes :
- En exécutant le programme pointé par le sysctl kernel.hotplug (par défaut
/sbin/hotplug, mais on peut le changer, statiquement ou dynamiquement).
Les paramètres sont alors dans les arguments ou l'environnement.
/var/log/hotplug.log
Pour le premier point, quand le noyau a besoin d'un firmware, il génère un
uevent, qui est communiqué à l'userland de deux manières différentes :
- En exécutant le programme pointé par le sysctl kernel.hotplug (par défaut
/sbin/hotplug, mais on peut le changer, statiquement ou dynamiquement).
Les paramètres sont alors dans les arguments ou l'environnement.
/var/log/hotplug.log
Pour le premier point, quand le noyau a besoin d'un firmware, il génère un
uevent, qui est communiqué à l'userland de deux manières différentes :
- En exécutant le programme pointé par le sysctl kernel.hotplug (par défaut
/sbin/hotplug, mais on peut le changer, statiquement ou dynamiquement).
Les paramètres sont alors dans les arguments ou l'environnement.
/var/log/hotplug.log
Bon, j'ai écrit le script suivant qui a l'air de marcher :
#!/bin/sh
if [[ "$SUBSYSTEM" == "firmware" && "$ACTION" == "add" ]] ; then
Bon, j'ai écrit le script suivant qui a l'air de marcher :
#!/bin/sh
if [[ "$SUBSYSTEM" == "firmware" && "$ACTION" == "add" ]] ; then
Bon, j'ai écrit le script suivant qui a l'air de marcher :
#!/bin/sh
if [[ "$SUBSYSTEM" == "firmware" && "$ACTION" == "add" ]] ; then
La construction [[ ... == ... ]] n'est pas du sh standard. Par exemple, dash
ne la reconnaît pas.
La construction [[ ... == ... ]] n'est pas du sh standard. Par exemple, dash
ne la reconnaît pas.
La construction [[ ... == ... ]] n'est pas du sh standard. Par exemple, dash
ne la reconnaît pas.
Nicolas George a écrit :La construction [[ ... == ... ]] n'est pas du sh standard. Par exemple, dash
ne la reconnaît pas.
Il me semblait bien que c'était un "bashisme". Comme je n'écris pas du
shell tous les jours, j'ai repompé la tournure vite fait dans un vieux
script que j'avais écrit ; comme il y avait un joker dans un opérande,
je n'avais pas trouvé comment faire autrement
Nicolas George a écrit :
La construction [[ ... == ... ]] n'est pas du sh standard. Par exemple, dash
ne la reconnaît pas.
Il me semblait bien que c'était un "bashisme". Comme je n'écris pas du
shell tous les jours, j'ai repompé la tournure vite fait dans un vieux
script que j'avais écrit ; comme il y avait un joker dans un opérande,
je n'avais pas trouvé comment faire autrement
Nicolas George a écrit :La construction [[ ... == ... ]] n'est pas du sh standard. Par exemple, dash
ne la reconnaît pas.
Il me semblait bien que c'était un "bashisme". Comme je n'écris pas du
shell tous les jours, j'ai repompé la tournure vite fait dans un vieux
script que j'avais écrit ; comme il y avait un joker dans un opérande,
je n'avais pas trouvé comment faire autrement