Avec un interpréteur, le langage va avec un environnement où vous entrez des commandes à un invite de commandes et l’environnement les exécute pour vous. Pour des programmes plus compliqués, vous pouvez entrer les commandes dans un fichier et demander à l’interpréteur de charger le fichier et d’exécuter les commandes qui sont à l’intérieur. Si quoique ce soit se passe mal, beaucoup d’interpréteurs vous enverrons dans un dévermineur pour vous aider à débusquer le problème.

L’avantage de cela est que vous pouvez voir les résultats de vos commandes immédiatement, et les erreurs peuvent être corrigées facilement. Le plus gros désavantage arrive quand vous voulez partager vos programmes avec d’autres personnes. Ils doivent avoir le même interpréteur ou bien vous devez avoir un moyen de leur donner, et ils doivent comprendre comment l’utiliser. Par ailleurs, les utilisateurs pourraient ne pas apprécier d’être renvoyés dans un dévermineur s’ils ont appuyé sur la mauvaise touche ! D’un point de vue performance, les interpréteurs peuvent utiliser beaucoup de mémoire et généralement ne génèrent pas un code aussi efficace que les compilateurs.

A mon avis, les langages interprétés sont le meilleur moyen pour démarrer si vous n’avez jamais programmé. Ce genre d’environnement se trouve typiquement avec des langages comme Lisp, Smalltalk, Perl et Basic. Il peut aussi être dit que l’interpréteur de commandes Unix (sh, csh) est lui-même un interpréteur, et beaucoup de gens écrivent en fait des "scripts" (procédures) pour l’interpréteur pour les aider dans diverses tâches "domestiques" sur leur machine. En effet, une partie de la philosophie d’origine d’Unix était de fournir plein de petits programmes utilitaires qui pouvaient être liés ensemble dans des procédures pour effectuer des tâches utiles.

Voici la liste des interpréteurs qui sont disponibles sous la forme de logiciels pré-compilés pour FreeBSD, avec une brève description de quelques uns des langages interprétés les plus populaires.

Pour obtenir un de ces logiciels pré-compilés, tout ce que vous avez à faire est de cliquer sur le lien du logiciel et d’exécuter

en tant que super-utilisateur. Evidemment, vous aurez besoin d’un FreeBSD 2.1.0 ou plus en état de marche pour que le logiciel fonctionne !

Les compilateurs sont plutôt différents entre eux. Tout d’abord, vous écrivez votre code dans un fichier (ou des fichiers) en utilisant un éditeur de texte. Vous exécutez ensuite le compilateur et vérifiez qu’il accepte votre programme. S’il ne compile pas, grincez des dents et retournez à l’éditeur; s’il compile et vous donne un programme, vous pouvez exécuter ce dernier à l’invite de commande ou dans un dévermineur pour voir s’il fonctionne correctement.

Evidemment, ce n’est pas aussi direct que d’utiliser un interpréteur. Toutefois cela vous permet de faire beaucoup de choses qui sont difficiles ou même impossibles avec un interpréteur, comme écrire du code qui interagit de façon proche du système d’exploitation ou même d’écrire votre propre système d’exploitation ! C’est aussi utile si vous avez besoin d’écrire du code très efficace, étant donné que le compilateur peut prendre son temps et optimiser le code, ce qui ne serait pas acceptable avec un interpréteur. Et distribuer un programme écrit pour un compilateur est habituellement plus évident qu’un écrit pour un interpréteur-vous pouvez juste donner une copie de l’exécutable, en supposant que l’utilisateur possède le même système d’exploitation que vous.

Les langages compilés incluent Pascal, C et C. C et C sont des langages plutôt impitoyables et conviennent mieux aux programmeurs expérimentés; Pascal, d’autre part, a été conçu comme un langage éducatif, et est un assez bon langage pour commencer. Malheureusement, FreeBSD ne possède aucun support Pascal, excepté pour un convertisseur Pascal vers C dans les logiciels portés.

Le cycle édition-compilation-exécution-déverminage étant relativement pénible lors de l’utilisation de programmes séparés, beaucoup de fabricants de compilateur ont produit des environnements de développement intégrés (ou IDE pour Integrated Development Environments et EDI dans la langue de Molière). FreeBSD ne possède pas d’EDI tel quel; toutefois il est possible d’utiliser Emacs à cet effet. Ceci est vu dans Utiliser Emacs comme environnement de développement.

Quand vous travaillez sur un programme simple avec seulement un ou deux fichiers source, taper

n’est pas si mal, mais cela devient rapidement fastidieux quand il y a plusieurs fichiers-et cela peut prendre du temps à compiler aussi.

Une façon de contourner cela est d’utiliser les fichiers objet et de recompiler le fichier source seulement si le code source a changé. Aussi, nous pourrions avoir quelque chose comme ça:

si nous avions changé le fichier fichier37.c mais aucun des autres depuis la dernère compilation. Cela pourrait accélerer assez bien la compilation mais cela ne resoud pas le problème de la frappe au clavier.

Ou nous pourrions écrire une procédure pour résoudre ce problème de frappe, mais celle-ci devrait tout re-compiler, devenant ainsi inefficace sur un gros projet.

Que se passe-t-il si nous avons des centaines de fichiers source ? Que se passe-t-il si nous travaillons dans une équipe avec d’autres personnes qui oublient de nous dire quand ils ont changé un de leurs fichiers source que nous utilisons ?

Peut-être pourrions nous mettre ensemble les deux solutions et écrire quelque chose comme une procédure qui contiendrait quelque règle magique disant quand notre fichier source doit être compilé. Maintenant, tout ce dont nous avons besoin est un programme qui comprend ces règles, alors que c’est trop compliqué pour l’interpréteur.

Ce programme s’appelle make. Il lit dans un fichier, appelé un makefile, qui lui dit comment les différents fichiers dépendent les uns des autres, et détermine quels fichiers ont besoin d’être recompilés et quels n’en ont pas besoin. Par exemple, une règle pourrait dire quelque chose comme "si fromboz.o est plus ancien que fromboz.c, cela signifie que quelqu’un a dû changer fromboz.c, aussi il a besoin d’être recompilé." Le makefile possède aussi des règles pour dire à make comment re-compiler un fichier source, en faisant ainsi un outil encore plus puissant.

Les Makefiles sont typiquement stockés dans le même répertoire que le source auxquels il s’appliquent, et peuvent être appelés makefile, Makefile ou MAKEFILE. La plupart des programmeurs utilise le nom Makefile, celui-ci se trouvant proche du début de la liste du contenu du répertoire où il peut être facilement vu.

Voici un exemple très simple de Makefile:

Il consiste en deux lignes, une ligne de dépendance et une ligne de création.

La ligne de dépendance ici consiste en le nom du programme (connu comme cible), suivi de deux-points puis un espace et enfin le nom du fichier source. Quand make lit cette ligne, il vérifie si foo existe; s’il existe, il compare la date à laquelle foo a été modifié la dernière fois avec la date de dernière modification de foo.c. Si foo n’existe pas ou est plus ancien que foo.c, il regarde la ligne de création pour trouver ce qu’il doit faire. En d’autres termes, il s’agit de la règle à utiliser quand foo.c a besoin d’être re-compilé.

La ligne de création commence avec un tab (appuyez sur la touche tab) suivi de la commande que vous taperiez pour créer foo si vous deviez le faire à l’invite de commandes. Si foo n’est pas à jour ou n’existe pas, make exécute alors cette commande pour le créer. En d’autres termes, il s’agit de la règle permettant à make de re-compiler foo.c.

Aussi, quand vous tapez make, il vérifiera que foo est à jour en respect de vos derniers changements sur foo.c. Ce principe peut être étendu à des Makefiles de plusieurs centaines de cibles-en fait, sur FreeBSD, il est possible de compiler un système d’exploitation entier en tapant juste make world dans le répertoire approprié !

Une autre propriété utile des makefiles est que les cibles n’ont pas nécessairement besoin d’être des programmes. Par exemple, nous pourrions avoir un Makefile qui ressemble à cela:

Nous pouvons dire à make quelle cible nous voulons en tapant:

make ira seulement voir cette cible et ingorera les autres. Par exemple, si nous tapons make foo avec le Makefile du dessus, make ignorera la cible install.

Si nous tapons juste make, make regardera toujours la première cible et s’arrêtera sans regarder aucune autre. Aussi, si nous avions tapé make seul, make serait juste allé à la cible foo, aurait recompilé foo si nécessaire et se serait arrêté sans aller à la cible install.

Notez que la cible install ne dépend pour l’instant de rien ! Cela signifie que la commande qui suit est toujours exécutée lorsque nous essayons de créer cette cible en tapant make install. Dans ce cas, make va copier foo dans le répertoire de l’utilisateur. Cela est souvent utilisé par les Makefiles des applications, ainsi l’application peut être installée dans le répertoire correct quand elle a été correctement compilée

Il s’agit d’un sujet légèrement embrouillant à essayer et expliquer. Si vous ne comprenez pas bien comment make fonctionne, la meilleure chose à faire est d’écrire un petit programme comme "bonjour monde" et un fichier Makefile comme le précédent et de le tester. Ensuite continuez en utilisant plus d’un fichier source ou en ayant un fichier source incluant un fichier d’en-tête. La commande touch est très utile ici-elle change la date sur un fichier sans avoir à l’éditer.

Les Makefiles peuvent être plutôt compliqués à écrire. Heureusement, les systèmes BSD comme FreeBSD sont fournis avec des fichiers très puissants comme partie intégrante du système. Un très bon exemple est le système des logiciels portés. Voici la partie essentielle d’un Makefile typique des logiciels portés:

Maintenant, si nous allons dans le répertoire de ce logiciel porté et tapons make, la chose suivante se passe :

Maintenant je pense que vous serez d’accord que c’est plus impressionnant qu’une procédure de quatre lignes !

Le secret réside dans la dernière ligne qui dit à make de regarder dans le Makefile système appelé bsd.port.mk. Il est facile de fermer les yeux sur cette ligne mais c’est ici que tous les trucs forts se passent-quelqu’un a écrit un Makefile qui dit à make de faire tout ce qu’il y a au-dessus (plus un couple d’autres choses que je n’ai pas mentionnées, comme la gestion des erreurs) et n’importe qui peut avoir accès à cela simplement est ajoutant une simple ligne dans son propre fichier Makefile !

Si vous voulez jeter un regard sur ces Makefiles système, ils se trouvent /usr/shared/mk mais il est probablement mieux d’attendre un moment jusqu’à ce que vous ayez un peu d’entrainement avec les Makefiles car ceux-ci sont très compliqués (et si vous les lisez, soyez sûr d’avoir un thermos de café fort à portée de main !)

Make est un outil très puissant et peut faire beaucoup plus que le simple exemple précédent ne l’a montré. Malheureusement, il y a différentes versions de make et elles diffèrent considérablement. Le meilleur moyen d’apprendre ce qu’elles peuvent faire est probablement de lire la documentation-heureusement cette introduction vous donnera la base à partir de laquelle vous pourrez faire cela.

La version de make fournies avec FreeBSD est le Berkeley make(make de Berkeley); il y a un cours d’instruction pour celui-ci dans /usr/shared/doc/psd/12.make. Pour le voir, faites

dans ce répertoire.

Beaucoup d’applications dans les logiciels portés utilisent GNU make, qui possède un très bon ensemble de page d'"info". Si vous avez installé un de ces logiciels portés, GNU make aura été automatiquement installé sous le nom de gmake. Il est aussi disponible comme logiciel porté ou logiciel pré-compilé seul.

Pour voir les pages d’info pour GNU make, vous devrez editer le fichier dir dans le répertoire /usr/local/info pour ajouter une entrée pour celui-ci. Cela implique d’ajouter une ligne

au fichier. Une fois que vous avez fait ceci, vous pouvez taper info et ensuite sélectionner make dans le menu (ou dans Emacs, faites C-h i).

Le dévermineur fourni avec FreeBSD est appelé gdb (GNU debugger). Vous pouvez le démarrer en tapant

bien que la plupart des gens préfèrent le démarrer au sein d’Emacs. Vous pouvez faire cela avec:

Utiliser un dévermineur vous permet d’exécuter le programme dans des circonstances plus contrôlées. Typiquement, vous pouvez exécuter le programme ligne à ligne, inspecter la valeur des variables, changer cette dernière, dire au dévermineur d’exécuter jusqu’à un certain point puis de s’arrêter etc…​ Vous pouvez même vous brancher sur un programme en fonctionnement, ou charger un fichier core pour enquêter sur le plantage du programme. Il est même possible de déverminer le noyau, quoique ce soit un peu plus rusé que de déverminer des applications utilisateur dont nous discuterons dans cette section.

gdb dispose d’une assez bonne aide en ligne comme d’un ensemble de pages d’info, aussi cette section va se concentrer sur quelques commandes basiques.

Finalement, si vous trouvez son interface texte non fonctionnelle, il y a une interface graphique pour celui-ci, xxgdb, dans la collection des logiciels portés.

Cette section a pour but d’être une introduction à l’utilisation de gdb et ne couvre pas les sujets très spécialisés comme le déverminage du noyau.

Vous devrez avoir compilé le programme avec l’option -g pour avoir la meilleure utilisation de gdb. Il fonctionnera sans mais vous ne verrez que le nom de la fonction dans laquelle vous vous trouvez plutôt que son code source. Si vous voyez une ligne comme:

quand gdb démarre, vous saurez que le programme n’a pas été compilé avec l’option -g.

A l’invite de gdb, tapez break main. Cela dira au dévermineur de passer le code préliminaire d’initialisation du programme et de démarrer au début de votre code. Maintenant tapez run pour démarrer le programme-cela va démarrer au début du code d’initialisation et ensuite s’arrêtera lors de l’appel à main(). (Si vous vous êtes toujours demandé où main() était appelé, maintenant vous le savez !).

Vous pouvez maintenant vous déplacer dans le programme ligne par ligne en pressant n. Si vous arrivez à l’appel d’une fonction, vous pouvez entrer dans celle-ci en appuyant sur s. Une fois que vous êtes dans l’appel de la fonction, vous pouvez retourner dans le code appelant en appuyant sur f. Vous pouvez aussi utiliser up et down pour avoir une vue rapide de l’appelant.

Voici un exemple simple de comment détecter une erreur dans un programme avec gdb. Voici notre programme (avec une erreur délibérée):

Le programme met i à 5 et le passe à une fonction bazz() qui imprime le nombre que nous lui avons donné.

Puis nous compilons et exécutons le programme obtenu

Ce n’était pas ce que nous attendions ! Il est temps de voir ce qui se passe !

Arrêtons-nous une minute! Comment anint a eu la valeur 4231? Ne l’avons-nous pas mis à 5 dans main()? Remontons dans main() et regardons.

Oh ! En regardant dans le code, nous avons oublié d’initialiser i. Nous aurions dû mettre

mais nous n’avions pas mis la ligne i=5;. Comme nous n’avons pas initialisé i, il a pris le nombre se trouvant dans la zone de mémoire quand le programme a démarré, ce qui dans ce cas était 4231.

Un fichier core est basiquement un fichier qui contient l’état complet du processus quand il s’est planté. Dans "le bon vieux temps", les programmeurs devait imprimer des listings en hexadécimal de fichiers core et transpirer sur leur manuels de code machine, mais la vie est maintenant un peu plus facile. Par chance, sous FreeBSD et les autres systèmes 4.4BSD, un fichier core est appelé nomprog.core plutôt que juste core, pour mieux savoir à quel programme appartient un fichier core.

Pour examiner un fichier core, démarrez gdb de façon habituel. Plutôt que de taper break ou run, tapez

Si vous n’êtes pas dans le même répertoire que le fichier core, vous devrez faire dir /path/to/core/file d’abord.

Vous devriez voir quelque chose comme cela:

Dans ce cas, le programme a été appelé a.out, aussi le fichier core s’appelle a.out.core. Nous pouvons voir que le programme s’est planté car il a essayé d’accèder à une zone dans la mémoire qui n’était pas disponible dans la fonction appelée bazz.

Quelquefois il est utile de pouvoir voir comment une fonction a été appelée car le problème peut avoir eu lieu bien avant dans la pile des appels dans un programme complexe. La commande bt demande à gdb d’afficher une trace inverse de la pile des appels:

La fonction end() est appelée lorsque le programme se plante; dans ce cas, la fonction bazz() a été appelée main().

Une des plus belles caractéristiques de gdb est qu’il peut se brancher sur un programme qui s’exécute déjà. Bien sûr, cela suppose que vous ayez les privilèges suffisants pour le faire. Un problème habituel est quand vous vous déplacez dans un programme qui se dédouble et que vous voulez tracer le programme fils cependant le dévermineur ne vous laissera seulement tracer le père.

Ce que vous devez faire est de démarrer un autre gdb, utiliser ps pour trouver l’ID du processus fils et faire

dans gdb, et déverminer ensuite comme d’habitude.

"C’est tout simple," pensez-vous certainement," mais pendant le temps que je faisais ça, le processus fils sera déjà parti loin". Ne vous en faites pas, noble lecteur, voici comment faire (avec l’appui des pages d’info de gdb):

Maintenant tout ce que nous avons à faire est de nous brancher sur le processus fils, de mettre PauseMode à 0 et d’attendre que l’appel à la fonction sleep() retourne !

Malheureusement, les systèmes Unix ne sont pas fournis avec des sortes d’environnements de développement intégrés tout-ce-que-vous-avez-toujours-voulu-et-beaucoup-plus-dans-un-ensemble-gigantesque que d’autres sytèmes ont. Toutefois, il est possible de se faire son propre environnement. Cela n’est pas forcément aussi joli et il peut ne pas être autant intégré mais vous pouvez le personnaliser comme vous voulez. Et c’est gratuit. Et vous en avez les sources.

La clé de tout cela est Emacs. Maintenant il y a des gens qui le détestent, mais beaucoup l’aiment. Si vous êtes un du premier groupe, j’ai peur que cette section ait peu d’intérêt pour vous. Vous aurez besoin d’une quantité moyenne de mémoire pour le faire fonctionner-Je recommenderai 8Mo en mode texte et 16Mo dans X pour avoir un minimum de performances.

Emacs est basiquement un éditeur hautement personnalisable -en effet, il a été personnalisé au point de ressembler plus à un système d’exploitation qu’à un éditeur! Beaucoup de développeurs et d’administrateurs système passent en fait pratiquement tout leur temps à travailler dans Emacs, en ne le quittant qu’à leur déconnexion.

Il est impossible de dire tout ce qu’Emacs peut faire ici, mais voici quelques unes des caractéristiques d’intérêt pour les développeurs:

Et sans doute beaucoup plus que je n’ai survolé.

Emacs peut être installé sur FreeBSD en utilisant Emacs le logiciel porté Emacs.

Une fois installé, démarrez-le et faites C-h t pour lire un cours sur Emacs-cela signifie maintenir la touche control, presser h, relâcher la touche control et presser t. (Alternativement, vous pouvez utiliser la souris pour sélectionner Emacs Tutorial dans le menu Help).

Bien que Emacs possède des menus, il est valable d’apprendre les raccourcis clavier, étant plus rapide quand vous éditez quelque chose d’appuyer sur un couple de touches que de reprendre la souris et de cliquer au bon endroit. Et, quand vous discutez avec des utilisateurs expérimentés d’Emacs, vous trouverez qu’ils parlent souvent de choses comme “M-x replace-s RET foo RET bar RET” aussi il est utile de savoir ce que cela veut dire. Et dans tous les cas, Emacs possède beaucoup trop de fonctions pour qu’elles soient dans les barres de menus.

Heureusement, il est assez simple de récupérer les raccourcis clavier car ils sont affichés à côté des éléments des menus déroulants. Mon conseil est d’utiliser un élément de menu pour, disons, ouvrir un fichier jusqu’à ce que vous sachiez comment cela fonctionne et que quand vous vous sentez à l’aise avec, essayez C-x C-f. Quand vous serez content avec ça, passez à une autre commande du menu.

Si vous ne pouvez pas vous rappeler de ce qu’une combinaison de touches particulières fait, sélectionnez Describe Key dans le menu Help et tapez-la-Emacs vous dira ce qu’elle fait. Vous pouvez aussi utiliser l’élément de menu Command Apropos pour trouver toutes les commandes qui contiennent un mot particulier, avec leur raccourci clavier.

De cette manière, l’expression ci-dessus signifie maintenir la touche Meta, taper x, relâcher la touche Meta, taper replace-s (raccourci pour replace-string- une autre caractéristique d’Emacs est que vous pouvez abréger les commandes), appuyer sur la touche Entrée, taper foo (la chaîne que vous voulez remplacer), presser la touche Entrée, taper bar (la chaîne que vous voulez substituer à foo) puis appuyer sur Entrée une dernière fois. Emacs va alors faire l’opération chercher-remplacer que vous avez demandé.

Si vous vous demandez ce qu’est cette touche Meta, il s’agit d’une touche spéciale que beaucoup de stations de travail Unix possèdent. Malheureusement, les PC n’en ont pas, aussi c’est habituellement la touche alt (ou si vous n’avez pas de chance, la touche échap).

Oh, et pour sortir d’Emacs, faites C-x C-c (ce qui signifie maintenir la touche control appuyée, appuyer c et relâcher la touche control. Si vous avez des fichiers non sauvegardés ouverts, Emacs vous demandera si vous voulez les sauvegarder. (Ignorez le bout de documentation où il est dit que C-z est la manière habituelle de quitter Emacs- qui quitte Emacs en le laissant tourner en tâche de fond et qui n’est vraiment utile que si vous avez un système sans terminal virtuel).

Emacs fait des choses merveilleuses; une partie est intégrée directement, une autre doit être configurée.

Plutôt que d’utiliser un macro langage propriétaire pour la configuration, Emacs utilise une version du Lisp spécialement adaptée pour les éditeurs, connue sous le nom d’Emacs Lisp. Celui-ci peut être assez utile si vous voulez poursuivre et apprendre quelque chose comme le Common Lisp, car il est considérablement plus petit que le Common Lisp (bien que déjà assez gros!).

La meilleure façon d’apprendre l’Emacs Lisp est de télécharger le cours d’Emacs

Toutefois, il n’y a pas besoin de connaître le Lisp pour commencer la configuration d’Emacs, car j’ai inclus un exemple de fichier .emacs qui devrait être suffisant pour commencer. Copiez juste celui-ci dans votre répertoire utilisateur et redémarrez Emacs si celui-ci s’exécute, il lira les commandes du fichier et (si tout va bien!) vous donnera une configuration basique utile.

Malheureusement, il y a beaucoup trop de choses ici pour les expliquer en détail; toutefois, il y a un ou deux points qui valent d’être mentionnés.

Maintenant, Emacs est très bien si vous voulez seulement programmer dans des langages déjà fournis dans le fichier .emacs (C, C++, Perl, Lisp et Scheme), mais qu’arrive-t-il si un nouveau langage appelé "whizbang" sort, plein d’excitantes fonctionnalités ?

La première chose à faire est de savoir si whizbang est fourni avec des fichiers de configuration pour Emacs. Ceux-ci se terminent habituellement par .el, raccourci pour "Emacs Lisp". Par exemple, si whizbang est un logiciel porté FreeBSD, nous pouvons localiser ces fichiers en faisant

et les installer en les copiant dans le répertoire Lisp d’Emacs. Sur FreeBSD 2.1.0-RELEASE, il s’agit de /usr/local/shared/emacs/site-lisp.

Aisni par exemple, si la sortie de la commande find était

nous ferions

Ensuite, nous devons décider quel extension les fichiers source whizbang ont. Disons qu’il s’agit de fichiers se terminant par .wiz. Nous devons ajouter une entrée dans notre fichier .emacs pour être sûr qu’Emacs sera capable d’utiliser les informations dans whizbang.el.

Trouvez l’entrée auto-mode-alist dans .emacs et ajoutez une ligne pour whizbang, comme :

Cela signifie qu’Emacs ira automatiquement dans la fonction whizbang-mode quand vous éditerez un fichier se terminant par .wiz.

Juste en-dessous, vous trouverez l’entrée font-lock-auto-mode-list. Ajoutez whizbang-mode à celle-ci comme ceci :

Cela signifie qu’Emacs autorisera toujours font-lock-mode (ie colorisation de la syntaxe) pendant l’édition d’un fichier .wiz.

Et c’est tout ce qui est nécessaire. S’il y a quoique ce soit que vous voulez de fait automatiquement quand vous ouvrez un fichier .wiz, vous pouvez ajouter un whizbang-mode hook (voir my-scheme-mode-hook pour un exemple simple qui ajoute auto-indent, l’auto-indentation).

L’exemple de code suivant contient un dépassement de capacité conçu pour écraser l’adresse de retour et "sauter" l’instruction suivant immédiatement l’appel de la fonction. (Inspiré par 4)

Examinons quel serait l’aspect de l’image mémoire de ce processus si nous avions entré 160 espaces dans notre petit programme avant d’appuyer sur Entrée.

Evidemment une entrée plus malveillante pourrait être imaginée pour exécuter des instructions déjà compilées (comme exec(/bin/sh)).

La solution la plus simple au problème de débordement de pile est de toujours utiliser de la mémoire restreinte en taille et les fonctions de copie de chaîne de caractères. strncpy et strncat font parties de la libraire standard du C. Ces fonctions acceptent une valeur de longueur comme paramètre qui qui ne devrait pas être plus grande que la taille du tampon de destination. Ces fonctions vont ensuite copier taille octets de la source vers la destination. Toutefois, il y a un certain nombre de problèmes avec ces fonctions. Aucune fonction ne garantit une terminaison par le caractère NULL si la taille du tampon d’entrée est aussi grand que celui de destination. Le paramètre taille est aussi utilisé de façon illogique entre strncpy et strncat aussi il est facile pour les programmeurs d’être déroutés sur leur utilisation convenable. Il y a aussi une perte significative des performances comparé à strcpy lorsque l’on copie une courte chaîne dans un grand tampon puisque strncpy remplit de caractères NULL jusqu’à la taille spécifiée.

Dans OpenBSD, une autre implémentation de la copie de mémoire a été créée pour contourner ces problèmes. Les fonctions strlcpy et strlcat garantissent qu’elles termineront toujours le tampon de destination par un caractère NULL losque l’argument de taille est différent de zéro. Pour plus d’informations sur ces fonctions, voir 6. Les fonctions strlcpy et strlcat d’OpenBSD ont été inclues dans FreeBSD depuis la version 3.5.

Le concept de Prison ("Jail") étend chroot() en limitant les droits du super-utilisateur pour créer un véritable serveur virtuel. Une fois qu’une prison est mise en place, toute communication réseau doit avoir lieu au travers de l’adresse IP spécifiée, et le droit du "privilège super-utilisateur" dans cette prison est sévèrement gêné.

Tant qu’il se trouve en prison, tout test avec les droits du super-utilisateur dans le noyau au travers d’un appel à suser() échouera. Toutefois, quelques appels à suser() ont été changés par la nouvelle interface suser_xxx(). Cette fonction est responsable de fournir ou de retirer les accès aux droits du super-utilisateur pour les processus emprisonnés.

Un processus super-utilisateur dans un environnement emprisonné a le pouvoir de :

Jail est un outil très utile pour exécuter des applications dans un environnement sécurisé mais il a des imperfections. Actuellement, les mécanismes IPC (Inter-Process Communications) n’ont pas été convertis pour utiliser suser_xxx aussi des applications comme MySQL ne peuvent être exécutée dans une prison. L’accès super-utilisateur peut avoir un sens très limité dans une prison, mais il n’y aucune façon de spécifier exactement ce que très limité veut dire.

Posix a réalisé un document de travail qui ajoute l’audit d’évènement, les listes de contrôle d’accès, les privilèges fins, l’étiquetage d’information, et le contrôle d’accès mandaté.

Il s’agit d’un travail en cours et c’est l’objectif du projet TrustedBSD. Une partie du travail initial a été intégré dans FreeBSD-current (cap_set_proc(3)).

FreeBSD fournit un fichier d’inclusion "makefile" que vous pouvez utiliser pour compiler rapidement votre ajout au noyau.

Lancer simplement la commande make avec ce fichier Makefile créera un fichier skeleton.ko qui peut être chargé dans votre système en tapant :

La commande mknod nécessite quatre arguments pou créer un fichier spécial de périphérique. Vous devez spécifier le nom de ce fichier spécial de périphérique, le type de périphérique, le numéro majeur et le numéro mineur du périphérique.

Le périphérique système de fichiers, ou devfs, fournit l’accès à l’espace des noms des périphériques du noyau dans l’espace du système de fichiers global. Ceci élimine les problèmes de pilote sans fichier spécial statique, ou de fichier spécial sans pilote installé. Devfs est toujours un travail en cours mais il fonctionne déjà assez bien.

Pour faire de particulièrement utile avec un périphérique PCI, vous aurez besoin d’obtenir les registres d’adresse de base (Base Address Registers ou BARs) de l’espace de configuration PCI. Les détails spécifiques au PCI sur l’obtention du registre d’adresse de base sont masqués dans la fonction bus_alloc_resource().

Par exemple, un pilote typique aura sa fonction attach() similaire à ceci :

Des références pour chaque registre d’adresse de base sont gardées dans la structure softc afin qu’elle puisse être utilisée pour écrire dans le périphérique plus tard.

Ces références peuvent alors être utilisées pour lire ou écrire dans les registres du périphérique avec les fonctions bus_space_*. Par exemple, un pilote peut contenir une fonction raccourci pour lire dans un registre spécifique à une carte comme cela :

De façon similaire, une autre peut écrire dans les registres avec :

Ces fonctions existent en versions 8bit, 16bit et 32bit et vous devriez utiliser bus_space_{read|write}_{1|2|4} en conséquence.

Les interruptions sont alloués à partir du code orienté objet du bus de façon similaire aux ressources mémoire. D’abord une ressource IRQ doit être allouée à partir du bus parent, et alors le gestionnaire d’interruption doit être règlé pour traiter cet IRQ.

A nouveau, un exemple de fonction attach() en dit plusqu’un long discours.

Sur les PC, les périphériques qui veulent utiliser la gestion de bus DMA doivent travailler avec des adresses physiques. C’est un problème puisque FreeBSD utilise une mémoire virtuelle et travaille presque exclusivement avec des adresses virtuelles. Heureusement, il y a une fonction vtophys() pour nous aider.

La solution est toutefois un peu différente sur Alpha, et ce que nous voulons réellement est une fonction appelée vtobus().

Il est très important de désallouer toutes les ressources qui furent allouées pendant attach(). Unsoin tout particulier doit être pris pour désallouer les bonnes choses même lors d’un échec afin que le système reste utilisable lorsque votre driver meurt.