Pour les cartes graphiques, il s'agit de porter XFree, donc les drivers sont ceux de XFree pour l'instant (4.1 actuellement, le 4.3 est en cours de portage).
Sauf dans l'optique d'un système de fenêtrage conçu proprement pour utiliser les spécificités d'un système multi-serveurs à micro-noyau de seconde génération comme GNU/Hurd sur L4.. :-) Ce qui offre des possibilités infinies, notamment permettrait une gestion clean et efficiente des drivers - il utiliserait pas son propre système de pilotes, mais bien le framework fourni par le système.
Pour le reste, on utilise actuellement OSKit, donc les drivers de Linux 2.2 ou FreeBSD jenesaispluscombien.
On n'utilise en fait que les pilotes de Linux 2.2.12, mais il serait hypothétiquement possible d'utiliser les pilotes de FreeBSD v2.1.7.1 (hé, ça explique peut-être qu'on les utilise pas, pour ceux qui suivent le développement de FreeBSD.. bien qu'il soit infiniment plus agréable d'utiliser, lire, développer des pilotes pour FreeBSD que pour Linux, à mon humble "avis").
A terme, on aura des drivers en user-space sur L4, et il faudra probablement réécrire pas mal de choses.
Voire, tout. Il faut bien comprendre que la portabilité inter-systèmes, dans l'esprit du GNU Manifesto (et plus spécifiquement dans mon esprit (: ) est une bonne chose, mais ne doit se faire en aucun cas au détriment du reste - c'est à dire, si faire le logiciel comme on pense que ça doit être fait implique utiliser des spécificités de GNU, il faut le faire (et si ça implique utiliser des spécificités d'autres systèmes, il faut les implémenter sous GNU :-). Or, utiliser des pilotes de périphériques conçus, par exemple, pour Linux, entraînera forcément une perte de performances, qui ne sera pas compensée, étant donné qu'ils ne tireront pas partie des avantages offerts par L4 et le Hurd. On pense notamment au fait que les pilotes de périphériques écrits pour Linux sont conçus pour avoir une mémoire « wired », inamovible (imaginez le bordel avec un kernel dont la mémoire est pageable (: ), alors que les pilotes en espace utilisateur peuvent - et devraient, à mon avis - être conçus pour tirer parti du fait que la mémoire puisse être « paged out » en cas d'utilisation intensive de la mémoire par d'autres applications. Voire, même, pour certains périphériques très particuliers, avoir un schéma de gestion de la mémoire plus complexe qui permettrait une certaine perte pendant les périodes de charge mémoire très forte, sans que pour autant le système sature d'autant plus.
Bien entendu, celà n'est qu'une question d'implémentation, et Linux nous apportera beaucoup dans la mesure où les pilotes pourront servir de spécifications, spécifications en plus déjà mises en applications, donc où l'on pourra voir les workarounds de Linux aux différents bugs des différents modèles de la carte trucmuche, etc. Que du bon en perspective ;-)
[^] # Re: Et les drivers ?
Posté par Manuel Menal . En réponse à la dépêche Démarrage du projet Gentoo GNU/Hurd le 13 Mars. Évalué à 7.
Sauf dans l'optique d'un système de fenêtrage conçu proprement pour utiliser les spécificités d'un système multi-serveurs à micro-noyau de seconde génération comme GNU/Hurd sur L4.. :-) Ce qui offre des possibilités infinies, notamment permettrait une gestion clean et efficiente des drivers - il utiliserait pas son propre système de pilotes, mais bien le framework fourni par le système.
Pour le reste, on utilise actuellement OSKit, donc les drivers de Linux 2.2 ou FreeBSD jenesaispluscombien.
On n'utilise en fait que les pilotes de Linux 2.2.12, mais il serait hypothétiquement possible d'utiliser les pilotes de FreeBSD v2.1.7.1 (hé, ça explique peut-être qu'on les utilise pas, pour ceux qui suivent le développement de FreeBSD.. bien qu'il soit infiniment plus agréable d'utiliser, lire, développer des pilotes pour FreeBSD que pour Linux, à mon humble "avis").
A terme, on aura des drivers en user-space sur L4, et il faudra probablement réécrire pas mal de choses.
Voire, tout. Il faut bien comprendre que la portabilité inter-systèmes, dans l'esprit du GNU Manifesto (et plus spécifiquement dans mon esprit (: ) est une bonne chose, mais ne doit se faire en aucun cas au détriment du reste - c'est à dire, si faire le logiciel comme on pense que ça doit être fait implique utiliser des spécificités de GNU, il faut le faire (et si ça implique utiliser des spécificités d'autres systèmes, il faut les implémenter sous GNU :-). Or, utiliser des pilotes de périphériques conçus, par exemple, pour Linux, entraînera forcément une perte de performances, qui ne sera pas compensée, étant donné qu'ils ne tireront pas partie des avantages offerts par L4 et le Hurd. On pense notamment au fait que les pilotes de périphériques écrits pour Linux sont conçus pour avoir une mémoire « wired », inamovible (imaginez le bordel avec un kernel dont la mémoire est pageable (: ), alors que les pilotes en espace utilisateur peuvent - et devraient, à mon avis - être conçus pour tirer parti du fait que la mémoire puisse être « paged out » en cas d'utilisation intensive de la mémoire par d'autres applications. Voire, même, pour certains périphériques très particuliers, avoir un schéma de gestion de la mémoire plus complexe qui permettrait une certaine perte pendant les périodes de charge mémoire très forte, sans que pour autant le système sature d'autant plus.
Bien entendu, celà n'est qu'une question d'implémentation, et Linux nous apportera beaucoup dans la mesure où les pilotes pourront servir de spécifications, spécifications en plus déjà mises en applications, donc où l'on pourra voir les workarounds de Linux aux différents bugs des différents modèles de la carte trucmuche, etc. Que du bon en perspective ;-)