Discussion :

[smyley]

Simple curiosité, peut on créer un driver grâce à un code managé ?
Je crois que directement l'écrire par exemple en C# ne sera pas possible, car j'ai jamais vu quelqu'un charger le CLR en mode noyau (), mais par exemple créer un driver qui utilise un service en mode utilisateur pour faire les véritables, qui lui est fait en .NET. On aurai par exemple une architecture où le C++ est là qu'en tant que wrapper pour le service managé.

Réalisable ou pur utopie ?

Merci d'avance (en espérant qu'une bonne âme me répondra )

[tomlev]

Tiens, c'est marrant, je me posais justement la question tout à l'heure en répondant à un autre post...
Enfin, à mon avis c'est pas gagné !
Il faudrait poser la question sur les forums MSDN

[smyley]

Rolala, aller jusque là, en anglais en plus
I'll see.

[tomlev]

qui sait, peut-être qu'un jour viendra où le noyau de windows fonctionnera sous .NET
bon ok, c'est pas très réaliste...

[smyley]

Ben en fait si c'est réaliste, regarde du coté de Singularity

[Thomas Lebrun]

Simple curiosité, peut on créer un driver grâce à un code managé ?
Je crois que directement l'écrire par exemple en C# ne sera pas possible, car j'ai jamais vu quelqu'un charger le CLR en mode noyau (), mais par exemple créer un driver qui utilise un service en mode utilisateur pour faire les véritables, qui lui est fait en .NET. On aurai par exemple une architecture où le C++ est là qu'en tant que wrapper pour le service managé.

Réalisable ou pur utopie ?

Merci d'avance (en espérant qu'une bonne âme me répondra )

Disons que si l'on suit ton raisonnement, tu souhaites:
- créer un driver C++
- faire un wrapper en .NET (C#/C++)
- Utiliser ce driver via le wrapper

Dans ce cas là, oui, c'est possible (COM Interop) mais au final, tu ne fais pas ton driver en managé

[smyley]

Disons que si l'on suit ton raisonnement, tu souhaites:
- créer un driver C++
- faire un wrapper en .NET (C#/C++)
- Utiliser ce driver via le wrapper

No, you didn't got it.

Ce que je voudrais savoir c'est si on peut
- créer un squelette de driver en C++
- faire le véritable code dans un service Windows managé
- Utiliser se driver comme un vrai driver

En fait en reprenant le principe du C#, le driver serai une interface et le service l'implémentation de l'interface du driver.
Un appel au driver C++ appellerai en faite la fonction dans le service managé avant de revenir à l'appelant natif.

[cinemania]

bien qu'il existe certains drivers qui fonctionne avant tout comme des services windows...

je me demande si cela est réalisable. Disons que ca l'est, ca c'est évident, mais de là a dire que ce soit "fonctionnel" ca l'est moins.

En plus créer un wrapper en C++ qui serve de squelette nécessite que tu choisisse un modele de communication entre le driver réel (C++) et le code managé qui est dans un Service windows, un processus totalement à part donc.
Qui dit choisir un modele de comm, signifie que tu aura pas mal de prog entre l'appelant/wrapper, et le service windows managé qui implante ton "interface"

Sinon il te reste la solution d'hoster la CLR directement dans ton driver C++, je me demande si cette solution ne serait pas plus simple.
Hoster la CLR ne signifie pas que ton code managé ne peut pas se trouver dans une assembly séparée donc tu pourrais écrire l'assembly séparée en C#... Mais encore... faut t'il arriver à le faire.

[smyley]

Sinon il te reste la solution d'hoster la CLR directement dans ton driver C++, je me demande si cette solution ne serait pas plus simple.
Hoster la CLR ne signifie pas que ton code managé ne peut pas se trouver dans une assembly séparée donc tu pourrais écrire l'assembly séparée en C#... Mais encore... faut t'il arriver à le faire.

Je pense que cette dernière partie est irréalisable. On parle bien de charger le CLR dans un processus s'exécutant en mode kernel. Tu penses qu'il est fait pour ça le CLR ?

[cinemania]

Le fait qu'il n'ai pas été concut pour... ne signifie pas que ce n'est pas possible, tout est affaire de droits et sécurité.

Maintenant je reconnais que c'est un peu tiré par les cheveux mais bon... créer un driver sans développement natif n'est pas viable sans cette solution.

Utiliser les RPC en natif, c'est assez hardcore s'il fait un service managé qui sert de coeur.

[smyley]

Le fait qu'il n'ai pas été concut pour... ne signifie pas que ce n'est pas possible, tout est affaire de droits et sécurité.

Mais la gestion de la mémoire n'est pas différente pour le noyau ?

Utiliser les RPC en natif, c'est assez hardcore s'il fait un service managé qui sert de coeur.

En même temps j'ai l'impression que les drivers d'ATI (en référence à MOM.exe et CCC.exe) sont managés. Je me fait des idées ou c'est vrai ?

[tomlev]

non, MOM et CCC sont liés au Catalyst Control Center, qui n'est pas un driver en soit, mais seulement une IHM pour bidouiller les options graphiques...
Après, ils sont pt-être managés, j'en sais rien...

[cinemania]

un driver, est un programme, exécuté en mode "kernel" mais programme quand, ou plutot bibliotheque de code, cependant, cette bibliotheque de code, peut très bien allouer de la mémoire, désallouer de la mémoire ...

certains pilotes font cela pour allouer un cache qu'ils vont laisser dans le swap et fixé en ram quand ils en ont besoin et remettre en swap.

là ou il y a des différences, c'est au niveau des droits et sécurités... en fait il faut savoir qu'un pilote est exécuté avec les droits du noyau, que ce soit au niveau du système mais également au niveau de la plateforme
(x86/N64 depuis le i386 ou les itanium, ils gères tous des droits & sécurités de session de façon HARDWARE, pour déterminer les zones d'adressages autorisées ou interdites)
Ainsi, pour un driver lorsque son code sera exécuté, il le sera en mode "kernel" (niveau de sécurité processeur 0 à 3) et pour une application, il le sera en mode "application" (niveau de sécurité processeur de 4 à 7)

maintenant il est difficile de savoir si windows tire profit de la sécurité intégrée des processeurs et des 8 niveaux de sécurités. Si mes souvenirs sont bon linux aux dernières nouvelles n'en utilisait que 2. (0 et 7)
mais globallement le fonctionnement reste le même.

il faut donc faire très attention à ce que l'on code dans un driver. microsoft ne précise pas si le code des pilotes est exécuté au meme rang que le noyau profond, ni meme si le noyau gere plusieurs de ces niveaux. Quoi qu'il en soit au niveau 0, on peut accèder à toute l'étendue de la mémoire, et des ressources et y mettre ce qu'on veut, y compris perturber les zones qui sont utilisées par le processeur, lui meme pour fonctionner (table des interruptions et autres...), donc il est quand meme fortement déconseillé d'hoster la CLR meme si c'est en théorie possible.

[smyley]

Quoi qu'il en soit au niveau 0, on peut accèder à toute l'étendue de la mémoire, et des ressources et y mettre ce qu'on veut, y compris perturber les zones qui sont utilisées par le processeur, lui meme pour fonctionner (table des interruptions et autres...)

c'est grave ? enfin, je veux dire, en faisant celà on peut faire en sorte qu'un processeur aille à la casse où c'est juste histoire qu'on redémarre et c'est réglé ?

, donc il est quand meme fortement déconseillé d'hoster la CLR meme si c'est en théorie possible.

Justement je parle pas de l'hoster directement dans le Driver mais d'utiliser un Service qui est donc dans l'espace Utilisateur afin d'effectuer le travail que l'on demande au driver dans l'espace Kernel. Par exemple, un driver de souris (je sais pas quoi) qui se serve d'un service pour faire tous les petits calculs de position et tout et qui ensuite récupère les résultats du service pour refaire passer les commandes au noyau... ?

[dev01]

c'est grave ? enfin, je veux dire, en faisant celà on peut faire en sorte qu'un processeur aille à la casse où c'est juste histoire qu'on redémarre et c'est réglé ?

nop c'est pas grave, les registres mémoire ne résistent pas à un reboot


Pour ce qui est des histoires d'emplacement de sécurité, un driver peut théoriquement être exécuté en Ring 0 ( c'est à dire au coeur même de l'OS ) c'est d'ailleur le cas de certain "driver" de protection .

Quand a écrire un driver en code managé, à mon avis c'est pas gagné. Je suis pas un expert en driver Windows mais :
- un driver qui chargé au boot ne le serait-il pas avant même que l'OS puisse charger le Fx ?
- Vu la couche importante de sécurité du Fx, le driver ne serait-il pas tué à son chargement par le runtime car il tenterait de s'éxecuter en mode noyau ?

[tomlev]

nop c'est pas grave, les registres mémoire ne résistent pas à un reboot


Pour ce qui est des histoires d'emplacement de sécurité, un driver peut théoriquement être exécuté en Ring 0 ( c'est à dire au coeur même de l'OS ) c'est d'ailleur le cas de certain "driver" de protection .

Quand a écrire un driver en code managé, à mon avis c'est pas gagné. Je suis pas un expert en driver Windows mais :
- un driver qui chargé au boot ne le serait-il pas avant même que l'OS puisse charger le Fx ?
- Vu la couche importante de sécurité du Fx, le driver ne serait-il pas tué à son chargement par le runtime car il tenterait de s'éxecuter en mode noyau ?

Et donc, on attend Singularity... mais bon, c'est un projet de recherche, pas sûr que ça donne un jour un produit commercial

[smyley]

Et donc, on attend Singularity... mais bon, c'est un projet de recherche, pas sûr que ça donne un jour un produit commercial

En même temps celà m'ettonerai que Microsoft après avec crée le .NET Framework ne finissent pas par en faire un standard pour ses propres développements... je sais pas, mais se faire c*ier à créer le CLR, WCF, WPF, WF, etc etc et ne jamais se dire que Singularity pourrai révolutionner ses OS ...

En même temps je ne vous dit pas que je cherche à charger le CLR dans un driver. Voilà le truc par exemple : un driver pour un système de fichier en résau ou bidule truc (je sais pas).

1- Windows charge le driver pendant le boot, mais il ne fait rien vu que windows n'a pas encore fini de démarrer.
2- Windows charge les services dont un service MySystemDeFichiers.
3- Windows a fini de démarrer, le service est actif.
4- Le driver remarque que le service est actif, il monte le lecteur et redirige les appels de Windows vers le service MySystemDeFichiers.
5- On a tranquillement un nouveau lecteur X: sur lequel le service MySystemDeFichiers renvois les résultats via le résau.

Dans tout ça, driver = C++ natif et MySystemDeFichiers = C#. C'est de ça que je parle ...

[tomlev]

ta méthode me semble réalisable... mais loin d'être facile