Allwinner VPU support in mainline Linux status update (week 11)

After the initial submission of the Sunxi-Cedrus driver last week, I spent most of this week looking into the sun4i DRM (Direct Rendering Manager) driver. The driver is in charge of handling the display pipeline on Allwinner SoCs. Tight integration of the VPU and the display pipeline is required in order to achieve decent video playback performance. That is because the output format of the VPU is a 32×32 tiled format based on NV12, a YUV420 semi-planar format, with one plane for the Y component (luminance) and one plane for the interleaved UV components (chrominance). While NV12 is a standard format for video output, the tiling is rather specific to the VPU, so the frames have to be untiled before they can be used. This operation, when done in software, is rather slow. Moreover, software-based compositing of the decoded frames is also a bottleneck that impacts the overall performance.

In order to circumvent these issues, we will be using the display engine itself to untile the VPU output frames and show the untiled frames directly in a dedicated hardware plane, that is then composed with the primary plane. This requires several features and especially support for the display engine’s frontend, that has the required components to untile and decode the frames. Partial support for the frontend was recently contributed by Maxime Ripard and is on its way to landing in the mainline Linux kernel, providing a base for my VPU-related work. Maxime’s patches allow scaling hardware planes (among other things), a feature that will be very useful for scaling videos to the screen size in hardware rather than software (which is another major bottleneck for performance).

Support for untiling the VPU frames is approaching completion (luminance is correctly decoded while chrominance is not yet correctly handled).

Decoding the MB32 tiled format with sun4i-drm

Once the frames are properly shown on screen, it’ll be time to make sure that dmabuf works as expected, which will allow us to send buffers from the VPU to the display engine without any copy, thus improving performance.

We should be making good progress on this topic over the upcoming week and start contributing patches to the sun4i DRM driver, so stay tuned for our next status update!

Security: 17 Things

A list for protecting yourself and others from the most common and easiest-to-pull-off security crimes. more>>

Private Internet Access Goes Open Source, New Raspbian Image Available, Scarlett Johansson Image an Attack Vector on PostgreSQL and More

News briefs for March 16, 2018. more>>

Linux 4.15 released, Bootlin contributions

Penguin from Mylène Josserand
Drawing from Mylène Josserand,
based on a picture from Samuel Blanc under CC-BY-SA

After a month of February busier than usual, with the renaming of our company from Free Electrons to Bootlin, our participation to FOSDEM and the welcoming of Maxime Chevallier, the latest addition to our engineering team, our article on the latest release of the Linux kernel arrives a bit late, more than a month after Linux 4.15 has been released by Linus Torvalds.

As usual, did an interesting coverage of this release cycle merge window, highlighting the most important changes: The first half of the 4.15 merge window and The rest of the 4.15 merge window. Due to the now well-known Spectre and Meltdown vulnerabilities and the resulting effort to try to mitigate them, 4.15 required a -rc9, which happened the last time back in 2011 with the 3.1, Torvalds said.

According to Linux Kernel Patch statistics, Free Electrons (now Bootlin) contributed 150 patches to this release, making it the 16th contributing company by number of commits.

The main highlights of our contributions are:

  • In the RTC subsystem, Alexandre Belloni made a number of improvements to various drivers, mainly making them use the nvmem subsystem where appropriate, and use the recently introduced rtc_register_device() API.
  • In the MTD subsystem, both Boris Brezillon and Miquèl Raynal made a number of contributions, mainly fixes.
  • For Marvell platforms
    • Antoine Ténart contributed a few fixes to the >inside-secure crypto accelerator driver, used on Marvell Armada 3700 and Armada 7K/8K
    • Antoine Ténart also contributed fixes and improvements to the mvpp2 network driver, used for the Ethernet controller on the Marvell Armada 7K/8K. His improvements include preparation work to support Receive Side Scaling (RSS).
    • Antoine Ténart enabled more networking ports and features in some Armada 7K/8K boards, especially SFP ports on Armada 7040 DB and Armada 7040 DB.
    • Boris Brezillon contributed a few fixes to the Marvell CESA crypto accelerator driver, used on the older Orion, Kirkwood, Armada 370/XP/38x processors. He migrated the driver to use the skcipher interface of the Linux kernel crypto framework.
    • Grégory Clement enabled NAND support on Armada 7K, and contributed a number of fixes around MMC support for some Marvell boards.
    • Thomas Petazzoni contributed a few minor Device Tree enhancements for Marvell platforms: fixing MPP muxing on an older Kirkwood platform, enabling more PCIe ports on Armada 8040 DB, etc.
    • Miquèl Raynal contributed support for more advanced statistics in the mvpp2 network driver.
    • Miquèl Raynal added support for the extended UART for the Marvell Armada 3720 processor, both in the UART driver and in the Device Tree.
  • For the RaspberryPi platform, Boris Brezillon contributed a few fixes to the vc4 display driver, and added support for the new DRM_IOCTL_VC4_GEM_MADVISE ioctl, which can be used to ask the userspace applications to purge inactive buffers when allocations start to fail in the kernel.
  • For Allwinner platforms
    • Mylène Josserand contributed a fix for the Allwinner A83 clock driver, fixing I2C bus clocks.
    • Quentin Schulz contributed a few fixes to the sun4i-gpadc-iio.c driver, which is used for the ADCs on several Allwinner processors.
    • Maxime Ripard made a number of fixes to the sun8i-codec driver, fixing clock issues, left/right channels inversion, etc.
    • Maxime Ripard made a number of improvements to the sun4i DRM display driver.
    • Maxime Ripard improved the support for the A83 processor (described the UART1 controller, the MMC1 controller, added support for display clocks) and added the Device Tree for a new A83 device.
    • Maxime Ripard also did a number of cleanups and misc improvements in a significant number of Device Tree files for Allwinner platforms.
  • Thomas Petazzoni made a few fixes to the sh_eth network driver, used on several Renesas SuperH platform, as part of a recent project Bootlin did on SuperH 4.

Bootlin engineers are not only contributors, but also maintainers of various subsystems in the Linux kernel, which means they are involved in the process of reviewing, discussing and merging patches contributed to those subsystems:

  • Maxime Ripard, as the Allwinner platform co-maintainer, merged 108 patches from other contributors
  • Boris Brezillon, as the MTD/NAND maintainer, merged 34 patches from other contributors
  • Alexandre Belloni, as the RTC maintainer and Atmel platform co-maintainer, merged 50 patches from other contributors
  • Grégory Clement, as the Marvell EBU co-maintainer, merged 24 patches from other contributors

Here is the commit by commit detail of our contributons to 4.15:

Oracle Patches Spectre for Red Hat

Red Hat's Spectre remediation currently requires new microcode for a complete fix, which leaves most x86 processors vulnerable as they lack this update. Oracle has released new retpoline kernels which completely remediate Meltdown and Spectre on all compatible CPUs, which I install and test on CentOS here. more>>

Linus Bashes CTS Labs, GNOME 3.28 Released, Project ACRN and More

News briefs for March 15, 2018. more>>

kernel, udev et systemd : la gestion du hotplug

La gestion des événements hardware est un domaine un peu mystérieux sous linux. Le noyau voit des événements, udev réagit, et il se passe des choses.

Cet article va essayer de démystifier cet aspect des systèmes linux en implémentant quelque chose de simple : changer automatiquement la luminosité de l’écran lorsque l’alimentation d’un ordinateur portable est branchée. Pour cela nous allons trouver l’événement noyau, le remonter via udev et systemd jusqu’à un script qui s’occupera de la mise à jour.

Udev et systemd : suivre le périphérique

Lorsque le noyau linux repère un événement intéressant, il doit prévenir un daemon en espace utilisateur. Pour faire cela, il envoie un message à travers un type de socket particulier : les sockets netlink.

Les sockets netlink ont toutes sortes d’utilisation dans le monde linux

  • détection d’événements hotplug
  • filtrage en espace utilisateur de paquets netfilter
  • réaction à des changements de paramètres réseau
  • et beaucoup d’autres.

Il n’est pas nécessaire de traiter nous même les événements netlink. Le daemon udev s’en charge pour nous.

Lorsqu’udev reçoit un événement noyau il utilise un grand nombre de règles pour réagir à cet événement. C’est lui qui est chargé, entre autre, de :

  • charger un module noyau pour du matériel qui en aurait besoin
  • créer des liens dans udev (le devnode lui-même est créé par le noyau)
  • paramétrer le matériel (type de clavier, sensibilité des touchpad et touchscreen)
  • appeler ifupdown (si c’est encore utilisé sur votre distribution)
  • prévenir d’autres daemons de l’arrivée du périphérique

Parmi les daemons qui surveillent les événements udev, l’un d’entre eux nous intéresse particulièrement : systemd. systemd est chargé de lancer des daemons lorsque du nouveau matériel apparaît. C’est ce mécanisme que nous allons utiliser pour modifier notre luminosité.

Surveiller les évenements kernel

La première question que nous devons résoudre concerne notre hardware : Quel événement est généré lorsque notre alimentation est branchée. Udev fournit un outil pour cela : udevadm. L’option monitor permet de surveiller les évenements reçu par le daemon.

Lorsqu’on lance cette commande, puis que l’on débranche notre alimentation, on obtient les traces suivantes :

root@pcrosen:/etc/systemd/system# udevadm monitor
 monitor will print the received events for:
 UDEV - the event which udev sends out after rule processing
 KERNEL - the kernel uevent

KERNEL[4487.028467] change /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP0 (power_supply)
 UDEV [4487.146286] change /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP0 (power_supply)
KERNEL[4487.149554] change /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
 UDEV [4487.152380] change /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0 (power_supply)

Nous avons deux types de traces :

  • les événements KERNEL qui correspondent à ceux que le noyau envoie à udev
  • les événements UDEV qui sont ceux générés par udev à partir de l’événement précédent

Notre action a affecté deux périphériques : ADP0 (l’alimentation, qui change d’état) et BAT0 (la batterie, qui commence à se décharger). Notons que l’événement généré est de type change. Il ne s’agit pas de l’ajout ou la suppression d’un périphérique mais bien d’un changement d’état du périphérique.

Maintenant que nous savons quel périphérique nous intéresse, voyons quels informations udev peut nous donner sur celui-ci.

Les attributs de notre périphérique

Systemd ne suit pas tous les périphériques du système. Seuls ceux qui sont explicitement marqués pour être suivi le sont. Le périphérique ADP0 n’est pas suivi. Nous allons ajouter la règle udev pour qu’il le soit.

Pour que udev marque un périphérique pour être suivi par systemd il faut lui associer un TAG systemd. Pour associer ce tag nous devons préciser à udev quel critère permet de choisir le périphérique qui nous intéresse. Nous pourrions nous baser sur le nom du périphérique mais celui-ci peut varier selon les PC. Nous allons trouver des critères un peu plus génériques.

Udev peut filtrer selon un très grand nombre de critères. Pour savoir quel critère utiliser, udev fournit la commande udevadm info -a qui liste toutes les propriétés filtrables d’un périphérique.

Pour connaître les critères utilisables sur notre alimentation, nous lançons donc la commande suivante:

root@pcrosen:/etc/udev/rules.d# udevadm info -a /sys/devices/LNXSYSTM\:00/LNXSYBUS\:00/ACPI0003\:00/power_supply/ADP0

Udevadm info starts with the device specified by the devpath and then
 walks up the chain of parent devices. It prints for every device
 found, all possible attributes in the udev rules key format.
 A rule to match, can be composed by the attributes of the device
 and the attributes from one single parent device.

looking at device '/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP0':

looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00':

looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00':

looking at parent device '/devices/LNXSYSTM:00':

udev peut filtrer sur des propriétés du périphérique, mais également sur des propriétés des périphériques parents. udev nous fournit donc toute l’arborescence des critères.

Nous devons filtrer les périphériques à faire surveiller par udev. Ici, nous avons deux critères qui nous intéressent

  • Notre périphérique a un attribut SUBSYSTEM==”power_supply”
  • Le noeud parent a un attribut DRIVERS==”ac”

Un périphérique qui répond à ces deux critères est une alimentation externe. C’est ce que nous cherchons.

Écrire une règle udev

Udev va chercher des règles dans plusieurs endroits. Ajoutons un fichier 99-backlight_update.rules dans /etc/udev/rules.d/ contenant la ligne suivante :

SUBSYSTEM=="power_supply" DRIVERS=="ac" TAG+="systemd" ENV{SYSTEMD_ALIAS}+="/sys/subsystem/power_supply/main_AC"

Notez que certains champs utilisent un ‘==’ d’autre un ‘=’. Les ‘==’ sont utilisés pour définir une condition.

Notez également le ‘S’ à DRIVERS. Le ‘S’ ici sert à spécifier que la condition s’applique à au moins un des drivers parents.

  • SUBSYSTEM==”power_supply” : Le périphérique doit appartenir au sous-système power_supply
  • DRIVERS==”ac” : L’un des parents du périphérique doit apartenir au sous-système ‘ac’
  • TAG+=”systemd” : Marquer le périphérique pour être suivi par systemd
  • ENV{SYSTEMD_ALIAS}+=”/sys/subsystem/power_supply/main_AC” : Indiquer à systemd que le périphérique doit avoir un alias.

Une fois le fichier créé, nous devons demander à udev de recharger sa configuration, faire redétecter le périphérique qui nous intéresse et vérifier que tout fonctionne.

 root@pcrosen:/etc/udev/rules.d# udevadm control -R
 root@pcrosen:/etc/udev/rules.d# udevadm trigger /sys/class/power_supply/ADP0
 root@pcrosen:/etc/udev/rules.d# udevadm info /sys/class/power_supply/ADP0
 P: /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP0
 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP0
 E: SUBSYSTEM=power_supply
 E: SYSTEMD_ALIAS=/sys/subsystem/power_supply/main_AC
 E: TAGS=:systemd:

Faire le script shell

L’étape suivante consiste à faire un petit script shell qui sera appelé sur les événements de notre périphérique et qui réagira à ceux-ci.

Pour savoir si nous sommes branchés, nous pourrions aller lire l’information dans le sysfs mais systemd fournit un utilitaire pour détecter cela: systemd-ac-power. En utilisant ce script nous pouvons facilement vérifier si nous sommes branchés et modifier la luminosité en conséquence.

Le script est appelé sur les événements de branchement et de débranchement. Il modifie la luminosité via un fichier particulier dans le sysfs:


if /lib/systemd/systemd-ac-power ; then
 cat /sys/class/backlight/intel_backlight/max_brightness > /sys/class/backlight/intel_backlight/brightness
 echo 30 > /sys/class/backlight/intel_backlight/brightness

Note : si vous n’avez pas systemd-ac-power, vous pouvez redemander l’état de la batterie via udevadm info. L’information POWER_SUPPLY_ONLINE vaut 1 si le cable d’alimentation est branchée, 0 sinon.

Où mettre notre fichier

Notre script est un exécutable, mais il n’est pas fourni par la distribution et il n’est pas censé être utilisé par un être humain, uniquement par systemd. Quel est l’endroit correct pour mettre ce script ?

  • Quasiment tout doit être dans /usr
  • Ce fichier ne provient pas de la distribution : /usr/local
  • Ce fichier n’est pas censé être utilisé par l’utilisateur. Il ne va pas dans /usr/local/bin ou /usr/local/sbin
  • Ce fichier est interne à notre application, d’autres applications ne sont pas censée l’utiliser. Il ne va pas dans /usr/local/share
  • Nous allons donc le mettre dans le répertoire de /usr/local/lib/backlight_update.

Faire le service correspondant

Vérifier que systemd surveille notre device

Comme nous l’avons dit précédement, systemd ne surveille que certains périphériques, pour savoir lesquels, il faut lancer la commande suivante

root@pcrosen:/etc/udev/rules.d# systemctl --type=device
 sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0003:00-power_supply-ADP0.device loaded active plugged /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP0
 sys-devices-LNXSYSTM:00-LNXSYBUS:00-PNP0A08:00-device:01-PNP0C09:00-ACPI0008:00-iio:device0.device loaded active plugged /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C09:00/ACPI0008:00/iio:devic
 sys-devices-pci0000:00-0000:00:02.0-drm-card0-card0\x2deDP\x2d1-intel_backlight.device loaded active plugged /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight
 sys-devices-pci0000:00-0000:00:14.0-usb2-2\x2d6-2\x2d6:1.0-bluetooth-hci0.device loaded active plugged /sys/devices/pci0000:00/0000:00:14.0/usb2/2-6/2-6:1.0/bluetooth/hci0
 sys-devices-pci0000:00-0000:00:1c.2-0000:02:00.0-net-wlp2s0.device loaded active plugged Wireless 7260 (Dual Band Wireless-AC 7260)
 sys-devices-pci0000:00-0000:00:1f.2-ata3-host2-target2:0:0-2:0:0:0-block-sda-sda1.device loaded active plugged LITEONIT_LMT-512L9M-11_MSATA_512GB 1
 sys-devices-pci0000:00-0000:00:1f.2-ata3-host2-target2:0:0-2:0:0:0-block-sda-sda2.device loaded active plugged LITEONIT_LMT-512L9M-11_MSATA_512GB 2
 sys-devices-pci0000:00-0000:00:1f.2-ata3-host2-target2:0:0-2:0:0:0-block-sda-sda3.device loaded active plugged LITEONIT_LMT-512L9M-11_MSATA_512GB 3
 sys-devices-pci0000:00-0000:00:1f.2-ata3-host2-target2:0:0-2:0:0:0-block-sda.device loaded active plugged LITEONIT_LMT-512L9M-11_MSATA_512GB
 sys-devices-platform-dell\x2dlaptop-leds-dell::kbd_backlight.device loaded active plugged /sys/devices/platform/dell-laptop/leds/dell::kbd_backlight
 sys-devices-platform-serial8250-tty-ttyS0.device loaded active plugged /sys/devices/platform/serial8250/tty/ttyS0
 sys-devices-platform-serial8250-tty-ttyS1.device loaded active plugged /sys/devices/platform/serial8250/tty/ttyS1
 sys-devices-platform-serial8250-tty-ttyS2.device loaded active plugged /sys/devices/platform/serial8250/tty/ttyS2
 sys-devices-platform-serial8250-tty-ttyS3.device loaded active plugged /sys/devices/platform/serial8250/tty/ttyS3
 sys-devices-virtual-block-loop0.device loaded active plugged /sys/devices/virtual/block/loop0
 sys-devices-virtual-misc-rfkill.device loaded active plugged /sys/devices/virtual/misc/rfkill
 sys-subsystem-bluetooth-devices-hci0.device loaded active plugged /sys/subsystem/bluetooth/devices/hci0
 sys-subsystem-net-devices-wlp2s0.device loaded active plugged Wireless 7260 (Dual Band Wireless-AC 7260)
 sys-subsystem-power_supply-main_AC.device loaded active plugged /sys/subsystem/power_supply/main_AC

LOAD = Reflects whether the unit definition was properly loaded.
 ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
 SUB = The low-level unit activation state, values depend on unit type.

19 loaded units listed. Pass --all to see loaded but inactive units, too.
 To show all installed unit files use 'systemctl list-unit-files'.

L’unité sys-subsystem-power_supply-main_AC.device est celle que nous souhaitons surveiller. Elle est apparue grâce à notre règle udev (plus précisément la partie SYSTEMD_ALIAS de notre règle). Commençons par générer des traces dans le journal, nous le connecterons à notre script plus tard.

Un service simple pour observer ce qui se passe

Lorsqu’un daemon écrit des traces sur stdout, systemd les envoie à journald. Notre service de surveillance, dans sa forme la plus simple, aura l’allure suivante

# /etc/systemd/system/backlight_update.service
 ExecStart=/bin/echo %n started

Une fois ce service écrit, nous pouvons le tester en surveillant journald sur un terminal

root@pcrosen:~# journalctl -fe -u backlight_update.service

Sur un autre terminal, nous demandons à systemd de recharger sa configuration, puis nous démarrons le service :

root@pcrosen:~# systemctl daemon-reload
 root@pcrosen:~# systemctl start backlight_update.service

Nous avons vu précédemment que le branchement causait un événement “change” sur udev. Ces événements deviennent des évenements “reload” pour systemd. Nous devons détecter ces évenements.

# /etc/systemd/system/backlight_update.service
 ExecStart=/bin/echo %n started
 ExecReload=/bin/echo %n reloaded
root@pcrosen:~# systemctl daemon-reload
root@pcrosen:~# systemctl start backlight_update.service
root@pcrosen:~# systemctl reload backlight_update.service

Systemd proteste car backlight_update n’est pas démarré. Notre service ne faisant rien d’autre que lancer la commande echo, il se termine immédiatement. Pour dire à systemd que notre service doit garder un pseudo-état “active” jusqu’à ce qu’il soit explicitement terminé, il faut utiliser la command RemainAfterExit

# /etc/systemd/system/backlight_update.service
 ExecStart=/bin/echo %n started
 ExecReload=/bin/echo %n reloaded
root@pcrosen:~# systemctl daemon-reload
root@pcrosen:~# systemctl start backlight_update.service
root@pcrosen:~# systemctl reload backlight_update.service

Nous avons un service qui trace les événements qu’il reçoit. Il ne nous reste plus qu’à le faire réagir aux événements “change” de notre alimentation.

L’instruction ReloadPropagatedFrom permet de propager l’événement reload depuis une autre unité. Dans notre cas, nous voulons propager vers notre service l’événement reload du .device.

# /etc/systemd/system/backlight_update.service

 ExecStart=/bin/echo %n started
 ExecReload=/bin/echo %n reloaded
root@pcrosen:~# systemctl daemon-reload

Lorsque nous débranchons et rebranchons notre alimentation, nous voyons les traces apparaître dans le journal.

Le vrai service

Notre système de détection fonctionne. Il ne reste plus qu’à lui associer le vrai script.


Nous devons encore expliquer à systemd que le service doit réagir à l’événement reload de l’alimentation, comme nous l’avons fait pour le service de trace.

# /etc/systemd/system/backlight_update.service
 Description=Update luminosity on AC plug event


Il ne nous reste plus qu’à expliquer à systemd quand lancer notre script. Il serait tentant de simplement démarrer le script au boot, mais le vrai événement que nous recherchons est la détection de l’alimentation par le noyau. Utilisons donc l’apparition du device pour démarrer notre service. La version finale de notre service a donc l’alure suivante :

# /etc/systemd/system/backlight_update.service
 Description=Update luminosity on AC plug event



Nous activons notre service :

root@pcrosen:~# systemctl enable backlight_update

Et nous avons terminé. Il ne reste plus qu’a redémarrer et vérifier que tout fonctionne…


Le hotplug linux peut sembler mysterieux mais, lorsque l’on ouvre la boite, il est assez simple de suivre l’enchaînement des événements

  • Le noyau détecte le périphérique
  • Le noyau prévient udev qui fait la mise en place initiale et prévient d’éventuels daemons plus complexes
  • Les daemons plus complexes réagissent.

Dans le cadre de cet article, le daemon plus complexe est systemd. Nous avons pu rapidement voir comment systemd peut suivre les états des périphériques et réagir à leur changement.

L’intégration du hotplug avec systemd est finalement assez simple et il est facile de mettre en place des systèmes complexes en intégrant cette logique dans le système de démarrage et de surveillance de systemd.

Help Us Cure Online Publishing of Its Addiction to Personal Data

Since the turn of the millennium, online publishing has turned into a vampire, sucking the blood of readers' personal data to feed the appetites of adtech: tracking-based advertising. Resisting that temptation nearly killed us. more>>

New Raspberry Pi 3B+, Infection Monkey, Samba Password Bug, Facebook's Profilo and More

News briefs for March 14, 2018. more>>

Complétez votre collection de magazines papier !

Des offres spéciales vous permettant d’acquérir les deux dernières années de vos magazines favoris sont désormais disponibles sur notre boutique en ligne. Elles vous permettront de retrouver tous les numéros publiés en 2016 et 2017 à un tarif avantageux, en version « papier ». Ces packs papier concernent aussi bien GNU/Linux Magazine, que MISC, Linux Pratique ou encore Hackable. Ils sont disponibles à la fois pour les particuliers et pour les professionnels.

Pour en savoir plus, rendez-vous sur :

Complétez votre collection de magazines papier !

Des offres spéciales vous permettant d’acquérir les deux dernières années de vos magazines favoris sont désormais disponibles sur notre boutique en ligne. Elles vous permettront de retrouver tous les numéros publiés en 2016 et 2017 à un tarif avantageux, en version « papier ». Ces packs papier concernent aussi bien GNU/Linux Magazine, que MISC, Linux Pratique ou encore Hackable. Ils sont disponibles à la fois pour les particuliers et pour les professionnels.

Pour en savoir plus, rendez-vous sur :

VIDEO: Learn how to mine Cryptocurrency, including Monero, using Linux.

It’s Here. The March 2018 Issue of Linux Journal Is Available for Download Now.

Boasting as many pages as most technical books, this month’s issue of Linux Journal comes in at a hefty 181—that’s 23 articles exploring topics near and dear to everyone from home automation hobbyists to Free Software advocates to hard-core hackers to high-level systems architects.


Mozilla's Firefox 59 Released, New Agones Project, SparkyLinux 5.3 Available, Hunt for Exoplanets and More

News briefs for March 13, 2018. more>>

Best Linux Desktop Environment

Best Laptop

What's the favorite LJ reader laptop?

The top three winners are: more>>

Eric Raymond's New UPS Project, Ubuntu's Bionic Beaver 18.04 Beta Released, Kernel Prepatch 4.16-rc5 and More

News briefs for March 12, 2018. more>>

Weekend Reading: Using Python in Science and Machine Learning

Python is easy to use, powerful, versatile and a Linux Journal reader favorite. We've round up some of the most popular recent Python-related articles for your weekend reading. more>>

What's the Geek Take on the GDPR?

Let us know how the GDPR is affecting your work. more>>

Allwinner VPU support in mainline Linux status update (week 10)

Just over a week ago, I started my internship focused on adding upstream Linux kernel support for the Allwinner VPU at Bootlin’s Toulouse office. The team has been super-friendly and very helpful to help me get settled and I’m definitely happy about moving to Toulouse for the occasion!

This first week of work was focused on studying and rebasing the work done by Florent Revest a year and a half ago. As a main development target, I went for an A33-based board, the SinA33 from Sinlinx. Florent’s patches for the sunxi-cedrus driver were rebased against the latest release candidate version of Linus’ tree, v4.16-rc4.

VPU decoding with Cedrus on the Sinlinx A33

The driver was then adapted to use the latest version of the V4L2 request API, a crucial piece of plumbing needed to provide coherency between setting specific controls for the media stream and the input/output buffers that these controls are related to. A few bugs needed fixing along the way, in order to avoid memory corruptions (use-after-free) and to properly schedule the VPU to run when a request is submitted. With these fixes the driver was ready, so it was sent for review on the linux-media mailing list. On the userspace side, the cedrus-specific libva was also updated to use the latest version of the request API.

The next step in the pipeline is to use a common buffer for the VPU’s decoded frame and the display controller’s plane, using dmabuf. This should bring a significant performance improvement and eventually allow for hardware-based scaling when decoding videos through the standard DRM/KMS interfaces. However, this requires adding support for the specific format used by the VPU (a multiplanar NV12 format with 32×32 tiles) into the display controller code.

Purism Announces Hardware Encryption, Debian for WSL, Slack Ending Support for IRC and More

News briefs for March 9, 2018. more>>

PME, numérisez et protégez votre production ! Expérimentez, validez et protégez votre entreprise ! - Bobigny (93) Le 26 mars 2018

Au cours de cet événement organisé par la CCI de Bobigny en partenariat avec le programme CAP'TRONIC, les participants pourront appréhender les enjeux liés à la protection du patrimoine économique et scientifique de l'entreprise, sa digitalisation via le programme régional "Usine Numérique Ile-de-France", l'impact du règlement RGPD sur le « business model » de l'entreprise et la compréhension de la directive RED appliquée, en particulier, aux objets connectés déployés au sein des entreprises.

Programme :

- 13h45-14h00 - Accueil

- 14h00 -15h30 - Protection du patrimoine scientifique et économique de la PME - Ministère de l'intérieur

  • Maîtrise des informations stratégiques et anticipation des risques
  • Intelligence économique
  • Participation à des salons et déplacements à l'étranger
  • Cybercriminalité – e-Réputation – Réseaux sociaux – Cloud computing
  • Utilisation des objets connectés

- 15h30-15h40 pause

- 15h40-16h10 - Programme "Usine Numérique Ile-de-France"
Présentation d'un programme régional pour les TPE/PME, soutenu par des fonds européens Feder, afin d'expérimenter des logiciels adaptés à l'industrie du futur - CAO, FAO, simulation, impression 3D.

- 16h10-17h10 - La nouvelle directive RED sur la sécurité des produits radio-électriques/objets connectés et le Règlement Général européen sur la Protection des Données (RGPD) : les bonnes pratiques - Europe Enterprise Network (EEN)
Remi Tingaud

- 17h10-17h30 - Devenir ingénieur par l'alternance – Ingé
Patrick Le MEN.

- 17h30 - 18h - Cocktail networking

Lieu de l'événement :

CCI Seine Saint Denis
191 avenue Paul Vaillant Couturier 93000 Bobigny

Transport en commun :
Metro ligne 5 - Bobigny Bablo Picasso

Inscription gratuite : cliquez-ici

Contact :

Christophe BRICOUT - 09 52 73 77 88

Le métier d’architecte en SI

Le métier d’architecte en systèmes d’information est souvent mal connu. Je vous propose de vous mettre à sa place pour imaginer une architecture innovante pour un nouveau SI.

Au sommaire de l’article

1. Les grandes étapes pour concevoir une architecture

2. Le scénario

3. La conception pas à pas

3.1 Gérer la base de données

3.2 Au plus vite

3.3 Choisir un consommateur de flux

3.4 Choisir un format d’échange

3.5 Invocation des services web

3.6 Intranet et Internet

3.7 Mise à jour à chaud

3.8 Gestionnaire de cloud

4. L’architecture finale



Philippe PRADOS

 > Lire l’intégralité de cet article sur notre plateforme de lecture en ligne Connect  

Retrouvez cet article (et bien d’autres) dans GNU/Linux Magazine n°207, disponible sur la boutique et sur Connect !

Sensibilisation à la fiabilisation d'un système électronique - Gardanne (13) Le 12 avril 2018

L'objectif de ce séminaire est de sensibiliser les participants à la fiabilisation des systèmes électroniques, et d'appréhender les taches à mener pour obtenir un produit fiable en fonction des contraintes appliquées.

CAP'TRONIC et SERMA TECHNOLOGIES s'associent pour vous proposer ce séminaire.

Inscription en ligne

- Intervenant : Jean-Michel LASSERRE - Responsable Pôle de compétence Fiabilité chez Serma Technologies


- Introduction
Définitions de la fiabilité
Défaillance abrupte (catalectique) et défaut d'usure
Exemple de mécanismes de défaillance

- Utilisation des mathématiques
Fonction taux de défaillance l(t)
Evolution du taux de défaillance dans le temps (courbe en baignoire)
Utilisation des lois statistiques et leur limitation :
- Exponentielle
- Weibull
Echantillonnage :
- Ki²

- Evaluation de la fiabilité prévisionnelle
Méthodes théoriques (MIL-HDBK-217, IEC 62380, FIDES)

- Notre approche : « La fiabilisation par la technologie »
Définition du profil de vie du produit
Analyse de risques (technologies versus profil de vie) :
- Composants et technologies
- Design
- Industrialisation Construction d'une filière d'évaluation ciblée

- Construction d'une filière d'évaluation ciblée
Validation des technologies : Composants, brasures etc…
Essais de robustesse : Le HALT
Essais de durabilité : Lois d'accélération (Arrhenius, Coffin Manson et Norris Landzberg, Hallberg Peck …)
Procédés de fabrication

- Positionnement du déverminage
Définition du déverminage
Efficacité du déverminage

- Questions / Réponses

Pré requis :

Niveau de technicien supérieur expérimenté ou d'ingénieur travaillant sur la qualité ou fiabilité d'un produit soit au niveau de sa fabrication ou de sa sélection.

Public concerné :

Responsable technique ou de bureaux d'étude, Ingénieur Chef de Projet, Responsable fiabilité.

Date :

Jeudi 12 avril 2018

Lieu :

Centre de microélectronique de Provence
880 route de Mimet

Contact : Alain BRITON - CAP'TRONIC - 06 30 46 78 99
Contact inscription : Dorothée WALLART - CAP'TRONIC - 04 38 78 37 36

Séminaire gratuit - Inscription obligatoire

Découvrez la préface de notre hors-série Mémo Python – saison 2 !

Vous l’attendiez et il est de retour : un nouveau hors-série au format « mémo » sur Python ! Dans cette saison 2, vous pourrez encore trouver une présentation synthétique de différents problèmes accompagnés de leurs solutions et, pour ceux d’entre vous qui souhaiteraient aller plus loin, de leurs explications.

Pour rappel, comme il est bien entendu impossible de recenser tous les problèmes possibles, ces « recettes » nécessiteront parfois des adaptations plus ou moins importantes, mais elles vous permettront de partir dans la bonne direction, de ne pas perdre inutilement du temps en testant une dizaine de solutions. Vous vous demandez comment implémenter le design pattern « Memento » ? Ne cherchez plus : prenez la recette que nous vous proposons et adaptez-la à votre programme !

Ce mémo comporte moins de recettes que le premier, car j’ai fait le choix d’aborder des problèmes légèrement plus complexes et qui nécessitent par voie de fait plus de code et des explications plus longues. Les recettes sont toujours classées en grandes familles :

– « Manipulez et représentez vos données » qui regroupe les problèmes liés à l’utilisation de données : stockage, conversion, opérations, etc. ;

– « Utilisez les bons outils » dans lequel vous trouverez comment travailler avec d’autres langages que Python tout en restant dans Python, et comment améliorer la qualité de votre code, fournir une documentation technique soignée, etc. ;

– « Exploitez la programmation réseau » vous permettra de travailler avec le Web, les services Google et les SMS ;

– et, enfin, « Organisez votre code » vous montrera différentes techniques permettant de structurer efficacement votre code et notamment comment implémenter un certain nombre de design patterns ou patrons de conception.

L’objectif de ce hors-série reste le même que pour le premier « Mémo Python » : vous aider à développer dans ce formidable langage qu’est Python et vous permettre de gagner du temps. Donc n’attendez plus, retournez coder et gardez ce guide à porter de main, il y a de fortes chances pour qu’il vous soit très utile… en tout cas c’est ce que nous souhaitons !

Tristan Colombo

Retrouvez GNU/Linux Magazine Hors-série n°95 :

À nouveau disponible en kiosque : le hors-série dédié à la sécurité des systèmes sans fil !

Vous l’avez manqué chez votre marchand de journaux ? Bonne nouvelle, notre guide spécial « Sécurité des systèmes sans fil » est actuellement de retour en kiosque ! Ce numéro réunit tous les outils qui vous permettront d’auditer vos systèmes sans fil. Il y sera d’abord question de communication sans fil avec une initiation au monde des télécommunications et de la radio logicielle sous l’angle de la sécurité. La radio-identification, puis la téléphonie mobile feront l’objet des chapitres suivants. Enfin, les objets connectés viendront clore ce numéro spécial avec l’analyse d’un porte-clé Bluetooth et des technologies utilisées par les télévisions connectées. En plus du kiosque, ce hors-série vous attend toujours sur notre plateforme de lecture en ligne Connect ainsi que sur notre boutique !

Au sommaire


p. 08 Introduction

Communication sans-fil

p. 16 Les tests d’intrusion en radiocommunication

p. 40 Exploration du spectre radio en radio logicielle

p. 54 Agressions électromagnétiques et risques SSI


p. 64 Proxmark 3, le couteau suisse RFID

Téléphonie mobile

p. 80 Interception passive et décodage de flux GSM avec gr-gsm

Objets connectés

p. 98 Attaques HbbTV par DVB-T

p. 112 Analyse d’un porte-clef connecté Bluetooth Low Energy

S2M : Smart Manufacturing Meeting - Paris - Espace Champeret Le 30 mai 2018

Smart Manufacturing Meetings (anciennement Paris Smart Manufacturing Summit) est le salon d'affaires de l'usine du futur. Cet événement vous propose non seulement un salon, mais aussi une convention d'affaires, un "disrupt challenge" et des conférences organisées par techniques de l'ingénieur avec le soutien de CAP'TRONIC.

L'événement Smart Manufacturing Meetings a pour objectif d'apporter une réponse technologique concrète aux porteurs de projets, acheteurs et aux entreprises en quête de solutions innovantes à même de répondre à leurs besoins.

Participer à S2m est pour vous l'assurance de n'avoir que des rendez-vous qualifiés, dont 90% sont programmés à l'avance, validés en amont par les 2 parties.
Voir comment fonctionnent les RDV d'affaires

Qu'est-ce que l'usine du futur ?
Derrière cette organisation se cache une vraie révolution :

  • Une production plus flexible qui permet de s'adapter à la demande en temps réel.
  • Une traçabilité poussée, qui permet de savoir où et quand a été fabriqué le produit, mais aussi comment.
  • Des machines capables de contacter un spécialiste apte à les dépanner à distance, ou pour se mettre à jour et améliorer leurs performances, grâce à Internet.
  • Une scénarisation du cycle de production grâce à laquelle la fabrication est pilotée en fonction du client et qui est capable de personnaliser le produit (taille, couleur, type d'emballage…).
  • Une optimisation des consommations par l'efficacité énergétique.

Les principaux outils nécessaires à cette mise en œuvre existent déjà : capteurs, automates, big data, Internet des objets, cloud computing… Plus qu'une révolution technologique, l'industrie du futur s'apparente plutôt à une réorganisation complète du mode de production avec les outils existants et donnant une plus grande importance au réseau. Cette nouvelle génération d'usines a pour objectif de relancer le dynamisme de l'industrie européenne via plusieurs actions : modernisation de la production, augmentation de la compétitivité, positionnement face aux enjeux de la mondialisation…

Consulter les thématiques technologiques

Le Disrupt challenge S2m 2018 permet aux offreurs de solution de n'importe quel type de structure (Start-up, PME, ETI…) déjà inscrite aux rendez-vous BtoB de candidater afin de présenter une technologie ou un service de rupture.
L'appel à candidatures du Disrupt Challenge

15 conférences, ateliers et tables rondes co-organisés par Techniques de l'ingénieur

Informations Pratiques

Les tarifs de l'événement
CAP'TRONIC propose à ses adhérents une participation à un tarif préférentiel, merci de contacter Michel Marceau pour plus d'information.

tel : +33 (0)1 46 90 22 35

L’édito de GNU/Linux Magazine n°213 !

Nous sommes nombreux à développer différents outils dans notre coin. Ces outils pourraient intéresser la communauté et pourtant, bien que convaincus de leur utilité et de la philosophie du logiciel libre, nous ne le faisons pas… Pourquoi ?

Nous voulons tous que notre programme soit le plus abouti possible en termes de fonctionnalités, mais pas toujours nécessairement en termes de qualité et de couverture de la documentation ou des tests. Écrire rapidement une preuve de concept et la documenter c’est une chose, distribuer un outil finalisé dont le code aura été nettoyé, qui sera correctement commenté, qui aura une couverture de tests minimale et une documentation fournie, agrémentée de tutoriels est une tout autre chose. Je suis bien placé pour en parler : de nombreux articles pourraient aboutir à des outils concrets, mais le manque de temps et les articles qui suivent m’empêchent d’aller au-delà. Bien entendu mon code est disponible sur le GitHub du magazine, mais il ne « vit » plus et n’est utile qu’en lien avec l’article auquel il est rattaché. Nous sommes donc face à trois cas possibles :

1. ne pas partager notre code et le garder jalousement (mon précieuuuux !) : notre notoriété n’en souffrira pas puisque personne ne verra ce que nous faisons ;

2. ne partager qu’un code parfaitement optimisé, documenté et avec une couverture de tests parfaite : ne nous leurrons pas, ce cas se rapprochera très fortement du premier cas, car nous ne pourrons partager que très peu de projets ;

3. partager le code alors qu’il est fonctionnel, mais n’est pas intégralement commenté, qu’il est documenté a minima pour pouvoir être installé et utilisé, et qu’il ne possède peut-être pas le moindre test unitaire.

Dans le troisième cas, il sera possible d’ « essaimer » de nombreux projets qui seront sans doute des projets « mort-nés » à vos yeux, mais n’en seront pas pour autant inutiles : vous aurez eu le mérite de partager votre méthode pour répondre à un problème. D’autres développeurs pourront s’en inspirer, voire les forker et ils pourront vous soumettre des remarques, soulever des problèmes ou proposer des corrections. Bien entendu, certains ne manqueront pas de critiquer sans aucune justification qu’une guerre d’église tel ou tel choix, de pointer l’absence de tests unitaires ou autre. Ces personnes-là sont généralement celles qui gardent leur code et ne font rien. Proposez-leur de soumettre un patch et vous n’en entendrez plus jamais parler…

Si l’un de vos projets prend le dessus sur les autres, car il suscite l’engouement de la communauté ou qu’il apparaît comme fondamental dans l’exercice de votre profession, vous pourrez alors lui consacrer le temps nécessaire pour le documenter de manière plus précise et améliorer la qualité du code.

Partagez donc votre code et votre expérience ! Si vous le souhaitez, vous pouvez même le faire au sein de votre magazine préféré : envoyez-moi vos idées ! En attendant, je vous souhaite une bonne lecture et je vous retrouverai le mois prochain…

Tristan Colombo

Retrouvez GNU/Linux Magazine n°213 :

Connectez votre Arduino au réseau mobile !

Pas de Wifi, pas de net… ? Hackable vous explique comment connecter votre Arduino au réseau mobile ! Vous découvrirez ainsi comment configurer votre shield ou carte GSM/GPRS, dialoguer avec le module SIM900 et créer une sonde de température qui vous alerte par SMS. Ce numéro inaugure également une nouvelle rubrique : nommée « Retro Tech », celle-ci vous permettra de découvrir ici le C64 Reloaded MK2, une carte mère flambant neuve pour faire revivre et améliorer le Commodore 64. Retrouvez sans plus tarder Hackable n°23 chez votre marchand de journaux, sur notre boutique en ligne ainsi que sur notre plateforme de lecture en ligne Connect !

Au sommaire


p. 04 NumWorks : la calculatrice open source française

p. 14 Visualisez, enregistrez ou transmettez la sortie HDMI de votre Pi


p. 24 Découvrez le multitâche avec votre ESP32

En couverture

p. 32 Connectez votre Arduino au réseau mobile

p. 48 Créez une sonde de température qui vous alerte par SMS

Embarqué & Informatique

p. 60 Boostez vos développements Linux sous Windows avec WSL

Nouvelle rubrique

Retro Tech

p. 72 C64 reloaded MK2 ou la renaissance du Commodore 64

Démontage, Hacks & Récup

p. 84 Votre ordinateur 8 bits sur platine : assez joué ! On passe au C !

Découvrez 59 nouvelles recettes pour accélérer vos développements Python !

Nous avons le plaisir de vous annoncer la publication de notre second « Mémo Python » (le premier se trouve ici) qui vous fournira 59 nouvelles recettes pour accélérer vos développements ! Les fiches pratiques fournies sont classées dans plusieurs catégories. La première vous permettra de manipuler, trier, convertir et représenter vos données. La seconde vous invitera à découvrir les outils qui vous permettront d’exploiter pleinement Python. La troisième vous expliquera comment récolter des données sur le Web, envoyer des SMS ou encore utiliser des services Google. La dernière partie, enfin, vous apprendra à organiser votre code et à utiliser les design patterns. Retrouvez dès à présent ce numéro spécial chez votre marchand de journaux, sur notre boutique en ligne ainsi que sur notre plateforme de lecture en ligne Connect !

Au sommaire

DONNÉES : Manipulez et représentez vos données

p.10 Arrondir un nombre à la dizaine supérieure ou inférieure

p.11 Définir des constantes « protégées »

p.12 Convertir une chaîne de caractères représentant un tuple en tuple

p.13 Créer une dataframe depuis un dictionnaire dont les clés sont des tuples

p.15 Filtrer les données d’une liste de dictionnaires en fonction d’un critère

p.16 Manipuler des octets

p.17 Convertir un octet en chaîne de 0 et de 1

p.18 Nettoyer des données en sortie de programme

p.19 Demander la saisie d’un mot de passe

p.21 Découper une chaîne de caractères en sous-chaînes de taille fixe

p.23 Créer une interface CLI avec autocomplétion

p.27 Compter le nombre d’occurrences des lettres d’une chaîne de caractères

p.28 Formater des chaînes de caractères

p.29 Grouper des chaînes de caractères par taille

p.30 Effectuer des opérations sur les colonnes d’une DataFrame Pandas

p.32 Combiner les colonnes d’une DataFrame Pandas

p.35 Nettoyer des données CSV avec Pandas

p.37 Effectuer des tests à la chaîne

p.38 Utiliser l’opérateur * pour récupérer les données d’une liste

p.39 Parcourir plusieurs listes avec une seule boucle

p.40 Trier une liste d’entiers lue sous forme de chaîne de caractères

p.41 Rafraîchir une fenêtre graphique Pygame

OUTILS : Utilisez les bons outils

p.44 Compiler Python

p.47 Afficher de manière lisible une structure complexe

p.49 Utiliser une classe Java dans un script Python

p.50 Documenter un projet avec Sphinx

p.56 Utiliser une fonction C dans du Python

p.59 Utiliser une fonction Fortran dans du Python

p.60 Compiler un programme Python en Bytecode

p.61 Vérifier la conformité PEP 8 d’un code

p.63 Gérer les environnements virtuels avec Pipenv

p.67 Étudier l’impact d’une modification en désassemblant du code

p.68 Conserver des données de manière persistante

p.70 Présenter du code Python avec Jupyter

p.74 Optimiser le temps d’exécution d’une fonction avec un cache

p.75 Effectuer des installations de modules sur différentes versions de Python

p.76 Visualiser les portions de code les plus lentes

RÉSEAU : Exploitez la programmation réseau

p.80 Envoyer des SMS

p.83 Recevoir et analyser des SMS

p.85 Envoyer des e-mails avec Gmail

p.87 Accéder aux évènements d’un agenda Google Calendar

p.91 Rechercher et analyser des données sur le Web et générer un document CSV

p.94 Récolter des données web avec Scrapy

p.98 Remplir un formulaire et effectuer des clics automatiques sur des pages web

STRUCTURE : Organisez votre code

p.102 Réduire la consommation mémoire d’un code

p.104 Composer des décorateurs

p.106 Créer un opérateur de classe

p.107 Créer un Context Manager

p.108 Appliquer le principe du slicing à un générateur

p.109 Créer une boucle de type do… while

p.110 Utiliser une structure switch

p.111 Utiliser un compteur sans avoir à gérer une variable

p.112 Utiliser le design pattern « Chaîne de responsabilité »

p.114 Utiliser le design pattern « Mémento »

p.117 Utiliser le Design Pattern « Adapter »

p.119 Utiliser le Design Pattern « Facade »

p.120 Utiliser le Design Pattern « Strategy »

p.122 Utiliser le Design Pattern « Factory Method »

p.124 Explorer le contenu d’une classe