Courbot Alexandre

Dans le vaste monde des systèmes de gestion de base de données (SGBD), le nom de SQLite ne vient pas aussi rapidement à l'esprit que PostgreSQL ou MySQL/MariaDB. Et pourtant ! Utilisée absolument partout, plus appropriée que ses consœurs pour un grand nombre d'usages, SQLite est l'illustration du logiciel effleurant la perfection au point de se rendre invisible. Essayons de donner à ce triomphe du logiciel libre un peu de la lumière qu'il mérite.

Après avoir étudié les différentes formes et transformations d'un programme depuis le code source jusqu'à l'exécutable chargé, il nous reste à nous intéresser aux mécanismes qui régissent son exécution. Celle-ci doit s'effectuer dans un cadre très strict, contrôlé à outrance par un autre programme qui joue le rôle d'autorité du système : le noyau.

Au cours des précédents articles, nous nous sommes familiarisés avec les étapes permettant de construire un programme binaire ainsi qu'avec le format ELF dans lequel il est stocké sur le disque. Ce mois-ci, nous allons découvrir comment le système charge ce format en vue de son exécution.

Dans le précédent article, nous avions disséqué le processus de compilation d'un programme et étudié les différents états qu'il traverse. Mais le fichier binaire obtenu à la fin de cette chaîne nous semble bien opaque... Pourtant, bien que la distinction soit toujours faite entre fichiers « programmes » exécutables et fichiers « classiques » de données, les premiers ne sont guère différents des seconds en ce qu'ils obéissent à un format bien précis et sont gérés par un programme tiers, le chargeur. Afin de mieux comprendre ce qui fait un programme, nous allons dans le présent article disséquer le format exécutable ELF utilisé par Linux et de nombreux autres systèmes d'exploitation.

Compiler, lier, exécuter, … autant de tâches familières pour le programmeur que vous êtes. Mais les détails de ces opérations sont plus confidentielles. Par exemple, connaissez-vous les formes que prend un programme durant sa construction ? Savez-vous comment il est chargé en mémoire et exécuté ? Comment il communique avec le noyau et les bibliothèques du système ? Cette série vous fera découvrir les ficelles de la production et de l'exécution d'un programme sous Linux, un sujet vaste qui nous fera plonger jusque dans les détails du noyau et nous aidera à devenir un meilleur programmeur, conscient de la relation entre son code, le système et le matériel.

Développer son projet open source est une chose, le faire parvenir jusqu'à ses utilisateurs potentiels en est une autre. L'époque où l'utilisateur moyen de Linux acceptait de compiler le source d'un logiciel est en effet révolue et tout le monde n'a pas l'honneur de voir son projet figurer dans les dépôts officiels des distributions. La solution consiste alors à fournir soi-même les paquets binaires pour le plus de plates-formes possible – une démarche fastidieuse et frustrante, mais l'OpenSUSE Build Service est là pour vous simplifier la vie.

Cela fait déjà quelque temps que nous naviguons dans les méandres de SQLite, et celui-ci doit déjà commencer à vous sembler familier. Après avoir défini des fonctions personnalisées, nous allons apprendre à créer nos propres définitions de tables. Celles-ci auront une particularité par rapport aux tables classiques de SQLite : leur stockage et leur accès sera sous notre entière responsabilité.

Durant les deux premiers articles, nous avons découvert SQLite et les différents moyens de l'utiliser au travers des API C et Python. Nous avons ainsi constaté la facilité avec laquelle nous pouvions l'embarquer dans nos propres applications. À partir de maintenant, nous allons étudier les différentes façons d'étendre SQLite, c'est-à-dire d'augmenter ses fonctionnalités selon nos besoins.

Lors du premier article, nous avions fait une approche rapide de SQLite, de ses concepts et de son API C. Cette fois-ci, nous allons passer un peu plus de temps sur les index, dont la bonne utilisation est critique pour le design d'une base de données. Nous verrons que ceux-ci ne peuvent pas résoudre tous les problèmes, mais qu'il est simple avec SQLite de combler les faiblesses du langage SQL avec les tables virtuelles, ce que propose le module de recherche rapide de texte FTS3. Nous profiterons aussi de l'occasion pour passer en revue l'API Python, plus simple et flexible que la C, pour réaliser un petit moteur de recherche de documentation.