Kernel Traffic #245 For 14 Dec 2003

Le but de ce mail est de clarifier ma position pour le 2.4.x dans le futur.

Le 2.6 devient de plus en plus stable chaque jour, et nous espérons voir la sortie du 2.6.0 durant ce mois-ci ou en janvier.

Ceci étant dit, j'ai l'intention de:

• Corriger les problèmes en attente qui pourraient nécessiter des modifications plus intrusives en 2.4.24. De nouveau drivers seront acceptés pendant cette période (par exemple, le driver Cyclades PC300, support du driver d'entrée mode-utilisateur ou tout autre driver sain qui pourrait apparaître).
• A partir du 2.4.25, correction des problèmes critiques/sécurité.

Les gens sont _profondément_ concernés sur une ABI du point de vue utilisateur. Je pense personnellement que la compatibilité descendante est _la_ chose la plus importante pour tout kernel, est casser les ABI coté utilisateur n'est pas fait.

Parfois on bidouille des choses visibles côté utilisateur (par exemple, en enlevant des appels système vraiment obsolètes), mais même là nous sommes extrêmement vigilants. Comme en affichant des messages d'avertissement pendant plusieurs _années_ avant d'enlever effectivement une fonctionnalité.

une exception concerne les ABI "gestion du système", c'est à dire des trucs que les programmes normaux n'utilisent pas. Les mises à jour de kernel ont dont parfois besoin de nouveaux utilitaires pour faire des choses comme la configuration de firewalls, configuration du matériel (utilitaires ethernet, ifconfig etc), où - dans le cas du 2.6 - chargement de modules et déchargement. Même cela est regardé avec suspicion, et doit être accompagné de bonnes raisons.

Parfois, nous avons modifié les sémantiques de comportements système existants de manière subtile: soit pour être conforme aux standards, soit pour des problèmes d'implémentation. Ça n'arrive pas souvent, et si ça casse les applications existantes, ce n'est pas fait du tout (et le problème est corrigé en ajoutant un nouvel appel système avec les sémantiques correctes, et en laissant l'ancien).

Vous avez, cependant, raison en ce qui concerne les interfaces internes du noyau: nous ne nous en soucions pas des ABI's, et même les API sont fluides et changent librement si il y a une raison technique pour cela. Mais c'est uniquement vrai pour ce qui est interne au kernel (où les sources sont obligatoires de toute façon).

Absolument. Cela n'arrivera pas. Je suis _complètement_ ininteressé par le fait d'avoir une ABI stable pour les modules kernel, et je suis même fermement opposé a l'_essai_, je veux que les gens sachent que les mécanismes internes du kernel changent et que ça va continuer.

Il n'y a pas de bonne excuse pour les modules binaires. Certains peuvent être techniquement légaux (en n'étant pas des travaux dérivés) et permis, mais même lorsqu'ils sont légaux, ce sont des épines dans le pied et toujours, horriblement bogués.

Je reçois de temps à autre des plaintes de constructeurs sur mon non-intérêt à ne serais ce qu'essayer d'aider les modules binaires. C'est une route à double sens: si vous ne m'aidez pas, je ne vous aide pas. Les modules binaires n'aident pas Linux, à l'inverse. Comme tel, nous ne devrions pas avoir d'initiatives les rendant plus courants qu'ils ne le sont déjà.

Voilà mes premières réflexions après la lecture de Documentation/fusyn.txt .

• Tout ici peut-être implémenté sur des futex classiques, mais ça ne veut pas dire que l'implémentation sera efficiente ou robuste. (Parce qu'en général, toute sorte d'implémentation futex/fuqueue/autre peut être déplacée de l'espace kernel à l'espace noyau, en utilisant de vrais futexes kernel pour simuler des waitqueues et spinlocks appellés dans futex.c).

C'est ce que j'ai pensé au début, et mes premiers essais (l'année dernière?) allaient dans ce sens, mais il y a pas mal de problèmes (si je ne me trompe pas). Par exemple:

• [mineur] éviter les inversions de priorité: vous ne pouvez pas laisser le lock delocké pendant que vous transférez la possession. C'est accompagné de race conditions lorsque vous essayez d'implémenter ceci.
• héritage/protection de la priorité: ça sent le soufre! vous aurez tellement d'appels systèmes dans le kernel et de race conditions que ce n'est probablement pas la peine. Vous devrez lancer de gros travaux pour implémenter le wait_cancel d'un boosting thread. Vous devez être capable de savoir qui est propriétaire de quoi et de suivre une chaîne potentiellement longue de propriétaire/wait (plus de kernel) afin de booster (réassigner les priorités) chaque propriétaire jusqu'à atteindre la fin. Ceci implique d'avoir les privilèges et les moyens d'y jeter un coup d'oeil.
• robustesse: vous avez besoin du kernel, au moins pour identifier le mort, et pour toutes les applications qui ont besoin de cette fonctionnalité, ça doit être très rapide. Ça pourrait peut-être être accéléré, mais pas pour être aussi rapide que maintenant (vous devrez demander le vfulock, vérifier que personne n'essaye d'initier un recovery -- ce qui nécessite un autre lock, qui nécessite de la robustesse aussi, la poule et l'oeuf quoi -- puis essayer un recovery); une grosse épine dans le pied pour résumer.

C'est la première chose à laquelle j'ai pensé; cependant, ce n'est pas une tâche facile --par exemple, vous devrez allouer un noeud central qui qui doit être actif pendant tout la durée de vie de la file (au contraire des futexes), et ça ne marche pas trop bien-- avec le code actuel, au contraire de mes essais précédents avec les rtfutexes, ce n'est pas un gros problème et ça pourrait être fait, mais je ne sais pas quelle partie de l'interface je pourrais émuler.

De même, supporter le changements de priorité pendant l'attente nécessite plus de travail...

C'est dans ma liste todo d'ajouter d'autres parties à la couche fuqueue pour qu'ils puissent faire tout ce que font les waitqueues avec une interface basée sur la priorité.

Il serait intéressant d'expérimenter dans un sous-système les fuqueues en remplaçant les fuqueus, pour voir ce qui arrive.

Dans les futexes, chaque hash chain a tous les attendants, en ordre d'arrivée FIFO, et nous en réveillons autant que nécessaire. Dans les fuqueues, ce réveil doit se faire par priorité. Nous pourrions parcourir la chaîne d'avant en arrière pour les réveiller dans l'ordre correct, mais ça deviendrait tout sauf O(1), et être simili "temps réel", ou être prédictable, fait partie du cahier des charges.

Donc, la file d'attente a une tête, la fuqueue->wlist et les attendants sont ajoutés là dans la position correcte (donc l'addition est O(N) maintenant, et je compte la changer en 0(1), la suppression de celui avec la plus haute priorité est O(1)--le mettre en tête).

Aujourd'hui dans les ufuqueues (celles qui sont associées à des adresses en espace utilisateur, le véritable équivalent futex) ce qui veut dire que vous ne pouvez pas faire la bidouille avec les listes de chaînes futex, donc vous avez pour chaque chaîne une tête par ufuqueue/adresse en espace utilisateur. Cette ufuqueue ne peut pas être déclarée dans la pile d'un des attendants, puisqu'elle disparaîtrait lors de son réveil et pourrait laisser les autres dans le vide.

Nous devons donc l'allouer, lui ajouter les attendants, et la désallouer lorsque la file d'attente est vide. C'est ce qui complique l'affaire et ajoute le tas de code qui est vl_locate() [l'allocation et ajout à la liste, vérification de collisions quand les locks sont libérés]. Comme le tout est relativement coûteux, nous avons intérêt à le garder en cache quelques secondes, il y a des chances que nous ayons une localité temporelle (en fait, il s'avère que ça améliore de beaucoup la performance), donc ça ajoute plus de code encore pour faire le "garbage collector", ça nettoie les chaînes de hash de têtes de file inutilisées de temps à autres. Voilà tout ce que fait le code de vlocator.

Malgré tout, au lieu d'allouer de la mémoire à la demande, vous pouvez garder un pool de files disponibles. Chaque fois qu'une tâche est crée, en allouer une et l'ajouter à la file; chaque fois qu'une tâche se finit, en récupérer une et la libérer. Puisqu'une tâche ne peut attendre que sur une file à un moment donné, vous ne manquerez pas de files (sauf si vous voulez implémenter une sorte de wait pour des objets multiples; mais, dans ce cas, vous pourriez allouer des files supplémentaires sur demande sans affecter le cas classique d'un objet unique).

Par conséquent, ce serait une opération sur une liste simplement chaînée plus un spinlock pour acquérir et libérer une file si quelque chose se bloque. Ce serait plus lent que l'implémentation actuelle de waitqueue, mais pas de beaucoup (et ça pourrait être rendu configurable pour ceux pour qui chaque cycle compte et qui ne veulent pas des files d'attente temps réel).

Ce serait bénéficiaire pour l'usage en espace utilisateur aussi, puisque bloquer sur une file ne se verrait plus retourner la valeur -ENOMEM (qui est généralement indésirable dans ce qui est censé est une application prédictible temps-réel).

J'aime l'idée, spécialement à cause des garanties, mais je ne sais comment ça sera accepter:

1. la file d'attente est juste le type de base, fulock se développe au dessus, donc un fulock est plus gros qu'une fuqueue. Donc, vous devez allouer pour chaque tâche pour que ça ait un sens (si nous ajoutons un jour des rwlocks, il pourrait se passer quelque chose de similaire).

   Nous pourrions aussi dire: ok, nous les séparons, mais alors vous devrez allouer des trucs supplémentaires autre part et vous revenez à la case départ (sans mentionner toutes les complications induites).

2. Beaucoup de tâches n'utiliseront pas de locks en espace utilisateur, donc elles n'utiliseront pas les files/locks associés, donc l'espace sera gâché pour chaque tâche qui ne les utilise pas.
3. Cela ralentira le temps de création d'une tâche.

Il faudra faire un choix: voulons nous faire avec l'espace gâché (2) et (3) pour éliminer le problème -ENOMEM?

Je pense implémenter un programme de test configurable pour voir comment ça marche.

Un autre point, la meilleure chose pour l'espace utilisateur serait de réessayer l'appel si il voit un -ENOMEM (quelque chose comme -EAGAIN).

D'un autre coté, nous devrions forcer des marques hi/lo dans le nombre des fulocks/fuqueues dans les caches kmem pour chacun.

Ah, ah, ah ... je vois. Ok, donc c'est comme une opération unlock mais "unlock ce gars". Bien, même chose mais étendue. Vous devez l'essayer en espace utilisateur, si ça échoue parce que c'est KCO (locké et il y a des attendants), alors allez en kernel et lui demander de transferer la possession ici.

Facile à faire, plus ou moins, et peut-être fait en O(1) en vérifiant dest_task->fuqueue_wait. Quel en est l'intérêt? Je suis curieux de voir ce pourquoi c'est utilisé.

Je vais m'en occuper dès que j'ai une minute (sauf si votre question est purement académique et ne comporte pas d'application précise).

D'abord, je vais faire une distinction qui cause bien trop de confusions, une chose est KCO pour le vfulock (dire à l'utilisateur que ça doit aller dans le kernel) et une autre est de toujours l'utiliser en mode KCO en passant un flags-devant-être-implémenté FULOCK_FL_KCO aux appels sys_ufulock_*() (donc on évite tout le laid code de synchronisation).

Ce FULOCK_FL_KCO est nécessaire pour la protection de priorité de toute façon, il sera donc présent; donc dans les architectures sans comparer-et-échanger atomique, ça devient un problème de oops-je-n'ai-pas -de-chemin-rapide, j'appelle donc juste le syscall avec le bit mis.

Je suis d'accord avec cela, mais pensez aux éléments. La seule partie qui est strictement équivalente aux futexes est celle des ufuqueues, c'est donc ufuqueue.c, fuqueue.c et vlocator.c. Cette séparation est nécessaire pour permettre aux différentes parties d'être partagées par les fulocks.

Commentaires mis à part, il ajoute la partie la plus complexe, le tri par priorité, le support chprio vs ne pas avoir de FUTEX_FD ou de support requeue...ça tend a être plus ou moins équivalent, si on prend en compte tout ce qui doit être changé pour les priorités pour travailler avec les sémantiques POSIX incroyablement stupides pour les temps de vie des mutex.

Le cryptage n'est pas si facile à mettre en place au dessus d'un système de fichiers existant pour un raison simple: en raison de problèmes de performance (et taille mémoire), la plupart des systèmes de fichiers font de l'"IO in place". En d'autres mots, il font les E/S directement dans ou à partir du cache de pages.

Avec un système de fichiers encrypté, vous ne pouvez pas faire ça. Ou plutôt: vous pouvez le faire si le système de fichiers est en lecture seule, mais vous ne POUVEZ PAS le faire lors de l'écriture. Pour l'écriture vous devez traiter le buffer de sortie autre part (et franchement, c'est plus facile si vous le faites pour lire aussi).

Et cela rapporte des problèmes à son tour. Vous avez tout un tas de scénarios d'interblocage lorsque l'écriture nécessite plus de mémoire pour réussir. Vous devez être attentif. Lire finit par être bien plus facile (par les mêmes problèmes d'interblocage _et_ vous pourriez le faire sur place de toute façon).

Le cryptage en soi n'est pas difficile. Mais ajouter la couche de buffers indirects supplémentaires _peut_ s'avérer désagréable, et difficile a traiter par la suite.

** NOTE NOTE NOTE **

Si vous n'avez pas besoin de mmaper() les fichiers, écrire devient plus facile. Parce qu'alors vous pouvez instaurer des règles comme "les accès à la page cache arrivent toujours lorsque la page est lockée", ensuite la couche de cryptage peut crypter sur place.

Il est donc potentiellement bien plus facile de faire du cryptage un cas particulier, et interdire mmap dessus, ainsi que d'interdire les lectures/écritures concurrentes sur les fichiers cryptés. C'est acceptable pour bien des cas (la plupart des programmes marchent toujours sans mmap - mais vous ne pourrez pas crypter des binaires chargés à la demande par exemple).

Oui, la compression et le cryptage sont la même chose du point de vue de l'implémentation du fs - ils ont juste de buts différents. Donc oui, tout système de fichiers compressé aura les mêmes problèmes pour une grande part.

La compression est difficile à traiter par la suite de la même manière.

Le cryptage a des problèmes supplémentaires, simplement par sont but. Dans un système de fichiers compressé, il est permis de dire "cette information est petite et difficile à compresser, ne le faisons pas" (les méta-données par exemple). Alors que dans un système de fichiers crypté, vous ne devriez pas laisser de côté des morceaux "difficiles".

(Les systèmes de fichiers cryptés ont aussi des problèmes de gestion de clés, compliquant un peu plus la chose, mais la complication tend a être à un niveau supérieur).

Une partie de notre projet de fs empilable (FiST) inclut un étage Gzipfs de compression. Il y eut un article dessus dans Usenix 2001, et il y a du code dans le dernier package fistgen. Voir http://www1.cs.columbia.edu/~ezk/research/fist/

La performance de Gzipfs est un autre problème, particulièrement pour les écritures au milieu du fichier. :-).

Nous compressons chaque morceau séparément; en ce moment chunk==PAGE_CACHE_SIZE. Pour chaque fichier foo, nous conservons un fichier index foo.idx qui enregistre les offsets dans le fichier principal où vous pourriez trouver les données compressés pour la page N. Nous l'accrochons ensuite dans les opérations de lecture/écriture de pages du VFS. Ça marche bien pour les modes d'accès aux fichiers les plus communs: petits fichiers, accès aléatoire/séquentiel en lecture, écriture séquentielle. Mais ça marche mal pour les écritures aléatoires dans de gros fichiers, parce que nous devons décompresser et recompresser les données après avoir écrit. Notre article donne un grand nombre de résultats de benchmarks montrant la performance et l'utilisation de l'espace selon différents scénarios.

Nous avons quelques idées sur comment améliorer la performance d'écritures-au-milieu, mais ça pourrait amoindrir la performance dans les cas courants. En résumé, nous devons alors vers des structures de données O(log n), ce qui rendrait les écritures aléatoires bien meilleures. Mais puisque ça pourrait impacter les performances d'autres modes d'accès, nous avons réfléchi à un moyen de supporter les deux modes et d'être capable de passer de l'un à l'autre à la volée (ou au moins de laisser les utilisateurs "marquer" un fichier comme étant destiné a être écrit de manière aléatoire).

Si quelqu'un a des commentaires ou suggestions, nous serions heureux de les entendre.

C'est sur. Je l'ai décrit avant à cette liste, mais voila comment ça marche:

Ce qu'a fait Acorn pour leur produit RISCiX (basé sur 4.3BSD, tournant sur une machine ARM dans la fin des années 80/début 90), était de compresser chaque page de 30Ko individuellement et de l'écrire sur un système de fichiers de taille block 1Ko (les disques faisaient atour de 50Mo à l'époque, 1Ko était la bonne taille). Ceci laissait le fichier plein de trous, et faisait perdre en moyenne 512/32Ko = 1/64 de la compression qui pouvait être atteinte, mais c'était très rapide de retrouver le bon endroit.

Aujourd'hui, les systèmes de fichiers avec une taille de block à 4Ko sont la règle, et la taille de page est aussi de 4Ko, donc vous ne devez pas forcément être plus futé pour obtenir le même effet. Compresser des morceaux de 256Ko a un moment donné vous donnera la même perte, mais je ne pense pas que Linux ait un bon support pour les systèmes de fichiers qui veulent larguer 64 pages dans le cache de pages alors que la VM/VFS n'en ont demandé qu'une.

Si il l'avait, ça pourrait permettre à ext2/3 d'agrandir les tailles de blocks au delà de la limite des 4Ko sur i386, ce qui serait une bonne chose à faire. Ou peut-être nous devons prendre le taureau par les cornes et augmenter le PAGE_CACHE_SIZE à quelque chose de plus gros comme 64Ko. Les gens voudront cela sur leurs systèmes 32 bits bientôt de toute façon.

Bien sur tout cela est fait au niveau fichier, qui s'appuie sur le support approprié des trous dans le système de fichiers sous-jacent (ce qui était le cas dans le BSD FFS d'Acorn). La politique de FiST est de considérer un implémentation sans le support de trous, où vous *devez* rassembler les données, autrement l'espace "inutilisé" consommerait physiquement des blocs disque. Dans ce cas un index pour trouvez le début de chaque block compressé est essentiel.

Je suppose que FiST n'a pas de support de trous ou d'insertion de données dans le modèle du système de fichiers, ce qui explique pourquoi lors de l'écriture au milieu d'un fichier le fichier complet à partir de ce point doit être réécrit.

Bien sûr, tout ceci se passe au niveau fichier logique, et ignore les blocs physiques sur le disque. Tous les systèmes de fichiers assument que les blocs de données physiques peuvent être mis à jour sur place. Avec la compression si c'est possible, un nouveau block physique doit être trouvé, surtout sil les blocks sont rassemblés et non-alignés sur les limites de blocks. Je pense que c'est pourquoi JFFS2 est un système de fichiers structuré autour d'un log.

Pas vraiment. JFFS2 est un système de fichiers structuré autour du log parce qu'il est fait pour marcher sur du _flash_, pas sur des périphériques block. Vous avez une taille d'eraseblock typique de 64Ko, vous pouvez supprimer des bits dans ce 'block' autant que vous voulez jusqu'à ce qu'ils soient tous supprimés ou que vous vous en lassiez, alors vous devrez l'effacer à OxFF et recommencer.

Même si vous admettiez d'avoir une taille de block de 64Ko pour les couches au dessus de vous, pour ne pouvez pas _faire_ un remplacement atomique de blocs, ce qui est nécessaire pour les systèmes de fichiers normaux afin de marcher correctement.

Ces caractéristiques de flash ont souvent été gérées en implémentant une 'couche de traduction' -- une sorte de pseudo système de fichiers -- qui imite un périphérique block avec un comportement écrasement-atomique de 512 octets normal. Vous utilisez ensuite un système de fichiers traditionnel au dessus de ce périphérique bloc émulé.

JFFS2 a été conçu pour éviter cette couche supplémentaire inéfficiente, et pour travailler directement avec le flash. Puisque réécrire des trucs sur place est si difficile, ou nécessite une couche de translation pour mapper les adresses 'logiques' en adresses physiques, nous avons abandonné l'idée que la location physique veut dire _quoi que ce soit_.

A partir de là, la compression fit son apparition; ce fut trivial.

Comme je le lis dans le ChangeLog:

aa VM inclusion: page réclame des changements, on tue l'oom killer

L'OOM Killer a été supprimé a cause des changements AA VM, ça ne peut donc peut-être pas être réactivé simplement.

ça peut être réactivé sans trop de difficultés si vous acceptez le comportement ordinateur de bureau de 2.4.22 et avant, qui n'est pas adapté aux serveurs.

L'oom killer avait des interblocages, et reposait sur une comptabilité inexacte, il y avait donc un certain nombre de cas où il terminait des tâches par erreur (il est trompé par shm/mlock/noswap etc..), j'ai aussi lu des rapports de bogues pour 2.4.22 avec des tâches étant terminées parce qu'il n'y avait pas de swap sur la machine (vous essayez de lancer une machine sans swap, la swap n'est pas obligatoire, c'est un souhait). Résoudre cela en 2.4 semble trop compliqué, et il est maintenant trop tard pour espérer faire un oom killer correct pour 2.4.

Pour mémoire 2.2 était capable de vérifier iopl pour retarder quelque temps la terminaison du serveur X, ça n'a pas été porté en 2.4. Pour le 2.6 nous pouvons faire quelque chose de mieux que tous les oom killers passés. 2.6 se fait tromper par mlock aussi d'ailleurs, termine aléatoirement des tâches etc... il n'est donc pas bien meilleurs que 2.4.22 sur la question de l'oom killer.

c'est simple a réactiver en 2.4.22, si vous êtes d'accord pour avoir des situations d'interblocage. Le 2.4.23 ne peut pas s'interbloquer, il peut faire un livelock si vous êtes malchanceux avec les timings (imaginez ajouter 32Go de swap et votre ram tourne à 1k/sec au lieu d'1G/sec), mais pas s'interbloquer et il ne tuera pas des tâches aléatoirement même si il ne devrait pas le faire. L'interblocage est un bogue, terminer une tâche alors qu'il y a de la ram libre est un bogue, le livelock est évitable si vous laissez tomber tout le swap. Si vous laissez tomber tout le swap en 2.4.22 il deviendra fou en terminant des tâches (voir les rapports de bogue).

Puisque le faire correctement n'était pas possible en 2.4, je l'ai laisser tomber il y a des années, les utilisateurs -aa n'ont pas d'oom killer depuis des années et je n'ai jamais entendu une plainte. certains ont demandé pourquoi, oui, mais étaient heureux par la suite. Je ne pense pas avoir demandé à Marcelo de l'intégrer, j'ai expliqué pourquoi je l'avais abandonné, certains lui envoyaient des rapports de bogues sur l'oom killer devenant fou, et il accepta que ma solution était la meilleure à court terme sans induire trop d'efforts pour faire marcher l'oom killer. Notez que l'oom killer devient fou en 2.6 aussi, personne ne l'a fait correctement à ce jour, c'est pourquoi je ne pense pas que ce soit un problème 2.4

Marcelo m'a demandé de le rendre configurable au runtime pour que vous puissiez aller dans le mode susceptible d'interblocage du 2.4.22 à la demande, mais je n'ajouterais pas plus de fonctionnalités au 2.4 aujourd'hui sauf si il y a des bogues bloquants (même si c'était simple a implémenter), en fait ce n'est même pas de mon ressort, donc ne me demandez pas de le faire, désolé.

J'ai intégré quelques unes des diverses améliorations soumises par TimeSys Corporation dans le kgdb principal sur http://kgdb.sourceforge.net/ La version de kgdb contenant ces fonctionnalités est la 1.7. Elle est disponible pour le kernel 2.4.23. Voici une brève description des améliorations.

1. gdb detach reconnect sans problèmes: Vous pouvez maintenant détacher gdb de kgdb en utilisant la commande "detach" de gdb. La reconnection plus tard est faite par la commande "target remote" de gdb.
2. Fichiers sources restructurés: Divers fichiers sources de kgdb ont été restructurés pour séparer le code dépendant ou indépendant de l'architecture dans leurs répertoires respectifs. C'est un pas vers l'unification du code des différentes architectures de kgdb.

Ceci pour annoncer la 2.0-rc3, est uploadé sur swsusp.sf.net.

Un nombre de petits mais conséquents changements visibles par l'utilisateur ont été faits lors de cette version, lisez attentivement les notes s'il vous plaît.

1. Nouveau format. Il y a maintenant un patch 'principal' qui devrait être appliqué quelle que soit la version du kernel. En addition au patch principal, un patch dépendant de la version devrait être appliqué. Ceux-ci sont disponibles pour les familles 2.4 et 2.6 de kernels. Les patches principaux et dépendant de la version devraient pouvoir être mis à jour indépendamment.

   SPÉCIFIQUEMENT DANS LE CAS 2.6, LE PATCH DÉPENDANT DE LA VERSION DEVRAIT ÊTRE APPLIQUÉ EN PREMIER. Autrement des rejets arriveront.

2. Changement des paramètres de la ligne de commande du kernel. A la place de resume=, resume_block= et resume_blocksize=, il y a maintenant un simple paramètre resume2=. Notez que c'est RESUME2, pas RESUME. Le format pour ce paramètre est:

   resume2=[writer]:[writer-specific-parameters]

   Pour le moment, il n'y a qu'une méthode pour sauvegarder les images - le swapwriter. Il est envisagé d'implémenter le support NFS a un moment dans le futur. (Après que je fasse le travail d'intégration avec Patrick). Pour l'instant, alors, vous remplacerez

   resume=/dev/hda1 resume_block=0x560 resume_blocksize=1024

   par

   resume2=swap:/dev/hda1:0x560@1024

   Plus tard vous serez peut-être capable de faire
   resume2=nfs:192.168.1.1/images/laptop.

3. /proc/sys/kernel/swsusp est maintenant obsolète. Il est toujours présent dans cette version mais j'aimerais que les scripts soient changés pour utiliser la nouvelle entrée /proc/swsusp/all_settings à la place. Les fonctionnalités sont exactement les mêmes. Seul l'endroit à changé.

   En plus, une tonne de changements visibles par l'utilisateur ont été faits. Ceci explique la taille du patch. Une nouvelle API interne implémente deux types de 'plugins', conçue pour ajouter de nouvelles méthodes pour transformer les données à stocker ('transformer') et pour sauvegarder les données ('writers') plus facile à implémenter. Ceci m'a permis de séparer le code spécifique swap et le code de compression comme part du grand nettoyage que j'ai aussi fait. Le code /proc a été amélioré, afin que les plugins puissent dynamiquement enregistrer de nouvelles entrées. Ceci formera aussi les fondations pour le support de kobject dans le kernel 2.6. (C'est à dire que le swsusp 2.6 cessera bientôt d'utiliser proc et utilisera sysfs à la place.

4. Compatibilité avec d'autres implémentations 2.6.

Cette version devrait marcher correctement avec les implémentations de software suspend dans le kernel 2.6. L'implémentation pmdisk de Patrick peut être activée comme toujours en utilisant l'interface sysfs, et celle de Pavel utilisant echo 4 > /proc/acpi/sleep. Ce patch remplace l'implémentation freezer qu'utilisent ces versions, et le suspend de Pavel s'initialisera mais n'utilisera pas le véritable affichage. Mis à part ces changements mineurs, aucune différence ne devrait être vue.

Pour ceux qui veulent simplement se mettre à jour à partir d'une rc2, un patch incrémental est aussi disponible sur Sourceforge. Je l'ai mis là-bas plutôt que de l'attacher à cause de sa taille.

Mis à part les changements kobject mentionnés ci-dessus, ceci devrait être le dernier ensemble de gros changements au code. Sauf si quelque chose m'a échappé, je crois que j'ai implémenté toutes les fonctionnalités donc on a besoin. A partir de maintenant, je travaillerai donc sur la mise à jour/amélioration de la documentation et le nettoyage et le commentaire du code, l'implémentation du support de kobject et peut-être aussi le support SMP. (ce qui devrait être un changement mineur).

ftp://oss.sgi.com/projects/xfs/download/patches/2.4.24-pre1.

Le 2.4.24-pre1 contient maintenant le gros du code XFS. Ces patches en morceau ne contiennent que des mises à jour XFS du 2.4.24-pre1, plus du code comme les ACL, DMAPI et KDB, si vous n'avez pas besoin de ces fonctionnalités et que vous ne voyez pas de bogues dans le code XFS du 2.4.24-pre1 vous n'avez alors pas besoin d'appliquer ces patches.

Voir le README dans chaque répertoire attentivement, le format du patch en morceaux a changé depuis quelques sorties du kernel. Toutes les questions traités par le README seront ignorées. Il y a même un 2.4.24/README pour les incurables impatients :).