diff --git a/index.md b/index.md index ee7bd9f..a0d365c 100644 --- a/index.md +++ b/index.md @@ -1,4 +1,4 @@ -See my resume in [:us:](en_US/) or in [:fr:](fr_FR/), or download them in [:us:](pdf/english.pdf) or in [:fr:](pdf/french.pdf). You may also download the [lite version](pdf/french-lite.pdf) or my [portfolio](pdf/portfolio-french.pdf), both in french. +See my resume in [:us:](en_US/) or in [:fr:](fr_FR/), or download them in [:us:](pdf/english.pdf) or in [:fr:](pdf/french.pdf). You may also download the [lite version](pdf/french-lite.pdf) in french. --- diff --git a/pdf/portfolio-french.pdf b/pdf/portfolio-french.pdf deleted file mode 100644 index 773090d..0000000 Binary files a/pdf/portfolio-french.pdf and /dev/null differ diff --git a/portfolio-french.tex b/portfolio-french.tex deleted file mode 100644 index be8dab6..0000000 --- a/portfolio-french.tex +++ /dev/null @@ -1,203 +0,0 @@ -%% portfolio-french.tex -%% Copyright 2015-2018 Gaël PORTAY -% -% This work may be distributed and/or modified under the -% conditions of the LaTeX Project Public License, either version 1.3 -% of this license or (at your option) any later version. -% The latest version of this license is in -% http://www.latex-project.org/lppl.txt -% and version 1.3 or later is part of all distributions of LaTeX -% version 2005/12/01 or later. -% -% This work has the LPPL maintenance status `maintained'. -% -% The Current Maintainer of this work is Gaël PORTAY. -% -% This work consists of the file portfolio-french.tex. - -\documentclass[a4paper]{article} -\usepackage{hyperref} -\usepackage[T1]{fontenc} -\usepackage[utf8]{inputenc} -\usepackage[francais]{babel} - -\title{Portfolio} -\author{Gaël PORTAY} -\date{\today} - -\begin{document} -\sloppy -\maketitle - -\begin{abstract} -Je suis ingénieur en informatique, spécialisé en \textit{Linux Embarqué}. J'ai découvert l'informatique à l'âge de 10 ans. Aujourd'hui, je totalise un peu plus de 6 ans d’expérience dans le monde professionnel. Je suis passionné et curieux : j'aime apprendre et comprendre comment fonctionne les «~choses~». Je suis également autodidacte et j'aime partager mes expériences et mes connaissances avec les autres.\\ - -Mon travail étant la partie immergée de l'iceberg, il est par conséquent, assez difficile de montrer le fruit de mon travail par des images ou des photos. En lieu et place\footnote{Plus tard, j'illustrerai mes propos par quelques schémas.}, j'expliquerai comment et avec quels outils j'ai réalisé mes travaux. De même, certains de mes développements étant du domaine du propriétaire, je ne présenterai ici que mes développements libres.\\ - -Je mets en évidence deux projets pour démontrer mes compétences : le \textit{BSP}\footnote{Board Support Package : le logiciel bas niveau d'une carte électronique.} pour la partie électronique ainsi que la partie système d'exploitation au niveau noyau ; et deux projets personnels pour la partie système d'exploitation au niveau espace utilisateur. L'annexe montre mon implication vis-à-vis de la communauté du Logiciel Libre.\\ - -Voici une liste non-exhaustive de mes compétences : langage \textit{C/C++} (libc, STL), mécanisme de \textit{polling} (epoll), \textit{Git}, \textit{Systèmes Linux} (espace utilisateur et noyau), scripts \textit{Shell} (POSIX, redirection, pipe...), \textit{Python}, \textit{Makefile}, \textit{Autotools}, \textit{Kconfig}, \textit{Yocto}, \textit{crosstool-ng}, \textit{QEMU}... -\end{abstract} -\clearpage - -\tableofcontents -\clearpage - -\part{\href{https://fr.wikipedia.org/wiki/Board_support_package}{Board Support Package}} - -\underline{Mots clés} : \textit{C}, \textit{noyau}, \textit{device-tree}, \textit{électronique}, \textit{SoC}, \textit{bootloader}.\\ - -J'ai développé le logiciel bas niveau (appelé \textit{BSP}) de deux nouvelles cartes électroniques développées par \href{http://www.overkiz.com/}{Overkiz}. Ces deux plateformes sont basées sur deux \href{https://fr.wikipedia.org/wiki/Syst\%C3\%A8me_sur_une_puce}{systèmes sur puce} d'\textit{Atmel} (ou \textit{SoC}\footnote{System-on-Chip.}) : \href{http://www.atmel.com/devices/SAM9G25.aspx}{SAM9G25} et \href{http://www.atmel.com/products/microcontrollers/arm/sama5.aspx}{SAMA5D31}.\\ - -Mon travail consistait à faire fonctionner notre distribution \textit{Linux} maison sur ces deux nouvelles plateformes. J'ai validé le fonctionnement de l'ensemble des composants utilisés sur les deux cartes électroniques : les \textit{DELs}, les boutons, le réseau (\textit{Ethernet}), les différents bus de communication (\textit{UART}, \textit{USB}, \textit{I2C} et \textit{SPI}), les différentes mémoires (\textit{NAND} et \textit{RAM}) ainsi que le contrôleur de gestion de l'alimentation (\textit{PMIC}\footnote{Power Management Integrated Circuit.}).\\ - -Le développement de ces deux \textit{BSP}s se décompose en deux parties distinctes : -\begin{itemize} -\item le \textit{bootstrap} : comme chargeur d'amorçage (\textit{bootloader}) pour démarrer un noyau \textit{Linux}, et -\item le \textit{device-tree} : pour définir la carte électronique au niveau du noyau \textit{Linux}. -\end{itemize} - -\section{AT91Boostrap} - -\underline{Mots clés} : \textit{C}, \textit{UBI}, \textit{bootloader}.\\ - -Le \textit{bootstrap} est le premier logiciel à s’exécuter après la mise sous tension du \textit{SoC} d'\textit{Atmel}. Il est chargé par le \textit{ROM code} interne du \textit{micro-processeur}. Le \textit{ROM code} est appelé \textit{bootloader} de niveau 1 tandis que le \textit{bootstrap} est appelé \textit{bootloader} de niveau 2. Le rôle du \textit{bootstrap} est d’initialiser les mémoires afin de charger un logiciel depuis une mémoire morte (\textit{ROM}) en mémoire vive (\textit{RAM}) et d’exécuter son contenu. \\ - -Mon développement s'est déroulé en deux étapes : -\begin{itemize} -\item ajout du support de la carte électronique et -\item ajout du support d'UBI\footnote{Unsorted Block Image.}. -\end{itemize} - -\subsection{Support des cartes électroniques} - -Ces deux nouvelles cartes électroniques sont similaires aux cartes d'évaluations proposées par \textit{Atmel} du point de vue des composants utilisés (\textit{RAM} et \textit{NAND}). J'ai réutilisé les développements effectués par le fabricant pour initialiser correctement ces deux mémoires, notamment en terme de timings. - -\subsection{Support d'UBI} - -\underline{Mots clés} : \textit{C}, \textit{UBI}.\\ - -Le noyau \textit{Linux} étant amené à évoluer durant le cycle de vie du produit, j'ai fiabilisé ses mises à jour contre des évènements que l'on ne peut pas maîtriser comme les coupures de courant. Pour ce faire, j'ai dupliqué tous les éléments critiques pouvant être soumis à des mises à jour et j'ai utilisé la technologie \textit{UBI} pour détecter leur intégrité via les \textit{méta-données}\footnote{Le marqueur de mise à jour du volume dans la table des volumes et le Contrôle de Redondance Cyclique (\textit{CRC}).} liées à cette technologie.\\ - -Chaque élément critique est par conséquent stocké deux fois dans la partition \textit{UBI}. Une première fois sous son propre nom (exemple : «~\textbf{kernel}~») et une seconde fois sous son nom suivi du suffixe «~\textit{-spare}~» (exemple : «~\textbf{kernel-spare}~»).\\ - -La procédure de mise à jour consiste à mettre à jour d'abord le volume principal, puis le volume de rechange. Ainsi, si la coupure de courant a lieu lors de la mise à jour du premier volume, alors on détecte sa non-intégrité grâce à la technologie \textit{UBI} et on charge le second. Si la coupure de courant a lieu lors de la mise à jour du second volume, on charge quoi qu'il arrive le premier volume car celui-ci est valide. La procédure de mise à jour doit prendre en compte une reprise sur erreur et reprendre la mise à jour là où elle a été interrompue.\\ - -Comme ni le \textit{ROM code}, ni le \textit{bootstrap} ne prennent en charge la gestion d'\textit{UBI}, j'ai implémenté cette fonctionnalité\footnote{Cette fonctionnalité est en cours de soumission pour être intégrée au projet. Elle est disponible via l'\textit{URL} \url{https://github.com/Overkiz/at91bootstrap/commit/be87d62fef7d11f7cf77c182ec9e76f89bdc9c78}}. - -\section{Kernel et Device-Tree} - -Le \textit{device-tree} est un langage qui formalise les schématiques d'une carte électronique an niveau noyau. Muni des schématiques des deux nouvelles plateformes, j'ai créé leur fichier descriptif en activant uniquement les périphériques utilisés. Par ailleurs, c'est dans ce fichier que l'on associe un périphérique à son \textit{pilote} (\textit{driver}). Grâce à ce couple périphérique/pilote, j'ai généré une configuration spéciale du noyau pour chaque plateforme afin que ce dernier n’intègre que les pilotes nécessaires à la gestion de la carte électronique.\\ - -Ces deux nouvelles cartes électroniques sont intégrées à la dernière version stable du noyau \textit{Linux}\footnote{A partir de la version 4.2.} (on parle de \textit{mainline}). -\begin{itemize} -\item at91-kizboxmini : \url{https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/at91-kizboxmini.dts?id=refs/tags/v4.2} -\item at91-kizbox2 : \url{https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/at91-kizbox2.dts?id=refs/tags/v4.2} -\end{itemize} -\clearpage - -\part{Projets Personnels} - -\section{\href{https://github.com/gportay/initramfs/}{InitRAMFS}} - -\underline{Mots clés} : \textit{Busybox}, \textit{OverlayFS}, \textit{GNU/Makefile}, \textit{Kconfig}, \textit{crosstool-NG}, \textit{QEMU}.\\ - -Je développe actuellement un système de fichier racine (\textit{rootfs}) minimal axé autour du projet \href{http://www.busybox.net/}{Busybox}. Il peut être utilisé par un noyau \textit{Linux} soit comme un «~\href{https://www.kernel.org/doc/Documentation/initrd.txt}{Initial RAM-Disk}~» soit comme un «~\href{https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt}{Initial RAMFS}~».\\ - -\textit{InitRAMFS} n'a pas pour vocation de concurrencer \href{http://buildroot.org/}{Buildroot} ou \href{https://www.yoctoproject.org/}{Yocto}. Il fournit simplement système minimal pour des systèmes sans écran (\textit{headless}). Le système ouvre une connexion via une liaison série (\textit{login}, \textit{tty}) et gère automatiquement les périphériques ainsi que la configuration réseau.\\ - -Le c\oe{}ur du projet est architecturé autour de l'exécutable \textit{Busybox} compilé en \textit{statique} et de plusieurs \textit{scripts Shell} de ma propre invention. Il tire partie de plusieurs \textit{applets Busybox} pour remplir les tâches minimales d'un tel système. Il utilise notamment : -\begin{itemize} -\item \href{http://www.busybox.net/downloads/BusyBox.html#ifplugd}{ifplugd}, \href{http://www.busybox.net/downloads/BusyBox.html#udhcpc}{udhcpc} et \href{http://www.busybox.net/downloads/BusyBox.html#zcip}{zcip} pour la configuration automatique du réseau via \textit{DHCP} ou la configuration en \textit{Link-Local}, -\item \href{http://www.busybox.net/downloads/BusyBox.html#mdev}{mdev} pour la gestion dynamique des périphériques (périphériques de stockage de masse, interfaces réseaux via \textit{USB}...), -\item \href{http://www.busybox.net/downloads/BusyBox.html#syslogd}{syslogd} et \href{http://www.busybox.net/downloads/BusyBox.html#klogd}{syslogd} pour les messages dit de \textit{log}. -\end{itemize} - -Le but étant de solliciter un maximum d'\textit{applet Busybox}.\\ - -\textit{InitRAMFS} gère de manière dynamique le montage des périphériques de stockage de masse (comme une \textit{clé USB}) dans le point de montage \textbf{/media/} grâce aux \textit{applets} \href{http://www.busybox.net/downloads/BusyBox.html#mdev}{mdev} et \href{http://www.busybox.net/downloads/BusyBox.html#blkid}{blkid} et d'un \textit{script Shell} \href{https://github.com/gportay/initramfs/blob/old-fixes-and-dev-need-study/packages-initramfs/mdev/usr/sbin/automount}{automount}.\\ - -\textit{InitRAMFS} configure (et dé-configure) également dynamiquement les interfaces réseaux au branchement (et débranchement) des câbles via l'applet \href{http://www.busybox.net/downloads/BusyBox.html#ifplugd}{ifplugd}. L'interface réseau obtient alors soit une adresse \textit{IP} attribuée par le serveur \textit{DHCP} via l'applet \href{http://www.busybox.net/downloads/BusyBox.html#udhcpc}{udhcpc}, soit une adresse \textit{IP} en \textit{Link-Local} via l'applet \href{http://www.busybox.net/downloads/BusyBox.html#zcip}{zcip} si aucun serveur \textit{DHCP} n'est présent sur le \textit{LAN}.\\ - -\textit{InitRAMFS} utilise un \href{https://github.com/gportay/initramfs/blob/master/packages-initramfs/ramfs/etc/init}{script Shell} en lieu et place du système d'init traditionnel implémenté par l'applet \href{http://www.busybox.net/downloads/BusyBox.html#init}{init}.\\ - -J'ai ajouté le support d'\href{https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt}{OverlayFS} afin de palier au problème de la volatilité d'un système de fichier racine en \href{https://fr.wikipedia.org/wiki/Ramfs}{RAMFS}. En effet, tout redémarrage fait perdre toutes traces de modifications.\\ - -Le système de compilation est basé sur un \textit{Makefile} utilisant les spécificités additionnelles de \textit{GNU/Make}. Il est donc indispensable d'utiliser \textit{gmake} pour construire l'\textit{initramfs}. Par exemple, j'utilise les règles avec des «~\href{https://www.gnu.org/software/make/manual/html_node/Double_002dColon.html}{::}~».\\ - -La commande suivante génère le fichier \textit{initramfs.cpio} : une archive \textit{CPIO} contenant le \textit{rootfs}. Elle est ensuite utilisée par le noyau \textit{Linux} lors de sa compilation pour la concaténer à son image et faire du noyau un système complet en une seule et même image. - -\begin{verbatim} -$ make [initramfs.cpio] -\end{verbatim} - -La commande suivante permet de générer une image du noyau complète avec son \textit{rootfs} concaténé. - -\begin{verbatim} -$ make kernel [KIMAGE=zImage] -\end{verbatim} - -\textit{InitRAMFS} se destinant au domaine de l'embarqué, l'architecture cible du processeur est souvent différente de celle de la machine servant à générer l'image (\textit{ARM}, \textit{MIPS}...). J'ai ajouté la possibilité d'utiliser un environnement de compilation croisé via la variable \textit{CROSS\_COMPILE} (tout comme pour le noyau \textit{Linux}). - -\begin{verbatim} -$ make CROSS_COMPILE=arm-unknown-gnueabi- -\end{verbatim} - -Si la \href{https://fr.wikipedia.org/wiki/Cha\%C3\%AEne_de_compilation}{chaîne de compilation croisée} (\textit{toolchain}) n'existe pas, \textit{InitRAMFS} utilise le projet \href{http://crosstool-ng.org/}{crosstool-NG} pour la générer. La commande suivante permet de la compiler. - -\begin{verbatim} -$ make CROSS_COMPILE=arm-unknown-gnueabi- toolchain -\end{verbatim} - -\textit{InitRAMFS} se veut utile du point de vue d'un développeur \textit{BSP}. Le projet intègre d'autre projets comme \href{https://matt.ucc.asn.au/dropbear/dropbear.html}{dropbear} (serveur et client \textit{SSH}), \href{http://git.kernel.org/cgit/utils/kernel/kexec/kexec-tools.git/}{kexec-tools} (exécution d'un noyau à chaud) ou encore \href{http://landley.net/toybox/}{toybox} (un autre projet comme \textit{Busybox} qui s'installe à la place ou en plus dans \textbf{/media/toybox/}). Ces autres outils sont également compilés en statique.\\ - -Par ailleurs, j'ai ajouté la possibilité de pouvoir configurer l'image générée avec \href{http://ymorin.is-a-geek.org/projects/kconfig-frontends}{Kconfig} : le même système utilisé par le noyau, \textit{BuildRoot} ou encore \textit{crosstool-NG}. - -\begin{verbatim} -$ make menuconfig -\end{verbatim} - -\textit{InitRAMFS} supporte également l'émulation via \href{http://wiki.qemu.org}{QEMU}. Je rencontre actuellement quelques problèmes avec la gestion du réseau via un pont. Les résolutions \textit{DNS} ne semblent pas fonctionner. Une configuration spéciale permet de se passer des droits administrateurs \textit{root}. - -\begin{verbatim} -$ make runqemu -\end{verbatim} - -\section{\href{https://github.com/gportay/mpkg/}{MPKG}} - -\underline{Mots clés} : \textit{POSIX}, \textit{script Shell}, \textit{grep}, \textit{sed}, \textit{tar}, \textit{wget}.\\ - -En parallèle au développement d'\textit{InitRAMFS}, je développe un système de paquet minimaliste écrit uniquement en \textit{Shell} \href{https://fr.wikipedia.org/wiki/POSIX}{POSIX}. \textit{MPKG} ne nécessite aucun interpréteur tierce (ni \textit{Python}, ni \textit{Lua}, ni \textit{Perl}...) ; il requiert uniquement un interpréteur \textit{Shell} et quelques outils standards que l'on retrouve sur n'importe quel système \textit{POSIX} minimal (\textit{grep}, \textit{sed}, \textit{tar}, \textit{wget}...). Par conséquent, il est possible de l'utiliser avec un simple système comme \textit{Busybox}.\\ - -\textit{MPKG} se veut moins complexe et plus léger que les systèmes de paquets existants (\textit{Debian} ou \textit{RPM}\footnote{RedHat Package Manager.}) ; il est majoritairement inspiré du formalisme de \textit{Debian} mais n'est, en aucun cas, compatible avec ce dernier.\\ - -Le format binaire du paquet est simple : une archive \textit{TAR} \textit{gzippée} représentant une archive des données à partir de la racine (\textit{rootfs}). L’extension est \textbf{.tgz}. Les \textit{méta-données} du paquet sont stockées dans un chemin spécifique : \textbf{/var/lib/mpkg//}.\\ - -Ce format est à comparer à celui utilisé par \textit{Debian} où ils ont fait le choix de créer une archive plus complexe en séparant les données utiles du paquet et des \textit{meta-données}. Un paquet \textit{Debian} est une archive \textit{AR} de deux sous archives \textit{TAR} \textit{gzippées} : une pour le \textit{rootfs} (\textbf{data.tar.gz}) et une autre pour les \textit{méta-données} (\textbf{control.tar.gz}). Cette archive \textit{AR} contient également un fichier supplémentaire définissant la version binaire du format du paquet (\textbf{debian-binary}).\\ - -\textit{MPKG} ne gère que les fonctionnalités essentielles d'un système de paquet. A savoir : -\begin{itemize} -\item un nombre restreint de mots-clés pour les \textit{meta-informations} du paquet : nom du paquet, version et la liste des dépendances. -\item les scripts de pré et post installation (\textit{preinst}/\textit{postinst}) -\item les scripts de pré et post désinstallation (\textit{prerm}/\textit{postrm}) -\end{itemize} - -Écrire \textit{MPKG} en \textit{Shell POSIX} me permet d'exprimer mes connaissances dans ce langage de script, en usant du mécanisme de parallélisation (pipe) et des redirections pour le rendre plus performant. -\clearpage - -\appendix -\section{Contributions} -Voici une liste de mes contributions dans différents projets libres : -\begin{itemize} -\item \textbf{Linux} : \url{https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=refs\%2Ftags\%2Fnext-20150610&qt=grep&q=PORTAY} -\item \textbf{OPKG} : \url{http://git.yoctoproject.org/cgit/cgit.cgi/opkg/log/?qt=grep&q=PORTAY} -\item \textbf{cURL} : \url{https://github.com/bagder/curl/commits?author=gportay} -\item \textbf{AT91Bootstrap} : -\begin{itemize} -\item \url{https://github.com/linux4sam/at91bootstrap/commits?author=gportay} -\item \url{https://github.com/linux4sam/at91bootstrap/pull/25} -\end{itemize} -\item \textbf{Dropbear} : \url{https://github.com/mkj/dropbear/commits?author=gportay} -\end{itemize} -Ainsi que lien vers mes dépots hebergés par GitHub : \url{https://www.github.com/gportay}. -\end{document}