IOCTL_GNSS_START_FIXSESSION IOCTL (ombadriver.h)

Article
02/07/2025

Le code de contrôle IOCTL_GNSS_START_FIXSESSION est utilisé par l’adaptateur GRID pour démarrer une session de réparation.

Code principal

IRP_MJ_DEVICE_CONTROL

Mémoire tampon d’entrée

Pointeur vers une structure GNSS_FIXSESSION_PARAM.

Longueur de la mémoire tampon d’entrée

Défini sur sizeof(GNSS_FIXSESSION_PARAM).

Mémoire tampon de sortie

Défini sur NULL.

Longueur de la mémoire tampon de sortie

Défini sur 0.

Bloc d’état

> IoStatus.Status est défini sur STATUS_SUCCESS si la requête réussit. Sinon, état à la condition d’erreur appropriée en tant que code NTSTATUS.

Remarques

Le pilote définit une valeur NTSTATUS pour indiquer l’un des résultats suivants.

La session de correction a démarré avec succès.
Une session de correction du même type est déjà active et le pilote ne prend pas en charge plusieurs sessions.

notes de l’adaptateur DIMENSIONNELLE

Si la prise en charge de plusieurs sessions n’est pas présente, l’adaptateur PSEC garantit que plusieurs sessions du même type de correctif sont correctement multiplexées afin que le pilote PSEC ne voit qu’une seule session d’un type donné de correctif. L’adaptateur SSH peut modifier les paramètres de session de correction d’une session de correction active via l’appel IOCTL_GNSS_MODIFY_FIXSESSION.

L’adaptateur SEE ne démarre pas une demande de correctif get, sauf si le pilote termine cet appel et retourne un état de réussite dans la sortie.

notes de pilote PSEC

Si la prise en charge de plusieurs sessions n’est pas présente et que l’adaptateur PSEC envoie une autre demande de correctif de démarrage pour un type de correctif déjà actif, le pilote PSEC doit échouer à la nouvelle demande de session. Le pilote ne doit pas remplacer la session précédente par les détails de la nouvelle session de correctif.

Plusieurs sessions de correctif de différents types de correctifs sont toujours prises en charge par le pilote JDBC.

Une fois que le pilote PSEC accepte les paramètres de session de correction, les valide et lance le moteur UO, il termine immédiatement l’E/S avec un code de retour réussi. Sauf si la session de résolution de démarrage retourne avec un code de réussite, l’adaptateur SSH n’émet pas de demande de correction d’obtention. Tous les correctifs reçus pour cette session de correctif spécifique doivent être remis à l’adaptateur SSH par rapport à un appel de correctif get en attente suivant à partir de l’adaptateur RDI qui a le même ID de session. Si un correctif devient disponible et qu’aucun appel de correctif get en attente n’est créé par l’adaptateur, le pilote UO est requis pour mettre en file d’attente la correction jusqu’à ce qu’une E/S en attente soit créée qui représente l’ID de session.

Une fois qu’une session de correctif est démarrée, elle reste active, sauf si la session de réparation est explicitement arrêtée par l’adaptateur SSE. Cela s’applique à tous les types de correctifs.