kernel developpement (débuter et tester) [résolu] .

ubuntuforce · Le 18/02/2014, à 19:03

Salut les Ubuntues,
Comme le titre l'indique je m'intéresse au noyau linux et a son architecture ainsi que le développement ce qui me pose problème car je ne peut pas tester de code écrit par un débutant et même en recompilant le noyau je ne voit pas comment je pourrai débuter a écrire du code (et surtout le tester) car:

"Les sources /usr/src/linux-headers-$(uname -r)/* ne sont pas linkable" et je n'ai pas trouver d'équivalent dans /usr/include/

par exemple pour tester:

#include "usr/src/$(uname -r)/sched.h" // ce qui ne fonctionne pas je sais
struct task_struct *task ;
next_task(task) ;
printf("find a task structure [pid:%d]\n",task->pid) ;

J'ai chercher un paquet kernel-dev qui n'existe pas et je n'ai pas de dossier:
/usr/include/kernel

Alors comment tester du code noyau, quel est la méthodologie a utiliser pour débuter.

Je cherche juste la bonne méthodologie pour débuter et tester du code noyau sachant que le noyau n'est pas écrit en C normal mais en optimiser et que les fichiers sources sont inutilisables pour #include...

Je vous serai reconnaissant si vous voulez bien m'éclairez un peu sur le sujet et me guider.
Merci pour toutes vos réponses éclairés.

Dernière modification par ubuntuforce (Le 24/02/2014, à 05:21)

tiramiseb · Le 18/02/2014, à 23:02

Salut,

"Les sources /usr/src/linux-headers-$(uname -r)/* ne sont pas linkable"

Tu as lu ça où ?

le noyau n'est pas écrit en C normal

Il est écrit en C anormal ?

les fichiers sources sont inutilisables pour #include...

Inutilisables ? Pourquoi ?

Pour avoir les sources du noyau, il faut avoir le paquet "linux-source-X.YY.Z" (où X.YY.Z est la version du noyau concernée, par exemple 3.11.0 sur Ubuntu 13.10).

Les fichiers dans /usr/src/linux-headers[...] ce sont les en-têtes du noyau, qui permettent de compiler des modules par exemple. Mais elles ne permettent pas de bosser sur le noyau directement.

Cela dit, j'imagine que pour faire du dev noyau, on utilise plutôt les sources vanilla de kernel.org...

pires57 · Le 19/02/2014, à 00:03

Le noyaux n'est pas écrit en C normal?
https://www.kernel.org/doc/Documentation/HOWTO

grim7reaper · Le 19/02/2014, à 03:35

tiramiseb a écrit :

le noyau n'est pas écrit en C normal
Il est écrit en C anormal ?

C’est gentil de rire, mais il a raison.
D’une part, le C du noyau c’est du C freestanding, pas hosted (ce qui implique pas d’accès à la libc entre autres) ce qui peut être déroutant. Mais ça reste du C « normal » (du C standard si tu préfères), on est d’accord.
D’autre part, le noyau Linux est écrit en GNU C, pas en C « normal » (donc standard). À une époque, il fallait patcher le noyau pour le compiler avec icc par exemple (je ne sais pas si c’est toujours le cas).
Donc ouais, le noyau n’est pas écrit en C normal.

tiramiseb a écrit :

les fichiers sources sont inutilisables pour #include...
Inutilisables ? Pourquoi ?

Parce que le noyau (ou un module noyau) ça ne se compile pas comme n’importe quel logiciel en espace utilisateur.

Pour en revenir au problème d’ubuntuforce, le plus simple pour bidouiller le noyau c’est d’écrires des modules je pense.

Voilà comment développer/compiler/tester un petit module noyau :

% mkdir hello_kernel
% cd hello_kernel

Dans ce répertoire, tu va te créer un fichier hello_kernel.c qui va contenir :

#include <linux/init.h>
#include <linux/module.h>

MODULE_LICENSE("GPL");

static int hello_init(void)
{
	printk(KERN_ALERT "Hello kernel!\n");
	return 0;
}

static void hello_exit(void)
{
	printk(KERN_ALERT "Goodbye kernel!\n");
}

module_init(hello_init);
module_exit(hello_exit);

Et le Makefile suivant (attention en copiant/collant depuis le forum, le Makefile doit contenir des tabulations pour les règles) :

# If KERNELRELEASE is defined, we've been invoked from the
# kernel build system and can use its language.
ifneq ($(KERNELRELEASE),)
	obj-m := hello_kernel.o
# Otherwise we were called directly from the command
# line; invoke the kernel build system.
else
KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)

default:
	$(MAKE) -C $(KERNELDIR) M=$(PWD) modules
endif

En fait, il faut passer par le système de build du noyau même quand tu compiles un module externe en dehors de l’arborescence (d’où le -C et M).

Si la compilation est OK (y’a juste à taper make normalement), tu peux ensuite faire (avec les droits d’admin) :

% insmod ./hello_kernel.ko

Pour charger le module.
Tu peux vérifier sa présence par

% lsmod | grep hello_kernel

Puis, pour le décharger (avec les droits d’admin) :

% rmmod hello_kernel.ko

Si tu tape

% dmesg

tu devrais voir les messages de ton module.

Si tu comprends l’anglais, je te conseille l’excellent Linux Device Drivers, Third Edition.
Si tu dois de limiter au français, bah bon courage. Il y a ça (qui correspond plus ou moins au début du bouquin précédent).

tiramiseb · Le 19/02/2014, à 09:25

Merci grim7reaper pour les détails.

Toutefois, tu veux bien en donner plus ?

le noyau (ou un module noyau) ça ne se compile pas comme n’importe quel logiciel en espace utilisateur.

Quelle est techniquement la différence ?
Car les quelques fois où j'ai compilé des modules (même un jour j'ai essayé d'en faire moi-même, mais bon ça fait longtemps je ne m'en rappelle plus) il ne me semble pas que j'ai fait quelque chose de spécial, de très différent d'une compilation d'un logiciel lambda.

Je ne me rappelle pas être « passé par le système de build du noyau »... Mais bon peut-être que c'est un aspect qui a évolué entre-temps...

pires57 · Le 19/02/2014, à 09:32

Jvois pas la différence, cela reste du c

grim7reaper · Le 19/02/2014, à 11:08

tiramiseb a écrit :

Merci grim7reaper pour les détails.

De rien.

tiramiseb a écrit :

Toutefois, tu veux bien en donner plus ?

Pas de problème.

tiramiseb a écrit :

le noyau (ou un module noyau) ça ne se compile pas comme n’importe quel logiciel en espace utilisateur.
Quelle est techniquement la différence ?

Il faut utiliser les Makefile du noyau, tu ne peux pas compiler un module avec un Makefile fait main dans ton répertoire comme tu le fais d’habitude.
Si tu regardes la ligne de commande utiliser pour compiler dans mon Makefile, c’est ça :

$(MAKE) -C $(KERNELDIR) M=$(PWD) modules

J’utilise le Makefile situé dans /lib/modules/XXXX/build/,qui va faire tout un tas de trucs puis appeler le petit bout de Makefile que j’ai écrit.

tiramiseb a écrit :

Car les quelques fois où j'ai compilé des modules (même un jour j'ai essayé d'en faire moi-même, mais bon ça fait longtemps je ne m'en rappelle plus) il ne me semble pas que j'ai fait quelque chose de spécial, de très différent d'une compilation d'un logiciel lambda.

Si tu utilises un Makefile fourni avec les sources du modules, tu ne vois pas la différence : tu tapes juste make dans tous les cas.
Par contre, si tu écris ton module, tu as certainement dû écrire un Makefile dans le même genre que le mien (ou le lancer avec une commande particulière).

tiramiseb a écrit :

Je ne me rappelle pas être « passé par le système de build du noyau »... Mais bon peut-être que c'est un aspect qui a évolué entre-temps...

En effet, ça a changé à un moment (mais depuis les 2.6.x c’est comme ça il me semble, les 2.4.x utilisait peut être un autre système) mais je pense que le principe était le même.

pires57 a écrit :

Jvois pas la différence, cela reste du c

Non, ce n’est pas du C.
Le C c’est pas le langage à mémé (ou pépé, pas de sexisme) que tu définis comme tu le sens. C’est un truc standardisé (comité ISO, serious business). Peu de langages ont une norme officielle de ce genre (C, C++, Ada, Ruby (c’est assez récent, c’était une condition pour qu’il soit utilisé par le gouvernement japonais) et c’est tout il me semble.
Partant de là, soit ça respecte une des normes et c’est du C, soit ça la respecte pas et ce n’est pas du C (c’est un autre langage, une extension ou un dialecte mais ce n’est pas du C). Y'a pas à tortiller, c’est un truc binaire.

Tu ne vois pas les différences, pourtant il y’en a un paquet (goto arithmétique, case range, tableau de taille zéro, typeof, …). Suffit de suivre le lien dans mon poste précédent.

ubuntuforce · Le 20/02/2014, à 11:49

Grand merci a tous et en particulier a grim7reaper

Concernant les débats je m'abstiens de commentaires, car je ne sais que programmer, en C depuis plus d'un an je n'ai publier qu'un seule programme de protection contre les accès physique a votre système Ubuntu en votre absence : datetime-lock.

Mais il y a un hic avec je n'ai jamais eu l'occasion de m'intéresser au programme make (sauf taper make, make install) mais je sais a quoi il sert: automatiser la compilation.
Et donc a la syntaxe des fichiers Makefile...

Mais ayant suivis le mini tutoriel de grim7reaper qui ne fonctionne pas sur mon système, j'ai dû faire quelque chose de travers.
Et comme lecteur assidus de la presse Linux j'ai suivis l'article sur les DKMS du N° 167.

J'ai réussis a compiler un module en mixant les deux recettes (le sujet était légèrement différent dans le magazine mais je l'ai adapter) !!!
Personnellement je lis: Linux Kernel Development
Et ça fait chauffer les neurones de la reine d'angleterre.

Grand merci a tous, que Ubuntu fasse la force et hacking the kernel is fun.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 18/02/2014, à 19:03

kernel developpement (débuter et tester) [résolu] .

#2 Le 18/02/2014, à 23:02

Re : kernel developpement (débuter et tester) [résolu] .

#3 Le 19/02/2014, à 00:03

Re : kernel developpement (débuter et tester) [résolu] .

#4 Le 19/02/2014, à 03:35

Re : kernel developpement (débuter et tester) [résolu] .

#5 Le 19/02/2014, à 09:25

Re : kernel developpement (débuter et tester) [résolu] .

#6 Le 19/02/2014, à 09:32

Re : kernel developpement (débuter et tester) [résolu] .

#7 Le 19/02/2014, à 11:08

Re : kernel developpement (débuter et tester) [résolu] .

#8 Le 20/02/2014, à 11:49

Re : kernel developpement (débuter et tester) [résolu] .

Pied de page des forums