La norme ACPI

Projet de veille technologique : la norme ACPI

Synthèse des articles

Dans cette série d'articles, nous nous sommes attachés à décrire précisément la norme, son cadre d'application, son fonctionnement, ses limitations et son avenir.

La norme ACPI est une norme ayant pour but de gérer simplement la mise hors tension de différents éléments matériels d'un ordinateur.

Cette norme a évolué au fil des années et de son implémentation sur les ordinateurs personnels.[1]

[1] : La norme ACPI

Succédant à l'APM, la norme ACPI n'a été standardisée que très tard et a donc été mal implémentée. Nous nous sommes plus particulièrement intéressé à son implémentation dans le noyau Linux.

D'un point de vue technique, nous nous sommes penchés sur le désassemblage d'une table DSDT(Cette table contient des informations et une configuration sur le système de base), nécessaire lorsque l'on souhaite comprendre de près le fonctionnement de l'ACPI, en particulier sa gestion sous GNU/Linux.[2]

[2] : Désassembler une table ACPI

D'un point de vue système, nous nous sommes intéressés à l'approche faîte par le noyau Linux, notamment via l'architecture de fichier mise en place. En particulier via l'architecture de /proc/acpi, nous avons vu de quelle manière il était possible d'exploiter ces informations à l'aide de scripts ou de programmes plus avancés.[3]

La modification à chaud d'une table DSDT [4] ainsi que l'envoi des signaux ACPI [5] ont été abordés.

[3] : Gestion de l'ACPI sous GNU/Linux

[4] : Modifier une table DSDT à chaud sur un système GNU/Linux

[5] : Envoyer des signaux ACPI

Dans une dernière partie, ce sont les nouveautés de la norme ACPI 4 et ses évolutions futures [6] qui nous ont attiré. Malgré la récente publication d'une nouvelle version de la norme ACPI, il existe maintenant des alternatives, comme l'UEFI

[6] : Nouveautés de la norme ACPI 4 et évolutions futures

Articles de blog relatifs à la norme ACPI

Articles de blogs traitant de l'ACPI

Glossaire

  • ACPI : Advanced Control Power Interface
  • APM : Adanced Power Management
  • DSDT : Differentiated System Description Table
  • UEFI : Unified Extensible Firmware Interface

0 comments

Nouveautés de la norme ACPI 4 et évolutions futures

Nouveautés de la norme ACPI 4 et évolutions futures

Les évolutions matérielles se sont succédées à une cadence effrénée, et l'ACPI a suivi ces évolutions, et les a parfois précédées (ou en tout cas leur déploiement effectif). La dernière version de la norme ACPI ne se contente pas d'intégrer des correctifs, et ajoute le support d'un certain nombre des ces innovations.

Évolutions apportées par la version 4 de la norme ACPI

L'ACPI v4 apporte notamment le support des technologies suivantes :

  • Support de x2APIC
  • Mise en attente des processeurs logiques
  • Support USB3

Support de x2APIC

L'IO/APICest une architecture développée par Intel pour assurer la gestion des interruptions dans les ordinateurs multi-processeurs (ce qui est impossible avec l'architecture PIC). IO/APIC est localisé à la fois dans le processeur (Local APIC), et dans les parties du système qui gèrent les Entrées/Sorties. Cette architecture est présente danse les composants depuis plus de 10 ans.

L'architecture x2APIC est une architecture de transition. En effet, elle assure à la fois la rétro-compatibilité avec l'APIC et sert de base pour les développements à venir sur plateforme intel.
Les modifications intégrées à la norme ACPI v4 concernant x2APIC se trouvent assez logiquement dans la table MADT. Le champ APIC Structure peut donc faire référence à des structures de type Processor Local x2APIC et Local x2APIC Non Maskable Interrupt Structure

Mise en attente des processeurs logiques

Il est possible d'avoir un nombre de processeurs logiques plus important que le nombre de processeurs physiques (technologie HyperThreading chez Intel). L'ACPI permet de mettre l'un de ces processeurs logiques en veille de manière performante.

La norme ACPI 4 introduit l'objet _PUR (Processor Utilization Request). Le _PUR est passé au Processor Aggregator Device par un mécanisme de type notify. La valeur de retour est un package qui contient presque uniquement le nombre de processeurs à mettre en veille. L'OSPM

décide lui-même de la séquence d'inactivation des processeurs logiques (elle doit être la plus efficace.)

Support de l'USB3

Le très populaire USB en est désormais à la version 3, qui promet des débits bien plus importants (de l'ordre de 5Gio/s). Les connecteurs USB3 ont cependant changé de forme. La norme ACPI 4 en tient compte.

L'objet _UPC) permet désormais de mentionner précisément le type de port USB présents sur le système. Le champ type de ce package peut contenir les valeurs (Ox03 à 0x07) qui désignent des types de connecteurs USB3 (A, B, Micro-B, Micro-AB, Power-B). Les valeurs 0x08 à 0xFE sont réservées, et laissent de la marge pour les prochaines versions d'USB

Développements futurs

Il existe d'autres solutions qui pourraient, à terme, remplacer l'ACPI. Une de ces solutions est l'UEFI, anciennement connue sous le nom d'EFIEFI. C'est un logiciel entre le matériel de l'ordinateur (via le firmware) et le système d'exploitation.

L'EFI n'a pas pour vocation à l'origine de remplacer l'ACPI. Il agit plutôt comme une nouvelle couche d'abstraction. Entièrement écrit en C, l'EFI est bien plus modulable que ne l'est le BIOS. Ainsi, on peut ainsi imaginer que l'ACPI verra son intérêt diminuer avec l'apparition de telles solutions. Apple est l'un des premiers constructeurs grand public à avoir embarqué l'EFI dans leurs plateformes. L'EFI se voit ainsi comparé à un mini-système d'exploitation sur lequel viendrait se charger Windows, MAC OS X ou GNU/Linux.

AMD, American Megatrends, Dell, HP, Intel, IBM, Insyde, Microsoft et Phoenix Technologies constituent aujourd'hui au sein de l'UEFI forum des acteurs majeurs autour de cette technologie. Ces firmes travaillent actuellement sur les spécifications de l'UEFI et ont publié les spécifications officielles de l'UEFI 2.0 au début de 2006 (d'après Wikipédia).

Bien qu'intéressant, l'EFI n'en reste pas moins une technologie encore controversée. Sujet à de nombreuses critiques, comme par exemple la possibilité d'introduire des mécanismes poussés de verrouillages (DRM) directement dans les couches basses du système. De plus, l'UEFI supportant de nombreux modes de communication sur le réseau, il est peut-être la cible potentielle d'attaques visant à nuire au système d'exploitation reposant sur l'EFI.

0 comments

Envoyer des signaux ACPI

Envoyer des signaux ACPI

Signaux déjà gérés

Certains signaux ACPI sont gérés proprement à l'aide de fichiers spéciaux. Le plus connu est utilisé pour gérer les niveaux de sommeil du système.

Niveaux de sommeil du système

Il s'agit du fichier /sys/power/state (anciennement /proc/acpi/sleep). Si on lit ce fichier, on obtient les différents états disponibles. Avec l'ancienne interface, on les récupère sous la forme "S0 S3 S4 S5", avec la nouvelle interface, on les récupère sous forme plus lisible (par exemple "mem disk")
Pour basculer le système dans un des états disponible, il suffit d'écrire le nom de l'état dans le fichier. Avec l'ancienne interface : # echo -n "1" > /proc/acpi/sleep pour passer en état S1.
Avec la nouvelle interface : #echo -n "disk" > /sys/power/state
(Le flag -n pour echo permet de ne pas rajouter de saut de ligne après la chaine de caractères affichée.) Par exemple pour mettre le système en veille, echo -n mem >/sys/power/state

Signaux personnalisés

Parfois certains signaux ne sont pas déjà gérés par des fichiers spéciaux dans /proc/acpi/, et il faut pouvoir effectuer l'appel ACPI a la mano.
Un module pour le noyau a été développé, qui permet d'émettre des appels ACPI directement en les écrivant dans un fichier spécial (/proc/acpi/call). Le module est disponible sur github Le code du module est assez court, puisque celui-ci se borne à être une interface facilement exploitable par l'utilisateur. Le module crée un fichier spécial /proc/acpi/call et y attache deux callbacks, un appelé à l'écriture du fichier, qui exécute l'appel ACPI, l'autre, appelé à la lecture du fichier, qui renvoie le résultat du dernier appel exécuté.
Comme pour la modification de la table DSDT à chaud, cette méthode est pratique pour du debug, mais il n'est pas recommandé de la conserver une fois les appels ACPI nécessaires identifiés : la création de fichiers spéciaux dans /proc/acpi/ est relativement aisée, et permet contraindre un peu les appels passés.
Ce module est utilisé entre autres pour exploiter les possibilités des cartes graphiques hybrides. Ces cartes gèrent un fonctionnement double : soit la carte est pleinement exploitée, soit un chipset graphique moins performant, mais aussi plus économe. Certains sont déjà gérés par vga_switcherooo (qui fournit un fichier spécial dans /sys/kernel/debug/vgaswitcherooo, ce qui permet de changer proprement de mode), mais pour d'autres, il faut faire les appels à la main.

Sources

Page github du module acpi_call
Gestion des cartes hybrides
États de sommeil

0 comments

Modifier une table DSDT à chaud sur un système GNU/Linux

La méthode de modification de la table DSDT consistant à intégrer la nouvelle table au noyau Linux est pérenne, mais n'est absolument pas adaptée à du trial and error. En effet, recompiler son noyau à chaque modification mineure d'un élément de la table se révèle fastidieux.
Nous allons donc aborder dans cet article le remplacement (ou l'ajout) de méthodes ACPI à chaud. Évidemment une fois que la table est correctement configurée, il faut l'intégrer proprement dans le noyau. La méthode présentée ici n'est valable que pour accélerer les cycles de debug.

Récupération d'une méthode existante

Si on veut modifier une méthode existante (mais on peut très bien en ajouter de nouvelles), il faut commencer par la récupérer :

$ cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.dat
$ iasl -d dsdt.dat
(On a indiqué le nouvel emplacement dans /sys et plus dans /proc/acpi/, en vigueur depuis le noyau 2.6.37) Il suffit ensuite d'extraire la méthode désirée dans un fichier à part (par exemple nom_methode.asl), et de la modifier. On ne peut surcharger que des objets ACPI de type "METHOD". Les objets de type "DEVICE", etc ne peuvent donc pas être surchargés

Création d'une nouvelle méthode

Dans le cas d'une nouvelle méthode, il suffit de créer un fichier et d'y définir la méthode. On compilera et chargera la méthode exactement de la même façon que pour surcharger une méthode existante. Si on crée une nouvelle méthode, il faut bien préciser le namespace complet de la méthode.

Génération du code AML

Il s'agit maintenant de compiler le code ASL que l'on a écrit en code AML, qui sera interprété par la machine.

$ iasl nom_methode.asl
Un fichier nom_methode.aml sera alors généré.

Chargement de la nouvelle méthode ACPI

On commence par monter le sytème de fichiers debugfs.

# mount -t debugfs none /sys/kernel/debug
On charge ensuite la nouvelle méthode
cat /tmp/nom_methode.aml > /sys/kernel/debug/acpi/custom_method

Annuler les changements

La méthode "annuler" ("undo) n'est pas encore supportée pour les méthode insérées à chaud. Il n'est donc pas encore possible d'enlever une méthode ajoutée. Pour une méthode surchargée, si l'on souhaite annuler ses changements, il faut sauvegarder une copie de la méthode originale du code ASL puis surcharger à nouveau la méthode avec la méhode d'origine.

Il est tout à fait possible d'utiliser plusieurs méthodes modifiant l'ACPI à chaud. Mais chaque écriture sur le fichier (de type debugfs ) doit implémenter une seule surcharge de méthode (en cas d'insertion/surcharge de plusieurs méthodes ACPI, il faut les séparer, et écrire une fois par méthode dans le fichier /sys/kernel/debug/acpi/custom_method)

Il est donc bien plus pratique de créer et de tester du code ASL par cette méthode que par la méthode plus lourde qui consiste à intégrer le code au noyau. Une fois les changements validés, il ne faut pas oublier de les intégrer définitivement au noyau.

Sources:

0 comments

Gestion de l'ACPI sous GNU/Linux

Projet de veille technologique : la norme ACPI

Architecture de /proc/acpi

Lorsque le système d'exploitation démarre et que le noyau détecte un BIOS compatible ACPI, ACPI est alors activé (et APM [1] est désactivé). Les vieilles machines nécessitent parfois le paramètre acpi=on (voire acpi=force ou acpi=off) pour forcer l'activation (ou la désactivation d'ACPI). On peut vérifier la bonne activation de l'ACPI via les logs de démarrages (voir /var/log/dmesg ). Dans ce cas, il y a un répertoire /proc/acpi qui est créé. Nous allons nous intéresser de plus près à ce répertoire.

[1] Advanced Power Management, un système d'économie d'énergie sur les ordinateurs portables, gérant la mise en veille

Tous les fichiers de ce répertoire peuvent être lus (avec cat par exemple), à l'exception des tables dsdt et fadt (voir article de blog précédent). Certains fichiers peuvent être modifiés directement : par exemple echo X /proc/acpi/<fichier>. En effet, les fichiers placés dans /proc ne sont pas des vrais fichiers au sens où ce sont directement des interfaces de communication avec le noyau. Voici une brève description de ces fichiers.

/proc/acpi/info

Informations générales sur l'ACPI.

/proc/acpi/sleep

Fournit des informations sur les états de sommeil du système.

/proc/acpi/button

Ce répertoire contient toutes les informations sur les différents interrupteurs de l'ordinateur (démarrage, wifi, son, ...).

/proc/acpi/processor/CPU*/info

Informations sur les possibilités d'économies d'énergie du processeur.

/proc/acpi/processor/CPU*/power

Informations sur l'état courant du processeur. Une astérisque à côté de l'état C2 signifie que le processeur est occupé. C'est l'état le plus fréquent.

/proc/acpi/processor/CPU*/throttling

Permet d'activer le bridage du processeur. Cette interface n'est plus utilisée.

/proc/acpi/processor/CPU*/limit

Si les performances et le bridage sont automatiquement contrôlés par un démon, les limites maximum sont spécifiées dans ce fichier. Certaines limites sont définies par le système, d'autres peuvent être modifiées par l'utilisateur. Est aujourd'hui souvent remplacé par /etc/sysconfig/powersave.

/proc/acpi/thermal_zone/

Un sous-répertoire existe pour chaque zone thermique. La plupart des possibilités ne sont pas exploitées par l'ACPI et c'est souvent le BIOS qui fournit ces informations. Le système d'exploitation n'a pas souvent l'occasion d'intervenir sur ces fichiers.

/proc/acpi/thermal_zone/*/temperature

Température actuelle de la zone de température.

/proc/acpi/thermal_zone/*/state

Cet état indique si tout est "ok" ou si ACPI effectue un refroidissement "active" ou "passive". Dans le cas où l'ACPI est indépendant de l'état du ventilateur (lorsque celui-ci est contrôlé par le BIOS), cet état sera forcément à OK.

/proc/acpi/thermal_zone/*/cooling_mode

Active le refroidissement passif (moins bonnes performances, plus économique) ou le refroidissement actif (performances au maximum, ventilateur au maximum et en continu).

/proc/acpi/thermal_zone/*/trip_points

Mise en place des limites pour les températures dont dépendront l'activation de certains modes de refroidissement (actif ou passif). Sont aussi précisées les états de supsension si la température est trop importante ("hot") et un état pour l'arrêt immédiat ("critical").

/proc/acpi/thermal_zone/*/polling_frequency

Si la température n'est pas mise à jour automatiquement lorsqu'elle change, la fréquence de vérification est alors définie ici.

Vers une nouvelle architecture

La publication du dernier noyau Linux (le 09 décembre 2010) [2] change toute l'arborescence du répertoire /proc/acpi et le considère comme obsolète. La plupart des entrées deviennent obsolètes et sont remplacées par leur équivalent Sysfs.

Voici une liste non exhaustive de ces changements :

  • /proc/acpi/sleep devient /sys/power/state
  • /proc/acpi/info devient /sys/module/acpi/parameters/acpica_version
  • /proc/acpi/dsdt devient /sys/firmware/acpi/tables/DSDT
  • /proc/acpi/fadt devient /sys/firmware/acpi/tables/FACP
[2] http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.36.2

Exploiter les informations contenues dans /proc/acpi

Les informations fournies par ACPI étant fournies dans des fichiers texte, il est facile d'y accéder dans des scripts. C'est utile par exemple pour générer des alertes quand une température est trop élevée. Quand on n'utilise pas un environnement de bureau « clés en main » (openbox, awesome, fluxbox, …), il est aussi nécessaire de mettre soi-même en place certains mécanismes comme la mise en veille à la fermeture de l'écran d'un ordinateur portable, ou applet affichant la charge de la batterie.

Par exemple pour avoir l'état de la batterie, on peut consulter

/proc/acpi/BAT0/state

pour avoir accès au mode de fonctionnement (chargée / en charge / endécharge), à la vitesse de charge / décharge) et à l'énergie restante (enmAh). Pour passer à un pourcentage de charge, il faut consulter

/proc/acpi/BAT0/info

qui contient la capacité totale de la batterie, ses caractérisquesmatérielles, etc.

grep "remaining capacity" /proc/acpi/battery/BAT0/state |\
cut -d":" -f2|\
sed -e "s/[^0-9.]//g" # Remove spaces and units
grep "last full capacity" /proc/acpi/battery/BAT0/info|\
cut -d":" -f2 |\
sed -e "s/[^0-9.]//g" # Remove spaces and units

De même, pour la température du processeur

grep "temperature" /proc/acpi/thermal_zone/THRM/temperaturecut -d":" -f2 |\
sed -e "s/[^0-9.]//g" # Remove spaces and units

Les identifiants BAT0, THRM, et tous les autres sont évidemment à adaptersuivant le système.

La deuxième partie est la gestion des événements ACPI. Sous GNU/Linux, on peututiliser acpid pour appeler des scripts lorsqu'un événement précis se produit.

Par exemple, dans

/etc/acpi/events/lidbtn

les lignes

event=button[ /]
lidaction=/etc/acpi/lid.sh

permettent de passer les événements liés à l'état du couvercle d'un ordinateurportable au script lid.sh qui effectuera les opérations nécessaires.

Ainsi, il est possible de configurer la gestion énergétique de son ordinateurassez simplement et UNIX-ement (outils simples, flux de texte, etc).

Sources :

Clément Delafargue / Benjamin Vialle

0 comments

Désassembler une table ACPI

L'ACPI implémente de nombreuses tables qui décrivent comment l'ordinateur doit
gérer l'énergie des composants. La plus connue d'entre elles est la table DSDT

La dernière version de la norme ACPI, la version 4.0, est sortie le 16 juin
2009 [1]

La table DSDT


La table DSDT (Differentiated System Description Table) est la table ACPI la
plus connue. Cette table contient des informations et une configuration sur le
système de base. Il n'est pas toujours capable de fournir les tables de
fonctions complètes et doit parfois être corrigé.

En effet, on trouve aujourd'hui des sites [2] référençant des tables ACPI
patchées (en particulier la table DSDT) ainsi qu'un patch noyau [3] permettant
d'ignorer la table DSDT de l'ordinateur pour utilisée celle modifiée. Passer
outre la DSDT est donc assez facile : au lieu de charger la table DSDT du BIOS,
le noyau est compilé avec et utilise sa propre table DSDT.

Nous nous sommes donc intéressé au désassemblage d'une table DSDT sous GNU/Linux.

Désassemblage d'une table DSDT

La méthode utilisée récupère la table DSDT chargée par le noyau, accessible via
/proc/acpi/dsdt

Nous récupérons donc la table DSDT de l'un de nos oridnateurs :

# cp /proc/acpi/dsdt DSDT


La table récupérée est écrite en AML (ACPI Machine Language). C'est une
syntaxetrès proche de l'assembleur Il convient ensuite de désassembler la table
DSDT du fichier ainsi récupéré :

$ iasl -d DSDT


Nous obtenons alors un fichier d'environ 10000 lignes contenant toute la table
DSDT. La syntaxe utilisée est la syntaxe ASL.

La table DSDT peut ensuite être modifiée et recompilée :


$ iasl -tc DSDT.dsl


On commence alors à toucher du doigt les limites des composants fournis par les
grands constructeurs. Que ce soit l'ordinateur de Clément (DELL) ou le mien
(ThinkPad), la recompilation de la table DSDT provoque moultes erreurs et
warnings. Ainsi, il sera possible de demander à l'ordinateur de se contenter
d'une table DSDT partiellement compilée, contenant des erreurs. Ce sera alors
au noyau du système d'exploitation de s'en accomoder.

Ceci explique en partie la grande difficulté des OS libres à mettre
correctement un ordinateur en veille ou en hibernation.

L'ASL ?

L'ASL, pour ACPI Control Method Source Language, est un langage déclaratif qui
est compilé en AML (ACPI Machine Language). La spécification ACPI décrit le
langage ASL, mais seul le langage AML doit obligatoirement pouvoir être
interprété par le Système d'Exploitation. Rien n'interdit de générer de l'AML
de la manière que l'on souhaite.

La syntaxe ASL en elle-même est relativement lisible, mais le résultat d'un
désassemblage est toujours complexe à appréhender. Il reste en effet un
certain nombre de fragments en hexadécimal, et les variables internes n'ont
pas des noms parlants.

Contenu d'une table DSDT

Structure


Toute la table DSDT est comprise dans un unique *DefinitionBlock*. Cette
entité est compilée et chargée en bloc par le système d'exploitation.
Il peut cependant y avoir plusieurs *DefinitionBlocks* dans une table (par
exemple dans le cas d'une docking station).

À l'intérieur du *DefinitionBlock* se trouvent différents types de
déclarations.

* Name(object) pour définir un objet dans l'espace de nom global
* Method pour définir une *Control Method*, c'est à dire une procédure qui
peut être appelée. Il est à noter que le mot clé Serialized permet
d'associer un verrou d'exclusion mutuelle (mutex) à la méthode.
* Device(identifiant) pour définir un élément physique
* Notify(object, value) pour prévenir le Système d'Exploitation d'un
événement lié à l'objet passé en argument.
* Scope pour définir un espace de nommage.


Points intéressants


En parcourant la table DSDT de mon ordinateur portable (un Dell XPS 13"), j'ai
pu m'apercevoir qu'à l'intérieur d'une procédure, une distinction était faite
en fonction du nom du système d'exploitation. Plusieurs versions de Windows
étaient mentionnées. GNU/Linux n'apparait pas (mais dans la table DSDT du
Lenovo de Benjamin, si).

J'ai tenté de recompiler la table DSDT désassemblée, et la compilation, tout
en s'effectuant, a remonté plusieurs erreurs et des dizaines de Warnings.
On peut donc penser que Dell ne met pas beaucoup de soin dans la rédaction de
ses tables ACPI.


[1] http://linuxfr.org/2009/06/24/25646.html
[2] http://acpi.sourceforge.net/dsdt/index.php
[3] http://gaugusch.at/kernel.shtml


Benjamin V. et Clément D.

0 comments

La norme ACPI

Projet de veille technologique : la norme ACPI

Plan d'approche du sujet

Dans un premier temps nous nous attacherons à décrire précisément la norme, son cadre d'application, son fonctionnement, ses limitations et son avenir.

Nous nous intéresserons ensuite au contenu de la table DSDT (Differenciated System Description Table) qui contient les informations sur le système de base. Cette table qui joue un rôle central nécessite souvent d'être réparée pour fonctionner correctement sous GNU/Linux, car les constructeurs respectent rarement la norme ACPI.

Nous étudierons ensuite son implémentation dans le noyau Linux, en particulier la structure de /proc/acpi.

Par exemple, sous Linux, quels sont les informations que nous obtenons grâce aux fichiers présents dans /proc/acpi ?

Présentation rapide de la norme ACPI

La norme ACPI (pour Advanced Configuration and Power Interface) est une norme ayant pour but de gérer simplement la mise hors-tension de différents éléments matériels d'un ordinateur.

L'ACPI permet donc de communiquer avec le matériel pour gérer ses différents états.

L'ACPI est très important sur un ordinateur portable, puisque de l'état des différents périphériques dépend la durée de la batterie. Ainsi, éteindre les périphériques non utilisés permet de prolonger la durée d'utilisation sans secteur de la batterie.

Comme malheureusement de nombreux "standards" en informatique, il n'y a pas eu de normes ou celles-ci n'ont pas été respectées. En effet, de nombreuses machines sont équipées de tables ACPI erronées. Il existe la possibilité de charger une table ACPI alternative sur Linux pour mieux prendre en charge la gestion de l'état du matériel.

One thing I find myself wondering about is whether we shouldn’t try and make the "ACPI" extensions somehow Windows specific.

If seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work.

Maybe there is no way to avoid this problem but it does bother me.

Maybe we could define the APIs so that they work well with NT and not the others even if they are open.

Or maybe we could patent something related to this.

Mail de Bill Gates à propos de l'ACPI.

Il y a donc d'intéressantes pistes à explorer autour de cette norme, et notamment son implémentation dans le noyau Linux.

Sujet encadré par Didier Lime

1 comment