Catégories
Non classé

Fonctions étrangères

Pour réaliser notre projet nous devons pouvoir nous interfacer en Rust avec la bibliothèque C ZBoss. Le C étant beaucoup plus dangereux que le Rust, et différent, de nombreuses précautions sont à prendre. Cet article recense les outils et les bonnes pratiques à suivre pour interagir avec du code étranger dans notre projet.

Caisses intéressantes

cty

Fournit les types C de base (on ne peut pas utiliser libc pour notre cible).

On a les correspondances suivantes :

CctyRust (ARM)
charc_chari8
signed charc_schari8
unsigned charc_ucharu8
shortc_shorti16
unsigned shortc_ushortu16
intc_inti32
unsigned (int)c_uintu32
longc_longi32
unsigned longc_ulongu32
long longc_longlongi64
unsigned long longc_ulonglongu64
floatc_floatf32
doublec_doublef64
XXbool
T *X*mut T
const T *X*const T
void **mut c_void*mut c_void
const void **const c_void*const c_void
size_tsize_tusize
ptrdiff_tptrdiff_tisize
Correspondance des types C, cty et Rust

Bien entendu les types de taille fixe de stdint peuvent être utilisés :

C (stdint.h)ctyRust
int8_tint8_ti8
uint8_tuint8_tu8
int16_tint16_ti16
uint16_tuint16_tu16
uint32_tuint32_tu32
int32_tint32_ti32
int64_tint64_ti64
uint64_tuint64_tu64
Correspondance des types stdint, cty et Rust

cstr_core

Les chaînes de caractères en Rust ne sont pas construites de la même manière qu’en C : il n’y a pas de caractère nul à la fin, et les caractères nuls sont admis au sein de la chaîne.

cstr_core fourni CStr (et CString si l’allocation est activée) comme chaîne se comportant comme en C.

rust-bindgen

A partir des entêtes C (éventuellement C++) d’une bibliothèque, génère les prototypes et les structures de données à l’interface adaptés à Rust.

Note : la caisse peut être utilisée pour la génération (build script, donc utilisé comme dépendance dans Cargo sous [build.dependencies]), puis enlevée des dépendances pour alléger le projet, ou encore utilisée dans une caisse à part du projet dédiée aux bindings.

Attributs utiles

#[link(name = « ext_library »)]

Indique au compilateur que les fonctions d’un bloc extern sont à lier à la bibliothèque donnée.

Exemple :

#[link(name = "git2")]
extern "C" {
    pub fn git_libgit2_init() -> c_int;
    pub fn git_libgit2_shutdown() -> c_int;

    . . .

}

#[repr(C)]

Force l’agencement en mémoire d’une structure à suivre les règles du C (ordre des champs, espacement entre les champs, alignement)

#[repr(C)]
pub struct git_error {
    pub message: *const c_char,
    pub klass: c_int,
}

#repr(align(n))

Force l’alignement sur n bytes, n doit être une puissance de 2.

#[no_mangle]

Empêche le mangling par défaut du symbole, utile pour aider le linker à retrouver les symboles en multi-langage.

Techniques et bonnes pratiques

Unsafe et contrat

Lorsqu’une fonction ou un trait sont déclarés comme unsafe il est impératif de documenter le contrat d’utilisation, c’est-à-dire de préciser le cadre d’utilisation pour ne pas avoir de comportement indéfini.

Exemple dans la bibliothèque standard : la fonction Vec::get_unchecked :

pub unsafe fn get_unchecked<I>(&self, index: I) -> &I::Output
    where
        I: SliceIndex<Self>,
    {
        // SAFETY: the caller must uphold most of the safety requirements for `get_unchecked`;
        // the slice is dereferencable because `self` is a safe reference.
        // The returned pointer is safe because impls of `SliceIndex` have to guarantee that it is.
        unsafe { &*index.get_unchecked(self) }
    }

Ce contrat est essentiel car s’il est violé, cela peut introduire des comportements indéfinis dans du code Rust supposé sûr.

Utiliser une variable globale externe en Rust

Utiliser static dans le bloc extern lié à la bibliothèque externe :

#[link(name = "readline")]
extern {
    static rl_readline_version: libc::c_int;
}

Utiliser une fonction C en Rust

On déclare la fonction dans un bloc extern "C". Tous les appels à celle-ci sont nécessairement unsafe.

La déclaration en C :

// header.h
int git_libgit2_init();

Le code Rust :

// main.rs
extern "C" {
    pub fn git_libgit2_init() -> c_int;
}

fn main() {
    unsafe {
        git_libgit2_init();
    };
}

Fonctions variadiques

On peut utiliser les fonctions variadiques du C en Rust :

extern {
    fn foo(x: i32, ...);
}

fn main() {
    unsafe {
        foo(10, 20, 30, 40, 50);
    }
}

Utiliser une fonction Rust en C

On utilise #[no_mangle] et extern "C" comme vu précédemment.

#[no_mangle]
pub extern "C" fn magic_number() -> c_int {
    42
}

Et on ajoute bien évidemment du côté C :

extern int magic_number();

Panique

A l’extérieur de Rust, les paniques causent un comportement indéfini, il faut donc les éviter. S’il faut quand même paniquer, utiliser catch_unwind.

Pointeur nul

Beaucoup de types Rust ne peuvent pas être nuls, notamment les références et les pointeurs de fonction. Ce n’est en revanche pas le cas en C. Le langage Rust donne une approche simple pour s’interfacer avec le C dans cette situation : pour faire simple, utiliser une Option. La structure sera bien optimisée avec None correspondant à la valeur nulle et Some correspondant à la valeur non-nulle.

CRust
int (*)(int)Option<extern "C" fn(c_int) -> c_int>
data_t *Option<*mut data_t>
Exemples

Libération de la mémoire

On utilise le trait Drop pour appeler les fonctions étrangères qui conviennent à la libération de la mémoire.

Exemple :

impl Drop for Repository {
    fn drop(&mut self) {
        unsafe {
            raw::git_repository_free(self.raw);
        }
    }
}

Structure opaque

Si les entêtes en C décrivent un type opaque :

typedef struct Foo Foo;

Ou bien en argument de fonction :

void bar(void *foo);

Alors on utilise dans le code Rust :

#[repr(C)] pub struct Foo { _private: [u8; 0] }

extern "C" {
    pub fn bar(arg: *mut Foo);
}

On manipulera donc uniquement ces structures avec des pointeurs bruts.

Catégories
Non classé

Terminologie applicative d’un réseau ZigBee

Cet article a pour but de lister les différents concepts liés aux applications disponibles sur les différents nœuds d’un réseau ZigBee. Il n’a pas pour but d’expliquer quels sont les différents types de nœuds d’un réseau, comment celui-ci va se constituer, etc. Ces aspects seront traités dans d’autres articles. Nous allons uniquement nous concentrer sur les nœuds terminaux (pouvant effectuer des actions concrètes, directement utiles à l’utilisateur final).

Un réseau de nœuds interagissants

Dans un réseau ZigBee, des nœuds vont communiquer entre eux afin d’effectuer des actions ou de récupérer des informations. Ces interactions auront généralement des buts communs. La ZigBee Alliance les regroupe dans des Application Profiles. Le tout premier profil défini s’appelle « Home Automation ». Son but est de définir un ensemble de ressources communes pouvant être utile pour faire de la domotique dans un cadre domestique. Les fabricants voulant commercialiser des produits prévus dans ce but ont ainsi un standard auquel se raccrocher. Ces profils précisent, pour un type d’application donnée, ce qu’il peut être possible de faire faire à un nœud, et quelles seront les ressources nécessaires pour cela.

On entend par nœud (node) tout appareil connecté au réseau ZigBee. Un nœud ZigBee peut ainsi être un simple interrupteur qui supportera également un mode de mise à jour. Un nœud peut donc avoir différents rôles.

Les Application Profiles définissent ces ensembles de rôles, qu’on appellera device. Un nœud peut ainsi héberger plusieurs devices. On peut par exemple imaginer un nœud comportant deux devices : un capteur de lumière (Light Sensor) et un capteur d’occupation (Occupancy Sensor). Ces deux devices sont par exemple définis dans le profil Home Automation.

Lorsqu’un client (celui qui va faire la demande) fait effectuer à un device (qui a donc un rôle de serveur) une action, on dit que celui-ci effectue une commande. Si le device nous permet d’accéder ou de modifier une information qui lui est relative (exemple : l’intensité d’une ampoule), on parle d’attribut.

Les clusters définissent un ensemble de commandes (et de comportements associés), d’attributs et de dépendances. La ZigBee Cluster Library (ZCL) définit un grand nombre de clusters qui a vocation à suffire dans la plupart des cas. Chaque fabricant peut ensuite décider, comme pour les Application Profiles ou les devices, d’en redéfinir selon ses besoin.

Définir un device revient donc à lister les clusters que ce dernier implémentera de manière obligatoire ou non.

Par exemple, considérons le device « On/Off Light » du profil Home Automation (section 2.4.1 du document cité). Ce dernier doit supporter différents clusters. Il doit par exemple supporter le cluster « Basic ». Cela veut simplement dire qu’il doit pouvoir renseigner le réseau a propos de quelques uns de ses attributs (dont il doit donc disposer, obligatoirement ou non selon les attributs), tels que le nom de son fabricant, la version de l’application, etc. voire permettre d’en modifier, comme par exemple la description de son emplacement. Les attributs peuvent être des chaînes de caractères, des nombres, ou des énumérations, définies dans la ZCL. Ce cluster ne prend qu’une commande, qui est la réinitialisation du device. Ce device implémente aussi le cluster « On/Off« , qui donne accès entre autres à trois commandes, Off, On et Toggle, qui permettront respectivement d’éteindre, allumer, ou faire basculer l’état de la lampe.

Un endpoint est une instance d’un device sur un nœud donné, adressé avec une valeur comprise entre 1 et 240.

Si on reprend l’exemple de la lampe ci-dessus, et qu’un client veut l’allumer, il aura ainsi simplement à envoyer une requête au nœud correspondant à la lampe, avec le profil Home Automation, le numéro d’endpoint repéré lors de la découvert de service (imaginons que c’est 1 et que c’est le seul device présent sur le nœud), le numéro de cluster correspondant à « On/Off Light », 0x0006, et enfin la commande Off, d’identifiant 0x00, d’après la ZCL.

Nous verrons plus tard comment fonctionne la découverte des services et nous verrons aussi qu’il n’est pas nécessaire aux nœuds d’envoyer à chaque fois ces informations pour parvenir à leurs fins.

Catégories
Non classé

Des messages de commit suivant nos conventions

Ainsi que nous l’avions annoncé dans un précédent post, nous désirons que nos messages de commit suivent les standards de rédaction classiques. Afin de limiter les risques de contrevenir par mégarde à ces règles, plusieurs options s’offrent à nous.

L’option GitLab

Le dépôt distant central, hébergé à Télécom, est un GitLab Community Edition. Gitlab permet de configurer des Push Rules, qui ressemblent à des hooks Git configurables graphiquement et qui nous permettraient de rejeter, lors du push, tout commit ne respectant les règles que nous nous sommes fixées. Malheureusement, la version de Gitlab en place est la version gratuite, qui ne permet pas l’utilisation de cette fonctionnalité. Les hooks classiques peuvent toutefois être configurés, mais cela nécessite un accès administrateur à la machine sur laquelle repose Gitlab (ou du moins à son système de fichiers), ce dont nous ne disposons pas.

Hook local

Après un avoir traversé un court, mais intense, moment de frustration, nous avons décidé de nous rabattre sur une solution alternative : configurer le hook sur nos dépôt locaux. Cette solution permet de rejeter les commits si les messages ne correspondent pas aux règles (ou du moins à certaines) que nous avons fixées.

Cette solution présente quelques petits inconvénients :

  • Il faut compter sur chaque développeur pour configurer le hook en question. Comme nous ne sommes que deux, et si nous partons du principe que nous ne réinstallerons pas nos dépôts tous les 4 matins, cela ne devrait pas poser problème. De toute façon, il est plus agréable que le hook se déclenche au commit plutôt qu’uniquement au push : dans le cas contraire, le développeur est forcé de revenir sur son commit et de modifier son message avant d’espérer que son push soit accepté.
  • Certaines actions, en particulier les fusions, peuvent parfois se dérouler via l’interface graphique fournie par Gitlab, très confortable et pratique pour cela. Lors de la validation d’un commit de fusion via cette interface, les règles correspondant à nos hooks locaux ne seront pas vérifiées. Il faudra être particulièrement vigilant dans ces cas là.

Script retenu

Après quelques recherches, nous avons décidé de tester git-good-commit. Ce dernier a le bon goût de ne pas nécessiter l’installation d’outils supplémentaires. Le script s’assure que les règles basiques (longueur des différentes parties du message, ponctuation) sont respectées, et embarque une liste de mots à bannir : quelques verbes anglais courants au prétérit et à la troisième personne du singulier. Comme nous avons choisi de rédiger nos messages de commit en anglais, cette liste nous permettra d’éviter les erreurs les plus classiques.

Installation

Il suffit de télécharger le script et de le définir comme hook commit-msg (dernier hook déclenché lors de la constitution d’un commit, lorsque l’éditeur du message se ferme) :

curl https://cdn.rawgit.com/tommarshall/git-good-commit/v0.6.1/hook.sh > .git/hooks/commit-msg
chmod +x .git/hooks/commit-msg

À partir de là, après la rédaction d’un message de commit ne correspondant pas aux standards, et si le script peut le détecter, un prompt proposera d’éditer le message, de l’abandonner ou de le forcer tel quel.