Dans la plupart des systèmes open-source, personnaliser son noyau fait partie des apprentissages nécessaire pour maîtriser le système.
On constate d'ailleurs que des Mailing-List entières existent sur ce sujet, et la communauté du système en question est prête à vous aider.
OpenBSD ne possède pas cette philosophie de customisation. En effet, l'utilisation du noyau GENERIC et considérée comme suffisante pour une utilisation standard, et la modification du noyau fourni serait un risque pris pour bien peu d'avantages (mis à part peut-être l'apprentissage, bien que la modification d'un noyau OpenBSD est loin d'être aussi compréhensible est agréable qu'un noyau comme Linux).
Dans ce cas, pourquoi recompiler un noyau ? Après tout, si les Mailing-List ne vous aident pas et que les utilisateurs vous déconceillent toute modification, quelle est donc l'utilité d'une recompilation ?
Il y a en fait plusieurs possibilités. Tout d'abord, recompiler un noyau ne signifie pas forcément le customiser. Ce dernier terme définissant la modification en profondeur du noyau, pour en retirer des fonctionnalités et en ajouter d'autres.
Cependant, les cas suivant peuvent impliquer une recompilation du noyau GENERIC :

• L'ajout d'un patch de sécurité au noyau lui-même. En conséquence, le noyau doit être recompilé pour assimiler le patch. Par contre, la modification des options n'est pas nécessaire.
• En cas de travail sur le noyau lui-même. Dans ce cas là, il est considéré que la personne est suffisamment au fait du fonctionnement interne de celui-ci pour savoir que faire.
• Enfin, il peut s'agir d'une volonté de réduction de la consommation mémoire du noyau, qui dans ses dernières version utilise environ 5 Mo en RAM. Ce dernier cas n'a de sens que d'en l'emploi d'OpenBSD sur un très vieux système, au ressources très limité.

De ces trois cas, on retiendra surtout le premier, étant le plus fréquent.
On exposera cependant le fonctionnement du fichier de configuration du noyau GENERIC, afin de bien comprendre le fonctionnement des sources.

Aucun outil externe n'est nécessaire si vous avez bien installé tout les fileset lors de l'installation de votre système. Si ce n'est pas le cas il vous faut absolument installer le fileset comp44.tgz vous le trouverez dans le repertoire OpenBSD/4.4/Votre_Architecture.
Une fois téléchargé vous devriez l'installer de la façon suivante :

# cd /
# tar xvzfp comp44.tgz

Vous aurez également besoin des sources du noyau.
Il s'agit du fichier sys.tar.gz, présent dans la racine du cdrom ou dans le répertoire OpenBSD/4.4 d'un des nombreux miroirs FTP.
Comme d'habitude, ce dernier s'installe dans le répertoire /usr/src du système, avec la commande suivante :

# cd /usr/src
# tar xzvpf sys.tar.gz

Les sources du noyau sont répartie en répertoire pour chaque type de processeur.
Normalement, il n'est pas nécessaire d'aller mettre les mains dans ces divers répertoires.
On constate également un répertoire conf, qui contient le fichier de configuration du noyau pour les options indépendantes du matériel, un répertoire arch/, contenant les informations dépendant du matériel et un fichier Makefile, pour la compilation.
Il faut savoir qu'aucun utilitaire de configuration n'est fourni.
Il sera donc nécessaire de modifier les fichiers de configuration du noyau à la main, ce qui implique une grande connaissance du matériel sur lequel est installé OpenBSD.
Il est déconseillé aux personnes n'ayant pas l'habitude d'un travail de ce type de chercher à modifier le noyau.

Une copie du noyau actuel est automatiquement faite lors du make install de /bsd vers /obsd. Cela vous permettra ensuite de pouvoir réutiliser ce noyau en cas de problème avec le nouveau (je rappelle que le gestionnaire d'amorçage d'OpenBSD permet le choix du noyau au démarrage de la machine).
Ensuite, il va falloir vous munir de patience, car la mise en place des modifications risque d'être longue.

Dans le cas d'une architecture de type i386.

Comme vu précédemment, ce fichier présente les options du noyau ne faisant pas référence au matériel.
Ainsi, on y trouvera aucune information sur les pilotes ou la gestion de la mémoire ou du processeur.
On trouvera surtout les options de support réseau et systèmes de fichiers.
En théorie, vous n'aurez pas à modifier le contenu de ce fichier.
En effet, il s'agit ici des supports de base du noyau, et le fait qu'ils soient indépendant du matériel les rendent communs à tous les noyaux OpenBSD de tous les matériels.
Dans le cas où vous souhaitez modifier ce fichier, faite une copie et travaillez dessus :

# cp GENERIC OBSDTEST

Le fichier GENERIC possède une structure précise : chaque ligne correspond à une option.
Voici la structure générale du fichier :

...
typenom # commentaire
...

Les lignes peuvent être de deux types : Les lignes d'options :
Elles activent le support des options du noyau concernant très majoritairement les systèmes de fichiers, les protocoles réseau et la cryptographie. En voici quelques exemples :

  option SYSVSEM # System V-like semaphores
  option SYSVSHM # System V-like memory sharing
  ...
  option INET6 # IPv6 (needs INET)
  option IPSEC # IPsec

On peut voir ici les deux types d'options. Les premières correspondent à la gestion de la mémoire et l'ordonnancement des processus (sémaphores). Les deux dernières correspondent aux supports des protocole réseaux IPv6 et IPsec. On constate donc qu'il s'agit de support de protocoles de fonctionnements, réseaux ou systèmes, parfaitement indépendant du matériel.

Les lignes de pseudo-device :
Elles actives le support des pseudo périphériques liés à ces options, comme pflog par exemple (device de gestion des journaux de pf) :

  pseudo-device pf # packet filter
  pseudo-device pflog # pf log if

Il s'agit là de gestion de devices materiel-indépendants.

Pour désactiver une option ou un pseudo-device, un # en début de ligne est suffisant, mettant la ligne en commentaire.
Il faut cependant bien faire attention lors de la mise en place des commentaires.
Des options telles que inet sont très probablement nécessaires à l'utilisation de la machine.
Les lignes ne doivent être modifiées que si vous êtes parfaitement certain de ce que vous faites.

Dans ce fichier sont regroupées toutes les informations liées d'une manière ou d'une autre à l'architecture de la machine.
Ce fichier fait plusieurs centaines de lignes.
De la même manière que pour le fichier précédent, il faut travailler sur une copie en cas de modification :

# cp GENERIC OBSDTEST

On retrouve dans ce fichier quelques options, la listes des materiels gérés, ainsi que leur périphériques parent et parfois d'autres information telles que leur IRQ.
Ce fichier est très complexe.
Il est également hardament conseillé de n'y toucher que si vous êtes parfaitement sûr de ce que vous faites.
On y retrouve également quelques options, mais surtout l'intégralité des matériels gérés par le noyau.
Contrairement au système Linux, le nom des périphérique n'est pas dépendant de sa fonction, mais du constructeur.
Ainsi, il est plus difficile de reconnaître précisément chaque périphérique dans ce fichier.
Il s'agit là aussi d'une difficulté importante :
Si l'on connaît bien son système et la façon dont le noyau OpenBSD gère celui-ci, il est cependant plus aisé d'y faire des modifications.
En fin de fichier, on retrouve également quelques pseudo-devices, en général nécessaire à un bon fonctionnement.
On retrouve également le support RAIDFrame, qui n'est pas activé par défaut.
Regardons maintenant d'un peu plus près ce fichier :

Le fichier commence par définir le type de machine, ici de type i386.
Cette ligne n'est bien entendu pas modifiable si vous souhaitez que le noyau fonctionne.
La deuxième est plus intéressante : elle inclus le fichier vu précédement en tête de celui-ci.
Si des modifications y ont été faites, il faut alors la remplacer par l'adresse du fichier travaillé :

include "../../../conf/OBSDTEST"

On retrouve en suite une liste de CPU compatible i386, puis quelques options comme la compatibilité avec d'autres OS et les options de débogage.
On arrive enfin à la liste des pilotes :

cpu0 at mainbus?
bios0 at mainbus0
...
pci* at mainbus0

La lecture devient plus complexe.
Tout d'abord, il faut savoir que le ? correspond à un caractère.
Il peut ainsi être remplacé par n'importe quel caractère alphanumérique.
Ensuite, le * correspond à une chaîne alphanumérique de taille variable.
En conséquence, voici la signification des lignes précédentes :

• La première conserne le premier CPU (unique dans la plupart de PC) La ligne indique qu'il peut se trouver sur n'importe quel bus principal. En effet, dans le cas de machines biporcesseurs, chaque processeur possède son bus. Il faut alors définir un processeur primaire et un secondaire, de même un bus primaire et un secondaire. Cette ligne permet de croiser processeurs et bus primaires et secondaires.
• La deuxième ligne définit le bios comme placé sur le bus primaire.
• Enfin, la dernière ligne place tous les controleurs PCI (pci0, pci1…) sur le premier bus principal, unique sur une machine monoprocesseur.

On peut ainsi considérer la liste des pilotes comme une suite d'adresses, ou à chaque matériel et associé sa position (via son parent), et les options qui doivent parfois lui être fournies.

On constate donc que la compréhension de ce fichier est complexe, et ses modifications délicates.
Je rappelle encore une fois que la modification du noyau OpenBSD n'est pas conseillé sauf exception et qu'il faut faire très attention lors d'éventuelles modifications.

Patcher le noyau est beaucoup plus simple que de le personnaliser.
Les sources du noyau sont configurées pour le noyau générique.
Ainsi, une fois les sources décompressées, il suffit d'appliquer le patch, puis de compiler.
L'application du patch se fait via la commande patch. L'utilisation classique de la commande est celle-ci :

# cd /usr/src/
# patch -p0 < correctif.patch

Dans ce cas là, le patch ira corriger les fichiers contenu dans le sous répertoire sys/ contenant le noyau.
L'option -p? définit la modification des adresses du patch.
Ainsi, si vous êtes déjà dans le répertoire sys/, vous pouvez le retirer en utilisant l'option -p1, et ainsi de suite.
Lors de l'exécution de la commande, toute une serie d'information va défiler.
Il s'agit des informations sur les divers fichiers à corriger, et les corrections effectuées.
Une fois l'exécution terminée, il ne reste plus qu'à compiler le noyau.

Tout d'abord, il faut préparer le noyau pour la compilation.
Pour cela, on utilise la commande config, qui va lire les fichiers de configuration et préparer les sources en conséquences.
Si vous n'avez fait que patcher le noyau, alors vous devez taper :

# config GENERIC

Dans le cas d'une personnalisation, vous devez lire vos fichiers et non ceux fournis avec les sources :

# config OBSDTEST

Dans ce dernier cas, il se peut que vous ayez une erreur d'écriture qui soit détectée.
En effet, comme les fichers de configuration sont modifiés à la main, des erreurs peuvent être faites.
config renvoie la ligne où l'erreur a été commise.
Il ne reste plus qu'à la corriger.
Une fois la configuration terminée, il faut compiler le noyau. Pour cela, on tape successivement :

# make dep
# make

Ces commandes vont se charger de gérer les dépendances entre fichier pour l'ordonnancement de la compilation, puis effectivement compiler le noyau.
Le fichier binaire de celui-ci est alors créé.

Pour pouvoir utiliser le nouveau noyau au démarrage, il faut copier le binaire fraichement créé vers /bsd,
cela est fait automatiquement avec la commande suivante :

# make install

En redémarrant, le système boote par défaut sur ce noyau.
Il est possible de s'en assurer avec la commande uname :

$ uname -v
OBSDTEST#0

Il ne reste plus qu'a tester les capacités du nouveau noyau.
Dans le cas d'un kernel-panic, il est toujours possible de démarrer sur l'ancien noyau en utilisant le fichier /obsd, créé automatiquement, puis de corriger l'erreur fournie lors du plantage.

Recompiler son noyau OpenBSD
The translation was initiated by Philippe Thierry on 2005-06-19