Revision

ARCHITECTURE APPLICATION NOYAU STANDARD ADAPTATION HARDWARE

BOARD SUPPORT PACKAGE (BSP) La couche d’adaptation est à la charge du concepteur du hardware Elle comprend des fonctions d’adaptation au hardware OAL (OEM Adaptation Layer, OEM:Original Equipment Manufacturer) un certain nombre de drivers (pilotes de périphériques) Le Boot Loader L’ensemble de cette couche est appelé BSP Des BSP existent pour des cartes industrielles de référence OEM : Original Equipment Manufacturer Ce terme correspondait, au début, à un équimentier qui développait un produit nouveau mais qui ne le commercialisait pas lui-même ; le produit était inséré pour être revendu dans un ensemble commercialisé par d’autres ; ce fût le cas pour de nombreux accessoires, lecteur de disquette, lecteur de CD, moteur d’imprimante laser, etc. Aujourd’hui, il arrive que l’OEM commercialise lui-même son produit, avec bien souvent des conditions commerciales alléchantes mais qui ne sont pas toujours un bon choix. Par exemple, un disque Wincheter acheté en OEM risque fort d’être livré dans un simple plastique, sans emballage de protection, sans documentation, sans les cavaliers nécessaires pour fixer les options, et souvent avec des difficultés pour faire jouer la garantie, etc. Le boot loader est un logiciel indispensable qui permet d’initialiser un équipement en lui transférant par diverses voies (liaison série ou liaison éthernet le plus souvent) un premier code exécutable, dont le rôle est d’initialiser des registres internes puis de télécharger et initialiser un ensemble de programmes plus conséquents qui vont permettre d’initialiser et réellement travailler avec le BSP.

PROCESS Un process ou processus est une instance d’application en cours ou en attente d’exécution Allocation de ressources au niveau du process 32 MB d’adressage virtuel par process Un process démarre avec un seul thread (Primary Thread) mais il peut créer d’autres threads Plusieurs threads peuvent s’exécuter simultanément Un process peut aussi créer d’autres process Windows CE peut gérer jusqu’à 32 process simultanément Process : le mot français processus est une bonne traduction de process, mais process se trouve très généralement employé ; nous prendrons l’une ou l’autre forme. Par contre, au pluriel, nous utiliserons processus ou encore process, car la forme plurielle anglaise processes est difficile à conserver ; ce faisant, nous appliquons une règle identique à celle utilisée pour le mot francisé « mess ». Thread : le programme qui compose le process est organisé sous forme de séquences indépendantes qui peuvent s’exécuter simultanément dans un ou plusieurs processeurs (accélération du traitement, répartition de charge entre CPU). Les threads utilisent, et donc partagent, les ressources allouées au process : espace mémoire, fichiers, sémaphores, etc. et certaines ressources privées (registres). Problème de la synchronisation entre threads… Ce mécanisme est particulièrement intéressant lorsque le processeur peut exécuter simultanément plusieurs threads ; c’est le cas notamment de certains Pentium récents. Adressage virtuel : il s’agit d’une notion fondamentale sur laquelle nous reviendrons ultérieurement.

THREAD La plus petite unité d’exécution Plusieurs threads peuvent s’exécuter simultanément Les threads ont accès à l’ensemble des ressources du process Ordonnancé (schédulé) par le noyau Quantum de temps configurable (100ms) Préemptif 256 niveaux de priorités Priorité tournante pour des threads de même priorité Scheduler (ordonnanceur) : il s’agit du logiciel du système qui gère l’exécution des threads éligibles à un instant donné. Lorsqu’un thread est créé on lui attribue ou il hérite d’un niveau de priorité, qu’il conservera excepté dans quelques circonstances particulières. Lorsque tous les threads des niveaux plus prioritaires ont rendu la main, le scheduler rend actif le thread s’il est seul sur ce niveau, ou bien choisit par un algorithme le thread à réveiller ; dans Windows CE la priorité sur un même niveau est gérée par priorité tournante Priorité tournante (Round Robin) : quand plusieurs threads ont la même priorité, le système alloue les quanta de temps de façon circulaire pour éviter qu’un même thread soit réélu sans que d’autres threads de même niveau de priorité aient pu bénéficier de quanta de temps. Ce schéma s’oppose à la priorité fixe ; il a l’avantage d’éviter la monopolisation de la ressource temps par un thread, par contre cela réagit sur le fonctionnement déterministe du système. Préemptif : ceci correspond à une caractéristique très importante d’un système. En simplifiant, cela indique qu’à tout instant où le système reprend la main, son scheduler peut prévoir le bon enchaînement des exécutions des threads dans le respect des contraintes de temps définies par les priorités. Cela exclut qu’une tâche monopolise tous les quanta disponibles pendant une durée indéfinie ; le système aura forcément repris la main au moment de l’allocation d’un quantum et pourra agir en ayant une vision complète des threads en attente.

Section critique : types Les types « section critique » et « pointeur sur section critique » sont définis par des typedef CRITICAL_SECTION cs; LPCRITICAL_SECTION lpcs; Cela permet des contrôles par le compilateur et contribue à éviter un usage inapproprié Dans winbase.h on trouve les typedef RTL_CRITICAL_SECTION et *PRTL_CRITICAL_SECTION. CRITICAL_SECTION et LPCRITICAL_SECTION sont des alias. typedef struct _RTL_CRITICAL_SECTION { PRTL_CRITICAL_SECTION_DEBUG DebugInfo; // The following three fields control entering and exiting the critical // section for the resource LONG LockCount; LONG RecursionCount; HANDLE OwningThread; // from the thread's ClientId->UniqueThread HANDLE LockSemaphore; DWORD Reserved; } RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION; typedef RTL_CRITICAL_SECTION CRITICAL_SECTION; typedef PRTL_CRITICAL_SECTION LPCRITICAL_SECTION;

Mutex Mutex : raccourci pour mutual exclusion Objet système destiné à gérer les synchronisations par exclusion mutuelle Synchronisation Intra-processus Inter-processus Alloué au plus à un thread à un instant donné Il s’agit d’une autre solution du problème de synchronisation, cette fois en utilisant un objet créé et géré par le système. En effet, aucune allocation d’objet n’est faite dans l’unité de compilation. L’objet mutex est créé par la fonction CreateMutex, non pas dans le processus mais dans son contexte d’exécution et le système rend cet objet visible par d’autres processus. L’objet mutex sera géré à travers un handle et le programme d’application n’a pas d’autre moyen d’y accéder que d’utiliser les fonctions proposées par Windows CE. La différence pratique est que plusieurs processus peuvent exploiter le même mutex à la simple condition de savoir comment il est nommé. Il est ainsi possible de réaliser des synchronisations dans un processus ou entre deux processus par ailleurs indépendants (l’un n’est pas un fils de l’autre).

Synchronisation par événement Autre forme de synchronisation plus souple que par les mutex Gestion plus riche des événements Création Prise de possession Restitution Transmission de données Ouvertures multiples

Sémaphore (1) Contrôle le nombre des accès à une ressource par la distribution de jetons Valeur maximale fixée à la création Chaque utilisateur prend et restitue un ou plusieurs jetons sur le sémaphore Fonctionne entre processus indépendants Exclusion mutuelle dans le seul cas d’un jeton à valeur maximum de 1

Sémaphore (2) Le nombre de jetons disponibles est égal à tout instant au nombre des utilisateurs de la ressource gérée par le sémaphore Chaque fois qu’un un jeton est pris, le compteur de jeton est décrémenté Chaque fois qu’un jeton est restitué, le compteur de jeton est incrémenté Lorsque le nombre de jetons disponibles est 0, la ressource n’est plus disponible

Système de base NOYAU (1) Principaux blocs constitutifs KERNEL GWES DEVICE MANAGER FILESYS DEVICE DRIVERS OAL

NOYAU (2) KERNEL OS minimal ; il gère les process, les threads, la mémoire, les interruptions, etc. GWES (Graphics Windowig Events Subsystem) Gère l’interface graphique et les entrées-sorties (I/O) des utilisateurs DEVICE DRIVERS Native Drivers : interface utilisateur de base sauf clavier, écran et souris qui sont gérés par GWES et chargés lors du boot Stream Drivers : gérés par le Device Manager

NOYAU (3) DEVICE MANAGER FILESYS Gère les Stream Drivers : charge lors du boot ceux qui sont listés dans la Registry Gère de manière dynamique les drivers chargeables à la demande FILESYS Gère le système de fichiers, la registry et la Property Data Base (base de donnée non hiérarchisée pour stocker des adresses, des mails et des informations)

Fonctions d’un driver XXX_Init XXX_Deinit XXX_Open XXX_Close XXX_Read XXX_Write XXX_IoControl XXX_Seek XXX_PowerUp XXX_PowerDown

Fonction XXX_Init Fonction appelée pour démarrer le driver par le Device Manager via l’appel de ActivateDeviceEx ou de RegisterDevice Initialise les ressources nécessaires au fonctionnement du driver (mémoire, registres des périphériques…) XXX_Init crée un handle hDeviceContext passé par RegisterDevice à XXX_Open, XXX_Deinit, XXX_PowerUp et XXX_PowerDown

Fonction XXX_Deinit BOOL XXX_Deinit(DWORD hDeviceContext); Fonction appelée quand le Device Manager arrête le driver via l’appel des fonctions DeactiveDeviceEx ou DeregisterDevice par l’application L’application devra compléter par un appel à CloseHandle pour détruire le handle associé et libèrer toutes les ressources matérielles et/ou logicielles utilisées par le driver

Fonction XXX_Open Ouvre un driver en lecture et/ou écriture Fonction appelée par l’application à travers la fonction CreateFile Alloue les ressources propres à chaque contexte ouvert Crée un handle hOpenContext utilisé par XXX_Close, XXX_Read, XXX_Write, XXX_Seek XXX_IOControl Peut-être appelée plusieurs fois

XXX_Close BOOL XXX_Close( DWORD hOpenContext); Parameters hOpenContext [in] Handle returned by the XXX_Open function, used to identify the open context of the device. Return Values TRUE indicates success. FALSE indicates failure. Fonction appelée par l’operating system en réponse à un appel par l’application de la fonction CloseHandle Microsoft Windows CE .NET 4.2  XXX_Close This function closes a device context created by the hOpenContext parameter. BOOL XXX_Close( DWORD hOpenContext ); Parameters hOpenContext [in] Handle returned by the XXX_Open function, used to identify the open context of the device. Return Values TRUE indicates success. FALSE indicates failure. Remarks An application calls the CloseHandle function to stop using a stream interface driver. The hFile parameter specifies the handle associated with the device context. In response to CloseHandle, the operating system invokes XXX_Close. The file handle specified for hOpenContext is no longer valid after this function returns; if an application tries to perform stream I/O operations on that handle after calling CloseHandle, those operations fail. The Device Manager uses the XXX prefix. When implementing the stream interface, replace XXX with a prefix appropriate for your specific implementation or use undecorated entry point names in conjunction with DEVFLAGS_NAKEDENTRIES. For more information, see Stream Interface Driver Implementation. Requirements OS Versions: Windows CE 1.0 and later. Header: Developer implemented. Link Library: Developer implemented. See Also Stream Interface Drivers | Device File Names | Stream Interface Driver Implementation | CloseHandle | XXX_Open  Last updated on Tuesday, February 03, 2004 © 1992-2003 Microsoft Corporation. All rights reserved.

XXX_Read DWORD XXX_Read( DWORD hOpenContext, LPVOID pBuffer, DWORD Count); Fonction appelée par l’operating system en réponse à la fonction ReadFile de l’application Utilise un contexte ouvert par XXX_Open Les caractères lus sont placés dans le buffer pointé par pBuffer Count indique le nombre de caractères à lire La fonction retourne le nombre de caractères lus

Fonction XXX_Read DWORD XXX_Read( DWORD hOpenContext, LPVOID pBuffer, DWORD Count ); Parameters hOpenContext [in] Handle to the open context of the device. The XXX_Open function creates and returns this identifier. pBuffer [out] Pointer to the buffer that stores the data read from the device. This buffer should be at least Count bytes long. Count [in] Number of bytes to read from the device into pBuffer. Return Values Returns zero to indicate end-of-file. Returns –1 to indicate an error. Returns the number of bytes read to indicate success. Microsoft Windows CE .NET 4.2  XXX_Read This function reads data from the device identified by the open context. DWORD XXX_Read( DWORD hOpenContext, LPVOID pBuffer, DWORD Count ); Parameters hOpenContext [in] Handle to the open context of the device. The XXX_Open function creates and returns this identifier. pBuffer [out] Pointer to the buffer that stores the data read from the device. This buffer should be at least Count bytes long. Count [in] Number of bytes to read from the device into pBuffer. Return Values Returns zero to indicate end-of-file. Returns –1 to indicate an error. Returns the number of bytes read to indicate success. Remarks An application calls the ReadFile function to read from the device. The operating system, in turn, invokes this function. The hFile parameter is a handle to your device. The pBuffer parameter points to the buffer that contains the data read from the device. The Count parameter indicates the number of bytes that the application wants to read from the device. The Device Manager uses the XXX prefix. When implementing the stream interface, replace XXX with a prefix appropriate for your specific implementation or use undecorated entry point names in conjunction with DEVFLAGS_NAKEDENTRIES. For more information, see Stream Interface Driver Implementation. Requirements OS Versions: Windows CE 1.0 and later. Header: Developer implemented. Link Library: Developer implemented. See Also Stream Interface Drivers | Device File Names | Stream Interface Driver Implementation | ReadFile | XXX_Open  Last updated on Tuesday, February 03, 2004 © 1992-2003 Microsoft Corporation. All rights reserved.

XXX_Write DWORD XXX_Write( DWORD hOpenContext, LPVOID pBuffer, DWORD Count); Appelée par l’operating system en réponse à la fonction WriteFile de l’application Les caractères à écrire sont placés dans le buffer et Count indique le nombre de caractères à écrire L’OS écrira dans le device connu par un handle de « contexte ouvert » créé par XXX_Open Fournit le nombre de caractères écrits ou erreur

XXX_Seek DWORD XXX_Seek( DWORD hOpenContext, long Amount, WORD Type); Appelée par l’operating system en réponse à la fonction SetFilePointer de l’application Amount indique le nombre de bytes dont doit être modifié le pointeur de données du device Type spécifie le point de départ du pointeur de données

Fonction SetFilePointer Permet de déplacer un pointeur dans un fichier ouvert Suppose un objet qui supporte un positionnement, pas un port qui travaille toujours au même endroit Peut renseigner sur la position dans le fichier Retourne la nouvelle valeur du pointeur ou une erreur

IOCTL Permet de définir des fonctions spécifiques à un device donné #define IOCTL_essai1 CTL_CODE(\ FILE_DEVICE_UNKNOWN,2048,\ METHOD_BUFFERED,FILE_ANY_ACCESS) Permet de définir des fonctions spécifiques à un device donné IOControl est un code 32 bits défini avec la macro CTL_CODE

XXX_IOControl dwCode identifie une opération BOOL XXX_IOControl( DWORD hOpenContext, DWORD dwCode, PBYTE pBufIn, DWORD dwLenIn, PBYTE pBufOut, DWORD dwLenOut, PDWORD pdwActualOut); dwCode identifie une opération On dispose d’un buffer d’entrée On dispose d’un buffer de sortie pdwActualOut permet de retourner le nombre de caractères effectivement lus sur le device. Appelé par l’application avec DeviceIoControl

XXX_ PowerDown XXX_PowerUp Appelés par l’operating system pour gérer l’énergie sur des périphériques disposant des fonctionnalités de mise en veilleuse ou d’extinction Void XXX_PowerUp(DWORD hDeviceContext); Void XXX_PowerDown(DWORD hDeviceContext); Microsoft Windows CE .NET 4.2  XXX_PowerUp This function restores power to a device. void XXX_PowerUp( DWORD hDeviceContext ); Parameters hDeviceContext [in] Handle to the device context. The call to the XXX_Init function returns this identifier. Return Values None. Remarks The power path of the kernel calls this function. The driver may also receive a separate power-down request from the Power Manager, in the form of IOCTL_POWER_SET to D3 or D4, before the XXX_PowerUp invocation. The operating system invokes this function to restore power to a device. The operating system might call this function as it is leaving a power-save mode. This function should only perform the required hardware-level recovery. It should signal a driver thread to complete the process if full recovery is time consuming or requires OS services that are not available in power callbacks. XXX_PowerUp and XXX_PowerDown callbacks can use CeSetPowerOnEvent to signal to arbitrary driver threads that a suspend/resume cycle has occurred. To signal the driver's interrupt service thread, use SetInterruptEvent instead. The Device Manager uses the XXX prefix. When implementing the stream interface, replace XXX with a prefix appropriate for your specific implementation or use undecorated entry point names in conjunction with DEVFLAGS_NAKEDENTRIES. For more information, see Stream Interface Driver Implementation. Requirements OS Versions: Windows CE 1.0 and later. Header: Developer implemented. Link Library: Developer implemented. See Also Stream Interface Drivers | Device File Names | Stream Interface Driver Implementation | CeSetPowerOnEvent | SetInterruptEvent | XXX_Init | XXX_PowerDown | Power Management  Last updated on Tuesday, February 03, 2004 © 1992-2003 Microsoft Corporation. All rights reserved. XXX_PowerDown This function suspends power to the device. It is useful only with devices that can power down under software control. Such devices are typically, but not exclusively, PC Cards. void XXX_PowerDown( DWORD hDeviceContext ); The power path of the kernel calls this function. The driver may also receive a separate power-down request from the Power Manager, in the form of IOCTL_POWER_SET to D3 or D4, before the XXX_PowerDown invocation. The operating system invokes this function to suspend power to the device. The operating system might call this function when it is about to enter a power-save mode. This function should not call any functions that might cause it to block, and it should return as quickly as possible. One strategy for returning quickly is to have this function set a global variable to indicate that a power loss occurred. Assuming no power management is involved, this function should only power down the device. Stream Interface Drivers | Device File Names | Stream Interface Driver Implementation | CeSetPowerOnEvent | SetInterruptEvent | XXX_Init | XXX_PowerUp | Power Management