Je n'ai pas de beep système alors que:
1. Mon serveur de son est compilé dans mon noyau.
2. Je n'ai aucun soucis pour utiliser les médias sonores.
3. J'ai bien installé le package "beep".
4. J'ai bien les droits et ça ne marche pas non plus sous root d'ailleurs.
Que dire de plus?
Je n'ai pas de beep système alors que:
1. Mon serveur de son est compilé dans mon noyau.
2. Je n'ai aucun soucis pour utiliser les médias sonores.
3. J'ai bien installé le package "beep".
4. J'ai bien les droits et ça ne marche pas non plus sous root d'ailleurs.
Que dire de plus?
Je n'ai pas de beep système alors que:
1. Mon serveur de son est compilé dans mon noyau.
2. Je n'ai aucun soucis pour utiliser les médias sonores.
3. J'ai bien installé le package "beep".
4. J'ai bien les droits et ça ne marche pas non plus sous root d'ailleurs.
Que dire de plus?
Bonjour à tous,
Je n'ai pas de beep système alors que:
1. Mon serveur de son est compilé dans mon noyau.
2. Je n'ai aucun soucis pour utiliser les médias sonores.
3. J'ai bien installé le package "beep".
4. J'ai bien les droits et ça ne marche pas non plus sous root d'ailleu rs.
Que dire de plus?
Merci d'avance.
--
Stevan Kanban
Bonjour à tous,
Je n'ai pas de beep système alors que:
1. Mon serveur de son est compilé dans mon noyau.
2. Je n'ai aucun soucis pour utiliser les médias sonores.
3. J'ai bien installé le package "beep".
4. J'ai bien les droits et ça ne marche pas non plus sous root d'ailleu rs.
Que dire de plus?
Merci d'avance.
--
Stevan Kanban
Bonjour à tous,
Je n'ai pas de beep système alors que:
1. Mon serveur de son est compilé dans mon noyau.
2. Je n'ai aucun soucis pour utiliser les médias sonores.
3. J'ai bien installé le package "beep".
4. J'ai bien les droits et ça ne marche pas non plus sous root d'ailleu rs.
Que dire de plus?
Merci d'avance.
--
Stevan Kanban
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le vendredi 4 Février 2005 02:36, Stevan Kanban a écrit :
> Bonjour à tous,
>
> Je n'ai pas de beep système alors que:
> 1. Mon serveur de son est compilé dans mon noyau.
> 2. Je n'ai aucun soucis pour utiliser les médias sonores.
> 3. J'ai bien installé le package "beep".
> 4. J'ai bien les droits et ça ne marche pas non plus sous root d'ailleurs.
> Que dire de plus?
> Merci d'avance.
modprobe pcspkr ???
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le vendredi 4 Février 2005 02:36, Stevan Kanban a écrit :
> Bonjour à tous,
>
> Je n'ai pas de beep système alors que:
> 1. Mon serveur de son est compilé dans mon noyau.
> 2. Je n'ai aucun soucis pour utiliser les médias sonores.
> 3. J'ai bien installé le package "beep".
> 4. J'ai bien les droits et ça ne marche pas non plus sous root d'ailleurs.
> Que dire de plus?
> Merci d'avance.
modprobe pcspkr ???
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le vendredi 4 Février 2005 02:36, Stevan Kanban a écrit :
> Bonjour à tous,
>
> Je n'ai pas de beep système alors que:
> 1. Mon serveur de son est compilé dans mon noyau.
> 2. Je n'ai aucun soucis pour utiliser les médias sonores.
> 3. J'ai bien installé le package "beep".
> 4. J'ai bien les droits et ça ne marche pas non plus sous root d'ailleurs.
> Que dire de plus?
> Merci d'avance.
modprobe pcspkr ???
>
On Fri, Feb 04, 2005 at 09:31:11AM +0100, christophe wrote :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Le vendredi 4 Février 2005 02:36, Stevan Kanban a écrit :
> > Bonjour à tous,
> >
> > Je n'ai pas de beep système alors que:
> > 1. Mon serveur de son est compilé dans mon noyau.
> > 2. Je n'ai aucun soucis pour utiliser les médias sonores.
> > 3. J'ai bien installé le package "beep".
> > 4. J'ai bien les droits et ça ne marche pas non plus sous root
> > d'ailleurs. Que dire de plus?
> > Merci d'avance.
>
> modprobe pcspkr ???
Pour l'histoire du câble relié à la carte mère, j'ai quand même le beep au
démarrage, les alarmes en cas de surchauffe. Est-ce le même beep que celui
géré par le packetage, avec donc des possibilités en terme de dur ée et de
fréquence, je ne le sais pas. J'ai aussi par exemple la cloche console qui
beep lorsque je l'autorise dans la configuration de Konsole. Concernant le
module de noyau pcspkr, il me dit qu'il n'existe pas(#modprobe pcspkr).
Pourtant il est bien présent dans le source et dans la lib installée
lorsque je dépackage mon noyau à la sauce débian:
# grep -R pcspkr /lib/modules/2.6.7-hector-0.3/*
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/Kconfig: module
will be called pcspkr.
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static ch ar
pcspkr_name[] = "PC Speaker";
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static ch ar
pcspkr_phys[] = "isa0061/input0";
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static
struct input_dev pcspkr_dev;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static int
pcspkr_event(struct input_dev *dev, unsigned int type, unsigned int code,
int value)
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static int
__init pcspkr_init(void)
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.evbit[0] = BIT(EV_SND);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.sndbit[0] = BIT(SND_BELL) | BIT(SND_TONE);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.event = pcspkr_event;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.name = pcspkr_name;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.phys = pcspkr_phys;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.id.bustype = BUS_ISA;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.id.vendor = 0x001f;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.id.product = 0x0001;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.id.version = 0x0100;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
input_register_device(&pcspkr_dev);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
printk(KERN_INFO "input: %sn", pcspkr_name);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static vo id
__exit pcspkr_exit(void)
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
input_unregister_device(&pcspkr_dev);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:module_in it
(pcspkr_init);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:module_ex it
(pcspkr_exit);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/Makefile:obj-$(CON FI
G_INPUT_PCSPKR) += pcspkr.o
Il ne connais pas le fichier pcspkr.o. Il ne l'aurait donc pas compilé? Or
il est dans /lib/modules/... Là je ne comprends pas.
--
Stevan Kanban
On Fri, Feb 04, 2005 at 09:31:11AM +0100, christophe wrote :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Le vendredi 4 Février 2005 02:36, Stevan Kanban a écrit :
> > Bonjour à tous,
> >
> > Je n'ai pas de beep système alors que:
> > 1. Mon serveur de son est compilé dans mon noyau.
> > 2. Je n'ai aucun soucis pour utiliser les médias sonores.
> > 3. J'ai bien installé le package "beep".
> > 4. J'ai bien les droits et ça ne marche pas non plus sous root
> > d'ailleurs. Que dire de plus?
> > Merci d'avance.
>
> modprobe pcspkr ???
Pour l'histoire du câble relié à la carte mère, j'ai quand même le beep au
démarrage, les alarmes en cas de surchauffe. Est-ce le même beep que celui
géré par le packetage, avec donc des possibilités en terme de dur ée et de
fréquence, je ne le sais pas. J'ai aussi par exemple la cloche console qui
beep lorsque je l'autorise dans la configuration de Konsole. Concernant le
module de noyau pcspkr, il me dit qu'il n'existe pas(#modprobe pcspkr).
Pourtant il est bien présent dans le source et dans la lib installée
lorsque je dépackage mon noyau à la sauce débian:
# grep -R pcspkr /lib/modules/2.6.7-hector-0.3/*
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/Kconfig: module
will be called pcspkr.
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static ch ar
pcspkr_name[] = "PC Speaker";
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static ch ar
pcspkr_phys[] = "isa0061/input0";
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static
struct input_dev pcspkr_dev;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static int
pcspkr_event(struct input_dev *dev, unsigned int type, unsigned int code,
int value)
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static int
__init pcspkr_init(void)
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.evbit[0] = BIT(EV_SND);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.sndbit[0] = BIT(SND_BELL) | BIT(SND_TONE);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.event = pcspkr_event;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.name = pcspkr_name;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.phys = pcspkr_phys;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.id.bustype = BUS_ISA;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.id.vendor = 0x001f;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.id.product = 0x0001;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.id.version = 0x0100;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
input_register_device(&pcspkr_dev);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
printk(KERN_INFO "input: %sn", pcspkr_name);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static vo id
__exit pcspkr_exit(void)
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
input_unregister_device(&pcspkr_dev);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:module_in it
(pcspkr_init);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:module_ex it
(pcspkr_exit);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/Makefile:obj-$(CON FI
G_INPUT_PCSPKR) += pcspkr.o
Il ne connais pas le fichier pcspkr.o. Il ne l'aurait donc pas compilé? Or
il est dans /lib/modules/... Là je ne comprends pas.
--
Stevan Kanban
On Fri, Feb 04, 2005 at 09:31:11AM +0100, christophe wrote :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Le vendredi 4 Février 2005 02:36, Stevan Kanban a écrit :
> > Bonjour à tous,
> >
> > Je n'ai pas de beep système alors que:
> > 1. Mon serveur de son est compilé dans mon noyau.
> > 2. Je n'ai aucun soucis pour utiliser les médias sonores.
> > 3. J'ai bien installé le package "beep".
> > 4. J'ai bien les droits et ça ne marche pas non plus sous root
> > d'ailleurs. Que dire de plus?
> > Merci d'avance.
>
> modprobe pcspkr ???
Pour l'histoire du câble relié à la carte mère, j'ai quand même le beep au
démarrage, les alarmes en cas de surchauffe. Est-ce le même beep que celui
géré par le packetage, avec donc des possibilités en terme de dur ée et de
fréquence, je ne le sais pas. J'ai aussi par exemple la cloche console qui
beep lorsque je l'autorise dans la configuration de Konsole. Concernant le
module de noyau pcspkr, il me dit qu'il n'existe pas(#modprobe pcspkr).
Pourtant il est bien présent dans le source et dans la lib installée
lorsque je dépackage mon noyau à la sauce débian:
# grep -R pcspkr /lib/modules/2.6.7-hector-0.3/*
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/Kconfig: module
will be called pcspkr.
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static ch ar
pcspkr_name[] = "PC Speaker";
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static ch ar
pcspkr_phys[] = "isa0061/input0";
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static
struct input_dev pcspkr_dev;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static int
pcspkr_event(struct input_dev *dev, unsigned int type, unsigned int code,
int value)
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static int
__init pcspkr_init(void)
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.evbit[0] = BIT(EV_SND);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.sndbit[0] = BIT(SND_BELL) | BIT(SND_TONE);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.event = pcspkr_event;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.name = pcspkr_name;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.phys = pcspkr_phys;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.id.bustype = BUS_ISA;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.id.vendor = 0x001f;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.id.product = 0x0001;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
pcspkr_dev.id.version = 0x0100;
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
input_register_device(&pcspkr_dev);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
printk(KERN_INFO "input: %sn", pcspkr_name);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:static vo id
__exit pcspkr_exit(void)
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:
input_unregister_device(&pcspkr_dev);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:module_in it
(pcspkr_init);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/pcspkr.c:module_ex it
(pcspkr_exit);
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/Makefile:obj-$(CON FI
G_INPUT_PCSPKR) += pcspkr.o
Il ne connais pas le fichier pcspkr.o. Il ne l'aurait donc pas compilé? Or
il est dans /lib/modules/... Là je ne comprends pas.
--
Stevan Kanban
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/Makefile:obj-$
(CONFIG_INPUT_PCSPKR) += pcspkr.o
Il ne connais pas le fichier pcspkr.o. Il ne l'aurait donc pas
compilé? Or il est dans /lib/modules/... Là je ne comprends
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/Makefile:obj-$
(CONFIG_INPUT_PCSPKR) += pcspkr.o
Il ne connais pas le fichier pcspkr.o. Il ne l'aurait donc pas
compilé? Or il est dans /lib/modules/... Là je ne comprends
/lib/modules/2.6.7-hector-0.3/build/drivers/input/misc/Makefile:obj-$
(CONFIG_INPUT_PCSPKR) += pcspkr.o
Il ne connais pas le fichier pcspkr.o. Il ne l'aurait donc pas
compilé? Or il est dans /lib/modules/... Là je ne comprends
> Je ne sais pas comment ça marche sous debian, mais il me semble que le
dossier /lib/modules/<kernelversion>/build pointe quelque part dans les
sources du noyau (/usr/src/linux...?). Dites-moi si je me trompe.
Donc la commande que tu as lancée trouve des références dans le code du kernel
et non dans les modules compilés. Donc le module n'est pas compilé à moins
que la fonction ne soit dans le kernel ??? Il ne reste donc qu'à compiler le
module et à le charger au démarrage en insérant la ligne pcspkr
dans /etc/modprobe.preload ou à le compiler dans le kernel si besoin... Dites
moi si je me trompe....
> Je ne sais pas comment ça marche sous debian, mais il me semble que le
dossier /lib/modules/<kernelversion>/build pointe quelque part dans les
sources du noyau (/usr/src/linux...?). Dites-moi si je me trompe.
Donc la commande que tu as lancée trouve des références dans le code du kernel
et non dans les modules compilés. Donc le module n'est pas compilé à moins
que la fonction ne soit dans le kernel ??? Il ne reste donc qu'à compiler le
module et à le charger au démarrage en insérant la ligne pcspkr
dans /etc/modprobe.preload ou à le compiler dans le kernel si besoin... Dites
moi si je me trompe....
> Je ne sais pas comment ça marche sous debian, mais il me semble que le
dossier /lib/modules/<kernelversion>/build pointe quelque part dans les
sources du noyau (/usr/src/linux...?). Dites-moi si je me trompe.
Donc la commande que tu as lancée trouve des références dans le code du kernel
et non dans les modules compilés. Donc le module n'est pas compilé à moins
que la fonction ne soit dans le kernel ??? Il ne reste donc qu'à compiler le
module et à le charger au démarrage en insérant la ligne pcspkr
dans /etc/modprobe.preload ou à le compiler dans le kernel si besoin... Dites
moi si je me trompe....
Je ne sais pas comment ça marche sous debian, mais il me semble que le
dossier /lib/modules/<kernelversion>/build pointe quelque part dans les
sources du noyau (/usr/src/linux...?). Dites-moi si je me trompe.
Donc la commande que tu as lancée trouve des références dans le code du kernel
et non dans les modules compilés. Donc le module n'est pas compilé à moins
que la fonction ne soit dans le kernel ??? Il ne reste donc qu'à compiler le
module et à le charger au démarrage en insérant la ligne pcspkr
dans /etc/modprobe.preload ou à le compiler dans le kernel si besoin... Dites
moi si je me trompe....
J'ai des éléments de réflexion:
1. Effectivement, le fichier pcspkr.c n'a pas "oublié" d'être compilé mais c'est tout bonnement un lien vers les sources du
kernel. Il est donc dans /usr/src/linux/drivers/input/misc/.
Il faut donc que je le recompile à part ou alors que je recompile tout le noyau avec la nouvelle option pcspkr dans
menuconfig (à propos, je ne l'ai pas trouvé dans le fichier /usr/src/linux/arch/i386/defconfig et l'aide de menucongig ne
dit pas son nom). Donc ça devrait bien marcher (ça compile pour le moment :) ).
2. Bon, là je recompile tout mon noyau car j'avais d'autres modifs à faire. Néanmoins, il y a quelques points que je ne
comprends pas:
A. Je peux recompiler un source comme pcspkr.c avec gcc. Mais j'obtiendrai alors pcspkr.o. Or, j'ai crû comprendre
que dans les noyaux à partir du 2.6, les modules étaient en .ko et non pas en .o. Tout d'abord, fichier.ko est bien tout
simplement un fichier source compilé, n'est-ce-pas? Comment l'obtenir à partir du source (et non pas avec make-kpkg)?
Comment l'intégrer aux modules? En le copiant-collant à la bonne place dans /lib/modules/mes_modules/...?
B. Le fait de modifier directement dans /usr/src/linux/arch/i386/defconfig une option et de recompiler ensuite, ça
prend en compte ou pas? J'ai fait un test et ça ne prend pas en compte la modif. Mon noyau recompilé est le même que le
précédent. Alors pourquoi?
Je ne sais pas comment ça marche sous debian, mais il me semble que le
dossier /lib/modules/<kernelversion>/build pointe quelque part dans les
sources du noyau (/usr/src/linux...?). Dites-moi si je me trompe.
Donc la commande que tu as lancée trouve des références dans le code du kernel
et non dans les modules compilés. Donc le module n'est pas compilé à moins
que la fonction ne soit dans le kernel ??? Il ne reste donc qu'à compiler le
module et à le charger au démarrage en insérant la ligne pcspkr
dans /etc/modprobe.preload ou à le compiler dans le kernel si besoin... Dites
moi si je me trompe....
J'ai des éléments de réflexion:
1. Effectivement, le fichier pcspkr.c n'a pas "oublié" d'être compilé mais c'est tout bonnement un lien vers les sources du
kernel. Il est donc dans /usr/src/linux/drivers/input/misc/.
Il faut donc que je le recompile à part ou alors que je recompile tout le noyau avec la nouvelle option pcspkr dans
menuconfig (à propos, je ne l'ai pas trouvé dans le fichier /usr/src/linux/arch/i386/defconfig et l'aide de menucongig ne
dit pas son nom). Donc ça devrait bien marcher (ça compile pour le moment :) ).
2. Bon, là je recompile tout mon noyau car j'avais d'autres modifs à faire. Néanmoins, il y a quelques points que je ne
comprends pas:
A. Je peux recompiler un source comme pcspkr.c avec gcc. Mais j'obtiendrai alors pcspkr.o. Or, j'ai crû comprendre
que dans les noyaux à partir du 2.6, les modules étaient en .ko et non pas en .o. Tout d'abord, fichier.ko est bien tout
simplement un fichier source compilé, n'est-ce-pas? Comment l'obtenir à partir du source (et non pas avec make-kpkg)?
Comment l'intégrer aux modules? En le copiant-collant à la bonne place dans /lib/modules/mes_modules/...?
B. Le fait de modifier directement dans /usr/src/linux/arch/i386/defconfig une option et de recompiler ensuite, ça
prend en compte ou pas? J'ai fait un test et ça ne prend pas en compte la modif. Mon noyau recompilé est le même que le
précédent. Alors pourquoi?
Je ne sais pas comment ça marche sous debian, mais il me semble que le
dossier /lib/modules/<kernelversion>/build pointe quelque part dans les
sources du noyau (/usr/src/linux...?). Dites-moi si je me trompe.
Donc la commande que tu as lancée trouve des références dans le code du kernel
et non dans les modules compilés. Donc le module n'est pas compilé à moins
que la fonction ne soit dans le kernel ??? Il ne reste donc qu'à compiler le
module et à le charger au démarrage en insérant la ligne pcspkr
dans /etc/modprobe.preload ou à le compiler dans le kernel si besoin... Dites
moi si je me trompe....
J'ai des éléments de réflexion:
1. Effectivement, le fichier pcspkr.c n'a pas "oublié" d'être compilé mais c'est tout bonnement un lien vers les sources du
kernel. Il est donc dans /usr/src/linux/drivers/input/misc/.
Il faut donc que je le recompile à part ou alors que je recompile tout le noyau avec la nouvelle option pcspkr dans
menuconfig (à propos, je ne l'ai pas trouvé dans le fichier /usr/src/linux/arch/i386/defconfig et l'aide de menucongig ne
dit pas son nom). Donc ça devrait bien marcher (ça compile pour le moment :) ).
2. Bon, là je recompile tout mon noyau car j'avais d'autres modifs à faire. Néanmoins, il y a quelques points que je ne
comprends pas:
A. Je peux recompiler un source comme pcspkr.c avec gcc. Mais j'obtiendrai alors pcspkr.o. Or, j'ai crû comprendre
que dans les noyaux à partir du 2.6, les modules étaient en .ko et non pas en .o. Tout d'abord, fichier.ko est bien tout
simplement un fichier source compilé, n'est-ce-pas? Comment l'obtenir à partir du source (et non pas avec make-kpkg)?
Comment l'intégrer aux modules? En le copiant-collant à la bonne place dans /lib/modules/mes_modules/...?
B. Le fait de modifier directement dans /usr/src/linux/arch/i386/defconfig une option et de recompiler ensuite, ça
prend en compte ou pas? J'ai fait un test et ça ne prend pas en compte la modif. Mon noyau recompilé est le même que le
précédent. Alors pourquoi?
> Je ne sais pas comment ça marche sous debian, mais il me semble que le
> dossier /lib/modules/<kernelversion>/build pointe quelque part dans les
> sources du noyau (/usr/src/linux...?). Dites-moi si je me trompe.
> Donc la commande que tu as lancée trouve des références dans le code du kernel
> et non dans les modules compilés. Donc le module n'est pas compilé à moins
> que la fonction ne soit dans le kernel ??? Il ne reste donc qu'à compiler le
> module et à le charger au démarrage en insérant la ligne pcspkr
> dans /etc/modprobe.preload ou à le compiler dans le kernel si besoin... Dites
> moi si je me trompe....
>
J'ai des éléments de réflexion:
1. Effectivement, le fichier pcspkr.c n'a pas "oublié" d'être compilé mais c'est tout bonnement un lien vers les sources du
kernel. Il est donc dans /usr/src/linux/drivers/input/misc/.
Il faut donc que je le recompile à part ou alors que je recompile tout le noyau avec la nouvelle option pcspkr dans
menuconfig (à propos, je ne l'ai pas trouvé dans le fichier /usr/src/linux/arch/i386/defconfig et l'aide de menucongig ne
dit pas son nom). Donc ça devrait bien marcher (ça compile pour le moment :) ).
2. Bon, là je recompile tout mon noyau car j'avais d'autres modifs à faire. Néanmoins, il y a quelques points que je ne
comprends pas:
A. Je peux recompiler un source comme pcspkr.c avec gcc. Mais j'obtiendrai alors pcspkr.o. Or, j'ai crû comprendre
que dans les noyaux à partir du 2.6, les modules étaient en .ko et non pas en .o. Tout d'abord, fichier.ko est bien tout
simplement un fichier source compilé, n'est-ce-pas? Comment l'obtenir à partir du source (et non pas avec make-kpkg)?
Comment l'intégrer aux modules? En le copiant-collant à la bonne place dans /lib/modules/mes_modules/...?
B. Le fait de modifier directement dans /usr/src/linux/arch/i386/defconfig une option et de recompiler ensuite, ça
prend en compte ou pas? J'ai fait un test et ça ne prend pas en compte la modif. Mon noyau recompilé est le même que le
précédent. Alors pourquoi?
J'espère que mes questions sont limpides.
Merci d'avance,
> Je ne sais pas comment ça marche sous debian, mais il me semble que le
> dossier /lib/modules/<kernelversion>/build pointe quelque part dans les
> sources du noyau (/usr/src/linux...?). Dites-moi si je me trompe.
> Donc la commande que tu as lancée trouve des références dans le code du kernel
> et non dans les modules compilés. Donc le module n'est pas compilé à moins
> que la fonction ne soit dans le kernel ??? Il ne reste donc qu'à compiler le
> module et à le charger au démarrage en insérant la ligne pcspkr
> dans /etc/modprobe.preload ou à le compiler dans le kernel si besoin... Dites
> moi si je me trompe....
>
J'ai des éléments de réflexion:
1. Effectivement, le fichier pcspkr.c n'a pas "oublié" d'être compilé mais c'est tout bonnement un lien vers les sources du
kernel. Il est donc dans /usr/src/linux/drivers/input/misc/.
Il faut donc que je le recompile à part ou alors que je recompile tout le noyau avec la nouvelle option pcspkr dans
menuconfig (à propos, je ne l'ai pas trouvé dans le fichier /usr/src/linux/arch/i386/defconfig et l'aide de menucongig ne
dit pas son nom). Donc ça devrait bien marcher (ça compile pour le moment :) ).
2. Bon, là je recompile tout mon noyau car j'avais d'autres modifs à faire. Néanmoins, il y a quelques points que je ne
comprends pas:
A. Je peux recompiler un source comme pcspkr.c avec gcc. Mais j'obtiendrai alors pcspkr.o. Or, j'ai crû comprendre
que dans les noyaux à partir du 2.6, les modules étaient en .ko et non pas en .o. Tout d'abord, fichier.ko est bien tout
simplement un fichier source compilé, n'est-ce-pas? Comment l'obtenir à partir du source (et non pas avec make-kpkg)?
Comment l'intégrer aux modules? En le copiant-collant à la bonne place dans /lib/modules/mes_modules/...?
B. Le fait de modifier directement dans /usr/src/linux/arch/i386/defconfig une option et de recompiler ensuite, ça
prend en compte ou pas? J'ai fait un test et ça ne prend pas en compte la modif. Mon noyau recompilé est le même que le
précédent. Alors pourquoi?
J'espère que mes questions sont limpides.
Merci d'avance,
> Je ne sais pas comment ça marche sous debian, mais il me semble que le
> dossier /lib/modules/<kernelversion>/build pointe quelque part dans les
> sources du noyau (/usr/src/linux...?). Dites-moi si je me trompe.
> Donc la commande que tu as lancée trouve des références dans le code du kernel
> et non dans les modules compilés. Donc le module n'est pas compilé à moins
> que la fonction ne soit dans le kernel ??? Il ne reste donc qu'à compiler le
> module et à le charger au démarrage en insérant la ligne pcspkr
> dans /etc/modprobe.preload ou à le compiler dans le kernel si besoin... Dites
> moi si je me trompe....
>
J'ai des éléments de réflexion:
1. Effectivement, le fichier pcspkr.c n'a pas "oublié" d'être compilé mais c'est tout bonnement un lien vers les sources du
kernel. Il est donc dans /usr/src/linux/drivers/input/misc/.
Il faut donc que je le recompile à part ou alors que je recompile tout le noyau avec la nouvelle option pcspkr dans
menuconfig (à propos, je ne l'ai pas trouvé dans le fichier /usr/src/linux/arch/i386/defconfig et l'aide de menucongig ne
dit pas son nom). Donc ça devrait bien marcher (ça compile pour le moment :) ).
2. Bon, là je recompile tout mon noyau car j'avais d'autres modifs à faire. Néanmoins, il y a quelques points que je ne
comprends pas:
A. Je peux recompiler un source comme pcspkr.c avec gcc. Mais j'obtiendrai alors pcspkr.o. Or, j'ai crû comprendre
que dans les noyaux à partir du 2.6, les modules étaient en .ko et non pas en .o. Tout d'abord, fichier.ko est bien tout
simplement un fichier source compilé, n'est-ce-pas? Comment l'obtenir à partir du source (et non pas avec make-kpkg)?
Comment l'intégrer aux modules? En le copiant-collant à la bonne place dans /lib/modules/mes_modules/...?
B. Le fait de modifier directement dans /usr/src/linux/arch/i386/defconfig une option et de recompiler ensuite, ça
prend en compte ou pas? J'ai fait un test et ça ne prend pas en compte la modif. Mon noyau recompilé est le même que le
précédent. Alors pourquoi?
J'espère que mes questions sont limpides.
Merci d'avance,
> Je ne sais pas comment ça marche sous debian, mais il me semble que le
> dossier /lib/modules/<kernelversion>/build pointe quelque part dans les
> sources du noyau (/usr/src/linux...?). Dites-moi si je me trompe.
> Donc la commande que tu as lancée trouve des références dans le c ode du
> kernel et non dans les modules compilés. Donc le module n'est pas com pilé
> à moins que la fonction ne soit dans le kernel ??? Il ne reste donc q u'à
> compiler le module et à le charger au démarrage en insérant la li gne
> pcspkr
> dans /etc/modprobe.preload ou à le compiler dans le kernel si besoin. ..
> Dites moi si je me trompe....
J'ai des éléments de réflexion:
1. Effectivement, le fichier pcspkr.c n'a pas "oublié" d'être compil é mais
c'est tout bonnement un lien vers les sources du kernel. Il est donc dans
/usr/src/linux/drivers/input/misc/.
Il faut donc que je le recompile à part ou alors que je recompile tout le
noyau avec la nouvelle option pcspkr dans menuconfig (à propos, je ne l 'ai
pas trouvé dans le fichier /usr/src/linux/arch/i386/defconfig et l'aide de
menucongig ne dit pas son nom). Donc ça devrait bien marcher (ça comp ile
pour le moment :) ). 2. Bon, là je recompile tout mon noyau car j'avais
d'autres modifs à faire. Néanmoins, il y a quelques points que je ne
comprends pas:
A. Je peux recompiler un source comme pcspkr.c avec gcc. Mais j'obtiendr ai
alors pcspkr.o. Or, j'ai crû comprendre que dans les noyaux à partir du
2.6, les modules étaient en .ko et non pas en .o. Tout d'abord, fichier .ko
est bien tout simplement un fichier source compilé, n'est-ce-pas?
Comment
l'obtenir à partir du source (et non pas avec make-kpkg)? Comment
l'intégrer aux modules? En le copiant-collant à la bonne place dans
/lib/modules/mes_modules/...?
B. Le fait de modifier directement dans
/usr/src/linux/arch/i386/defconfig une option et de recompiler ensuite, ça
prend en compte ou pas? J'ai fait un test et ça ne prend pas en compte la
modif. Mon noyau recompilé est le même que le précédent. Alors po urquoi?
J'espère que mes questions sont limpides.
Merci d'avance,
--
Stevan Kanban
> Je ne sais pas comment ça marche sous debian, mais il me semble que le
> dossier /lib/modules/<kernelversion>/build pointe quelque part dans les
> sources du noyau (/usr/src/linux...?). Dites-moi si je me trompe.
> Donc la commande que tu as lancée trouve des références dans le c ode du
> kernel et non dans les modules compilés. Donc le module n'est pas com pilé
> à moins que la fonction ne soit dans le kernel ??? Il ne reste donc q u'à
> compiler le module et à le charger au démarrage en insérant la li gne
> pcspkr
> dans /etc/modprobe.preload ou à le compiler dans le kernel si besoin. ..
> Dites moi si je me trompe....
J'ai des éléments de réflexion:
1. Effectivement, le fichier pcspkr.c n'a pas "oublié" d'être compil é mais
c'est tout bonnement un lien vers les sources du kernel. Il est donc dans
/usr/src/linux/drivers/input/misc/.
Il faut donc que je le recompile à part ou alors que je recompile tout le
noyau avec la nouvelle option pcspkr dans menuconfig (à propos, je ne l 'ai
pas trouvé dans le fichier /usr/src/linux/arch/i386/defconfig et l'aide de
menucongig ne dit pas son nom). Donc ça devrait bien marcher (ça comp ile
pour le moment :) ). 2. Bon, là je recompile tout mon noyau car j'avais
d'autres modifs à faire. Néanmoins, il y a quelques points que je ne
comprends pas:
A. Je peux recompiler un source comme pcspkr.c avec gcc. Mais j'obtiendr ai
alors pcspkr.o. Or, j'ai crû comprendre que dans les noyaux à partir du
2.6, les modules étaient en .ko et non pas en .o. Tout d'abord, fichier .ko
est bien tout simplement un fichier source compilé, n'est-ce-pas?
Comment
l'obtenir à partir du source (et non pas avec make-kpkg)? Comment
l'intégrer aux modules? En le copiant-collant à la bonne place dans
/lib/modules/mes_modules/...?
B. Le fait de modifier directement dans
/usr/src/linux/arch/i386/defconfig une option et de recompiler ensuite, ça
prend en compte ou pas? J'ai fait un test et ça ne prend pas en compte la
modif. Mon noyau recompilé est le même que le précédent. Alors po urquoi?
J'espère que mes questions sont limpides.
Merci d'avance,
--
Stevan Kanban
> Je ne sais pas comment ça marche sous debian, mais il me semble que le
> dossier /lib/modules/<kernelversion>/build pointe quelque part dans les
> sources du noyau (/usr/src/linux...?). Dites-moi si je me trompe.
> Donc la commande que tu as lancée trouve des références dans le c ode du
> kernel et non dans les modules compilés. Donc le module n'est pas com pilé
> à moins que la fonction ne soit dans le kernel ??? Il ne reste donc q u'à
> compiler le module et à le charger au démarrage en insérant la li gne
> pcspkr
> dans /etc/modprobe.preload ou à le compiler dans le kernel si besoin. ..
> Dites moi si je me trompe....
J'ai des éléments de réflexion:
1. Effectivement, le fichier pcspkr.c n'a pas "oublié" d'être compil é mais
c'est tout bonnement un lien vers les sources du kernel. Il est donc dans
/usr/src/linux/drivers/input/misc/.
Il faut donc que je le recompile à part ou alors que je recompile tout le
noyau avec la nouvelle option pcspkr dans menuconfig (à propos, je ne l 'ai
pas trouvé dans le fichier /usr/src/linux/arch/i386/defconfig et l'aide de
menucongig ne dit pas son nom). Donc ça devrait bien marcher (ça comp ile
pour le moment :) ). 2. Bon, là je recompile tout mon noyau car j'avais
d'autres modifs à faire. Néanmoins, il y a quelques points que je ne
comprends pas:
A. Je peux recompiler un source comme pcspkr.c avec gcc. Mais j'obtiendr ai
alors pcspkr.o. Or, j'ai crû comprendre que dans les noyaux à partir du
2.6, les modules étaient en .ko et non pas en .o. Tout d'abord, fichier .ko
est bien tout simplement un fichier source compilé, n'est-ce-pas?
Comment
l'obtenir à partir du source (et non pas avec make-kpkg)? Comment
l'intégrer aux modules? En le copiant-collant à la bonne place dans
/lib/modules/mes_modules/...?
B. Le fait de modifier directement dans
/usr/src/linux/arch/i386/defconfig une option et de recompiler ensuite, ça
prend en compte ou pas? J'ai fait un test et ça ne prend pas en compte la
modif. Mon noyau recompilé est le même que le précédent. Alors po urquoi?
J'espère que mes questions sont limpides.
Merci d'avance,
--
Stevan Kanban
