Kernel Traffic #122 For 18 Jun 2001

There were 393 different contributors. 190 posted more than once. 152 posted last week too.

Derek Glidden à trouvé le moyen bloquer entièrement sa machine pendant plusieurs minutes. Il attribue ce problème à la version 2.4 de la VM, et ajoute qu'il lui semble subsister de sérieux problèmes avant que la 2.4 VM ne puisse être considérée comme stable. D'autres ont confirmé ce problème, puis il y eut une longue discussion. Miles Lane répondit alors, "Mike et les autres : Je suis fatigué de vos commentaires. Les développeurs qui travaillent actuellement sur la VM connaissent déjà le problème et explorent les solutions, de plus il existe déjà un correctif. Il semble clair que les remarques des personnes ayant eu des problèmes avec la nouvelle version du swap ont bien été entendues et que nous sommes en train de corriger le problème. Cela n'arrivera peut être pas aujourd'hui ou demain, mais bientôt. Que voulez-vous d'autre bordel !" Derek répondit que sont "post" d'origine n'était envoyé que dans le but de donner des informations supplémentaires, et Miles répond, "Actuellement, je pense que ton message d'origine était inutile. Cela a rappelé qu'il fallait réévaluer le design de la VM dans la série des 2.4, et mis en évidence certains bugs. Ce n'est pas à toi que je reproche d'avoir envoyé des remarques infâmantes, c'est aux personnes qui critiquent la gestion actuelle du swap sans donner aucune information pour aider les développeurs à remédier à la situation. Enfin, Merci d'avoir relancé le sujet. :-)"

Cela est certainement vrai, mais ce que tu as effectivement démontré c'est que "swapoff()" est extrèmement (et je veux dire _ETREMEMENT_) inefficient, à un point tel que l'on pourrait dire que s'en est bogué. C'est devenu pire dans la 2.4.x, pas tant à cause de problèmes dus au fonctionnement général de la VM, mais au fait de la plus grande persistence du swap dans les 2.4.x , cela démontre plus clairement la fondamentale inefficience de "swapoff()". Je ne pense pas que l'algorithme de swapoff() lui même ait changé, mais je pense que l'algorithme était déjà exponentiel (et à cause du swap persistent, l'algorithme suivant "n" est devenu beaucoup plus long). Cela n'est vraiment pas un problème lié au fonctionnement général de la VM. Va voir le fonctionnement de "try_to_unuse()". Je verrai bien quelqu'un pour examiner un peu plus swap-off. Eventuellement, par exemple, ce serait swap-off qui ne notifierai pas les pages de swap mortes (dead swap-pages), aussi, quelqu'un devrait vérifier qu'on n'éssaie pas de lire ou de "try_to_unuse()" les entrées de swap mortes. Cela mettrait en évidence le problème plus clairement.

Felix von Leitner nous rapporte que certaines des entêtes du noyau sont utilisées dans des librairies comme dietlibc. Les entêtes provoquent alors une exportation de la mauvaise API. Il donna un simple correctif, mais David S. Miller répondit, "N'utilisez pas les entêtes du noyau dans le "userspace" (espace réservé au utilisateurs contrairement à l'espace du noyau). Les entêtes du noyau et les entêtes des utilisateurs ont des espaces de nommage différents, et tu n'as montré qu'un seul des nombreux emplacements ou nous utilisons différents noms/structures/etc. pour la partie réseaux du noyau, comparé à ce que nécessite l'espace utilisateur." Felix von Leitner se lamente, "Quel choix ai-je ? Tout dupliquer et être désynchronisé lorsque les spécs changeront ?" Ce à quoi répondit Linus Torvalds :

Oui.

Et même de préférence - écrire des entêtes qui n'ont _que_ le minimum de code. Les entêtes du noyau sont pleines de code lié au noyau lui même, et cela veux-dire que si tu les utilises dans ton programme, ta compilation sera beaucoup plus lente que ce qu'elle auraît été.

En fait le noyau _refusera_ de suivre "l'espace de nommage" du jour de C89, C99, POSIX, BSD, Sus, GNU .. etc. Les entêtes du noyau ne sont pas faites pour être utilisées dans l'espace utilisateur, et elles ne suivront pas les règles strictes des espace de nommage dont certains standard s'amusent à perdre leur temps avec.

De toute manière, il n'y a pas tant de chose utile dans les entêtes du noyau. La plupart des infos (comme l'IPv6) sont définies ailleurs.

Peter J. Braam a rassemblé quelques rpm sur ext3, ils sont disponibles sur ftp://ftp.clusterfilesystem.com/pub/ext3. P.A.M. van Dam demanda ou il pourraît trouver les patchs de l'ext3 pour le noyau 2.4, Andrew Morton répondit:

Tous les détails sont sur: http://www.uow.edu.au/~andrewm/linux/ext3/

C'est actuellement du code bien stable. Les performances sont bonnes. Ce n'est pas vraiment testé avec LVM et le RAID. Cela peut bloquer avec une forte charge si vous utilisez les quotas.

Evitez tout ca et vous ne devrez pas avoir de problème.

Porter le code sur les -ac et corriger les problèmes des quotas est basiquement la prochaine activité de la liste.

Dawson Engler a écrit un utilitaire qui cherche les bogues dans le source. Il dit, "Vous pouvez utiliser ce "vérificateur" pour traquer si l'information provient d'une source non sécurisée (e.g., de copy_from_user) pour atteindre un endroit sécurisé (e.g, un index de tableau). Le principal facteur limitant de son efficacité est que nous n'avons qu'une notion incomplète de ce qui est sécurisé. Si quelqu'un a des suggestions à propos d'autres endroits ou il est dangeureux d'utiliser de mauvaises données, envoyez moi un mail svp." Il lista 15 bogues qu'il a découvert avec cet outil. Alan Cox a rapidement corrigé beaucoup d'entre eux, et Oliver Xymoron ajouta:

J'ai écrit quelque chose de similaire pour l'espace utilisateur (en passant par ld preload). La plupart de mes vérifications étaient autour des chaînes et d'être sûr que leur longueur était vérifiée afin d'éviter les débordements de pile, mais j'ai aussi vérifé les arguments d'"open", etc..

Dans ton cas, basiquement, toutes les destinations sont sécurisées à un certain niveau : l'espace utilisateur fournit des données à mettre quelque part. Au lieu de cela, tu peux vouloir vérifier que les données passent par des fonctions qui valident tout ca. Je parie que vous trouverez qu'environ 90% du code est couvert par quelques règles de sécurité communes .Et la plupart du code restant peut être réécrit pour pour l'être.

Eric S. Raymond a trouvé plusieurs nouveaux symboles de configuration dans le 2.4.6pre2 qui n'ont aucune documentation correspondante. Il les liste:

Maksim Krasnyanskiy reconnaît les symboles CONFIG_BLUEZ, ils font parti du système Bluetooth, et ajoute que Linux est le premier OS à avoir un support officiel pour le Bluetooth. Il décrit les options :

CONFIG_BLUEZ

Bluetooth est une technologie économe, à faible voltage, et sans fils (à court rayon d'action). Cela a été conçu afin de remplacer les cables et autres technologies à cour rayon d'action comme l'irDA (NDT: infra rouge). Bluetooth fonctionne dans une zone à rayon d'action personnel qui s'étend typiquement à 10 mètres. Plus d'informations à propos de Bluetooth peuvent être trouvées sur http://www.bluetooth.com

Linux Bluetooth est constitué de plusieurs couches :

HCI Core (périphérique et gestionnaire de connections, scheduler (NDT :ordonanceur/programmateur ?))
HCI Device drivers (interface avec le hardware)
L2CAP Module (protocole L2CAP)

Choisir Y ici pour activer le support Linux Bluetooth et compiler la couche HCI Core.

Pour utiliser le système Bluetooth, vous aurez besoin de plusieurs utilitaires dans l'espace utilisateur comme hciconfig et hcid. Ces utilitaires et mises à jours du module Bluetooth du noyau sont fournis dans le package BlueZ. Pour plus d'informations, voir http://bluez.sf.net.

Si vous voulez compiler le HCI Core en tant que module (hci.o) choisir Y ici.

Pas certain ? choisir N.

CONFIG_BLUEZ_L2CAP

L2CAP (Logical Link Control and Adaptation Protocol) fournit la couche transport en mode connecté ou non connecté, L2CAP est requis pour la plupart des applications utilisant Bluetooth.

Choisir Y ici pour compiler le support L2CAP dans le noyau ou choisir M pour le compiler en tant que module (l2cap.o).

Pas Sûr ? choisir M.

CONFIG_BLUEZ_HCIUART

Driver Bluetooth HCI UART. Ce driver est est requis si vous voulez utiliser des périphériques Bluetooth avec une interface série.

Choisir Y ici pour compiler le support des périphériques Bluetooth dans le noyau ou choisir M pour le compiler en tant que module (hci_uart.o).

Pas Sûr ? choisir M.

CONFIG_BLUEZ_HCIUSB

Driver Bluetooth HCI USB. Ce driver est requis si vous voulez utiliser Bluetooth avec des périphériques USB.

Choisir Y ici pour compiler le support des périphériques Bluetooth dans le noyau ou choisir M pour le compiler en tant que module (hci_usb.o).

Pas Sûr ? choisir M.

CONFIG_BLUEZ_HCIEMU

Driver de périphérique Virtual HCI Bluetooth Ce driver est requis si vous voulez utiliser le mode d'émulation logiciel HCI.

Choisir Y ici pour compiler le support Virtual HCI dans le noyau ou choisir M pour le compiler en tant que module (hci_usb.o).

Pas Sûr ? choisir M.

6. Bigmem Limitations / Limitations liées à l'option Bigmem (grande quantité de RAM)

Matt Nelson a un projet qui nécessite environ 6G de RAM sur Intel, et il voulait savoir s'il y a certains problèmes dont il doit se soucier. Doug McNaugth suggéra de prendre un Alpha, et expliqua, " Les pointeurs sur IA32 sont en 32 bits, aussi (autant que je le comprenne) chaque processus peut adresser un maximum de 4G. Tu devras allouer en plusieurs gros morceaux (en mémoire partagée ou par fichiers mappés, ainsi ils sont persistents) et les mapper au besoin." Mais il ajouta, "Si tu peux découper ta tache en plusieurs processus de telle manière qu'aucun d'eux n'ait besoin d'adresser plus de 4G, un IA32 fonctionnera bien." Plus tard Matt dit, " Merci à tous ceux qui ont répondu. Je n'ai jamais eu besoin d'autant de mémoire auparavant, et j'étais ignorant de l'implémentation du support des 64G sur IA32. Malheureusement, il n'y a pas assez de "trucs" pour mes besoins... maintenant je vais chercher un système SMP Alpha abordable..."

Craig Lyons de Promise Technology a envoyé un patch à Andre Hedrick, qui explique, "Dans l'arborescence 2.4 du noyau, il y a un support pour certains de nos produits (Ultra 66, Ultra 100, etc.). Comme vous le savez ou non, notre famille de contrôleurs Ultra (ceux qui sont des contrôleurs IDE standards sans le RAID) utilisent le même ASIC (NDT :Application-Specific Integrated Circuit /Circuit intégré spécifique) que sur notre contrôleur "FastTrak RAID". Le noyau 2.4 reconnaîtra notre famille de controleur "Ultra", mais il y a un problème, le FastTrak n'est pas reconnu en tant que FastTrak mais en tant que Ultra. Aussi, les disques ne sont pas reconnus en tant qu'un groupe de disques mais chaque disque est reconnu individuellement, les données des utilisateurs ne peuvent donc pas être accédées. Nous avons un correctif qui corrige le problème et nous espérons qu'il sera possible de le voir intégré dans le noyau. " Andre répondit, "Je ne veux pas de votre patch et n'en ai pas besoin. Je ne prendrais, ni n'accepterai ou approuverai du sale code (NDT: littéral) qui autorise un mauvais driver binaire qui ne peut contrôler son ISR et qui interfère de manière irresponsable avec le driver natif ATA. (NDT: dur dur !)"

Bert Hubert "Craig t'as contacté pour trouver ce qui n'allait pas et tu devais lui expliquer quels étaient les problèmes, et comment les résoudre. Linus accepterai un correctif écrit par Bill Gates s'il était bien codé et sous bonne license, aussi je ne verrai pas pourquoi Promise serait une exception. " Il expliqua aussi à Craig, "La procédure est de publier un correctif qui sera commenté et essayé par des personnes. Ils trouveront souvent que le code ne va pas ou qu'il n'est pas écrit de la manière qui convient aux développeurs du noyau. Sans aucune mauvaise intention, les développeurs du noyau préfèrent choisir eux mêmes. Ils te diront comment arranger ton code pour qu'il soit accepté. Ou même, les personnes voudront voir ce qu'il y a besoin modifier dans le correctif et feront les modifications elles-mêmes. " Mais Andre dit, "Non, je ne prendrais pas leur code, et ne n'appliquerai pas. Je ne veux même pas le regarder. Tout ce que je désire c'est que les règles des API soient respectées, ce qui est actuellement le cas. Nous n'avons pas besoin de leur driver." Rob Landley trouve, qu'en tant que développeur (mainteneur), Andre devrait être plus "ouvert" à propos de leur correctif. Andre répondit, "J'en ai vu une version et j'en suis tombé malade."

J'aimerai vous remercier publiquement pour être venu "à la table du GNU/GPL" avec une perspective ouverte. Après 90 minutes au téléphone, desquelles 45 minutes à expliquer les problèmes et les plaintes et 20 minutes sur les manières de travailler et sur les solutions dans un avenir proche et à plus long terme, à écouter vos questions et vos soucis entre chaque coupures que j'ai eu.

La prochaine conversation ne sera pas morcelée parce qu'elle se fera en personne ou la batterie de mon téléphone portable sera entièrement chargée.

Depuis que tu as dit "Je n'accèpterai pas le code de Promise", cela va mieux, et il reste du chemin à accomplir pout effacer les incompréhensions du passé de chaque côté.

Dans l'attente, de travailler avec Promise dans la compréhension et l'efficacité.

Répondez moi et corrigez tout ce qui aurait pu être mal compris ou vérifiez l'exactitude de mes dires. Ce sera une preuve de bonne fois pour tous ceux qui nous lisent ici.

Andre et moi avons eu une conversation sympatique au téléphone. Merci encore d'avoir pris le temps de parler avec moi et de m'offrir votre assistance. Comme je l'ai dit au téléphone nous engageons de larges ressources afin de sortir des drivers et des utilitaires pour nos produits sous Linux, incluant le FastTrak. Je sais que nous avons prévu de donner le source des cartes Ultra et SuperTrak mais je ne suis pas sûr que la manière dont nous avons procédé pour le FastTrak est ce que vous attendez. Comme je l'ai dit, je ne peux garantir ce dont je n'ai pas l'autorité, je transmettrai vos requêtes. J'essaierai d'être le pour-parler de Promise pour la communauté Linux, et le pour-parler de la communauté Linux chez Promise. Si l'entreprise fait des choix, je vous les ferai savoir, et peut-être me direz vous si nous nous sommes égarés ou non.

J'invite tout le monde à me contacter pour toutes suggestions et requêtes, quelles qu'elles soient. Comme je l'ai dit à Andre, je ne vous promet rien, car je ne décide de rien, mais je ferai tout ce que je peux pour vous aider. Je suis également à la recherche d'un contact technique avec qui je pourrai parler sans qu'il n'y ait a passer par un commercial qui ne comprendrai pas la moitié de ce que l'on dit ;).


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	5 Jun 2001 - 12 Jun 2001	(150 posts)	Statut de la Mémoire Virtuelle du Noyau 2.4
2.	8 Jun 2001	(6 posts)	Utiliser les entêtes du Noyau dans les Programmes
3.	8 Jun 2001 - 9 Jun 2001	(4 posts)	Statut de l'ext3
4.	8 Jun 2001 - 11 Jun 2001	(10 posts)	Traqueur Automatique de Bogues
5.	10 Jun 2001 - 13 Jun 2001	(4 posts)	Symbols de Configuration non Documentés dans 2.4.6pre2
6.	11 Jun 2001 - 13 Jun 2001	(9 posts)	Bigmem Limitations / Limitations liées à l'option Bigmem (grande quantité de RAM)
7.	12 Jun 2001 - 13 Jun 2001	(10 posts)	Commercial Patches / Patches commerciaux

Kernel Traffic #122 For 18 Jun 2001

By Zack Brown

Translated By: Nicolas Parpandet