Revision
ARCHITECTURE
APPLICATION
ADAPTATION
NOYAU STANDARD
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
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
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é
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é
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é
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
KERNELGWES
DEVICE DRIVERSOAL
DEVICEMANAGER
FILESYS
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– 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);ParametershOpenContext
[in] Handle returned by the XXX_Open function, used to identify the open context of the device.
Return ValuesTRUE indicates success. FALSE indicates failure.
• Fonction appelée par l’operating system en réponse à un appel par l’application de la fonction CloseHandle
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 );
ParametershOpenContext
[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 ValuesReturns zero to indicate end-of-file. Returns –1 to indicate an error. Returns the number of bytes read to indicate success.
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
#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
• 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);