Deux nouvelles versions de
FreeBSD viennent de sortir pour ce début d'année: la version 6.3 et la toute nouvelle version 7.0.
La version 6.3 sortie le 18 janvier est la dernière version de maintenance de la branche RELENG_6, cette mise à jour concerne :
- Correctifs de sécurité (bind, libarchive, random, openssl et libc)
- Amélioration de l'ACPI,
- Ajout de nombreux pilotes,
- Amélioration de freebsd-update qui permet maintenant, en plus des mises à jours de sécurité, de faire des montées de version.
- Réimplémentation de unionfs
Mais l'actualité majeure concerne la version 7.0 : en effet c'est la première version stable de la branche RELENG_7 qui apporte beaucoup de nouveautés. Parmi les fonctionnalités majeures apportées par cette version on peut noter :
- Amélioration du support des portables,
- Prise en charge de ZFS,
- Passage à GCC-4.2,
- Poursuite de la suppression du « Giant Lock »,
- Virtualisation complète de la pile réseau,
- Stabilisation et amélioration de l'ordonnanceur de processus « SCHED_ULE »,
- Gestion de la journalisation pour UFS,
- libthr devient la bibliothèque de gestions des threads par défaut.
NdM : Merci à FRLinux d'avoir également proposé une dépêche.
Après une très longue phase Beta/RC qui a permis de mettre et de corriger de très nombreux bugs, et plusieurs mois de retard, la très attendue version 7.0 vient de sortir. Beaucoup de développements à tous les niveaux :
Noyau et Espace Utilisateur
ZFS(1M) est le système de fichiers « révolutionnaire » de Sun. Le port de
ZFS sous FreeBSD, bien que considéré comme expérimental, est parfaitement fonctionnel, dotant ainsi le système d'un nouveau système de fichiers moderne très complet. FreeBSD est le second système d'exploitation libre à bénéficier du support pour ce système de fichier en natif (le premier étant OpenSolaris). La licence CDDL ne permettant pas l'inclusion dans le noyau, ZFS est donc disponible sous la forme de module, mais il peut quand même être utilisé pour la partition système. À noter que son support est considéré comme expérimental et qu'il n'est pas recommandé de l'utiliser sur des machines de production.
- Accès en lecture seule au système de fichiers XFS(5)
Après
reiserfs(5), xfs est le second système de fichiers « exotique » Linux a être implémenté en lecture seule sous FreeBSD. Étant sous licence GPL, il est incompatible avec une inclusion directe dans le noyau, le support est donc disponible sous la forme d'un module.
- Ajout expérimental du système de fichiers tmpfs(5)
tmpfs a été développé initialement sous
NetBSD à l'occasion du Google Summer of Code, celui-ci a ensuite été porté sous FreeBSD.
Le système de fichiers UFS profite d'une nouveauté basée sur l'infrastructure de stockage
GEOM. En effet FreeBSD 7.0 introduit l'outil gjournal qui offre enfin la journalisation au système de fichier UFS ainsi que potentiellement à n'importe quel Système de fichier tirant parti de l'infrastructure GEOM. Gjournal ne remplace par les
softupdates mais propose une alternative, il permet entre autre d'éviter de devoir faire une vérification du système de fichiers en tâche de fond après un incident.
- Stabilisation et amélioration de l'ordonnanceur de processus « SCHED_ULE »
L'ordonnanceur SCHED_ULE à été complètement revu, il est désormais beaucoup plus stable et plus réactif, en particulier quand le système est fortement chargé. Il fournit des performances nettement supérieures sur les systèmes multiprocesseurs mais aussi sur les système uniprocesseurs, et deviendra l'ordonnanceur par défaut pour la prochaine version de FreeBSD (7.1).
- Amélioration de la couche ACPI(4)
- Amélioration du support de l'ABI Linux(4) (linuxulator).
Le linuxulator permet désormais d'émuler certaines fonctions du noyau linux 2.6.16. Cette fonctionnalité n'est pas encore présente par défaut, mais peut être activée par
sysctl(8) : compat.linux.osrelease=2.6.16. Actuellement la compatibilité par défaut reste basée sur l'émulation de Linux 2.4.2.
- Ajout de nombreux pilotes audio avec notamment un module pour les cartes son se conformant aux spécifications HDA d'Intel
- Ajout de nombreux pilotes réseau (filaire et WIFI) ainsi que du support de la norme 802.11n
- KAME Ipsec est remplacé par FAST_IPSEC
- Poursuite de la suppression du « verrou géant » (aka "Giant Lock")
La majorité des composants importants sont désormais libres de "Giant Lock", plusieurs processus peuvent donc exécuter du code kernel sur plusieurs processeurs simultanément. La majorité des pilotes (notamment cartes réseaux et contrôleurs de disques) ainsi que les systèmes de fichiers virtuels basés sur pseudofs (procfs, linprocfs et linsysfs) sont concernés.
- L'allocateur de mémoire traditionnel (phkmalloc) est remplacé par le tout nouveau et très performant jemalloc. Ce dernier a été conçu spécialement pour les ordinateurs modernes ayant une grande quantité de mémoire et plusieurs processeurs et il fonctionne en espace utilisateur. Les performances étant intéressantes et la licence BSD étant permissive, les développeurs du navigateur Firefox 3 ont décidé d'utiliser jemalloc comme allocateur de mémoire par défaut.
- Amélioration de l'utilitaire freebsd-update(8)
La commande freebsd-update permettait jusque là de faire les mises à jours de sécurité relatives au noyau et à l'espace utilisateur de manière binaire. Désormais, elle permet aussi via l'option upgrade de faire des montées de version (en choisissant la release de destination avec l'option -r).
- Passage à la version 2 de libarchive(3), et ajout du support du format ar
Le but à terme est de recoder la totalité des GNU binutils sous license BSD afin de tirer profit de libelf. C'est le projet «
ElfToolChain » qui s'appuie sur libarchive et libelf.
- libthr(3) comme bibliothèque de threads par défaut
libthr est une implémentation 1:1 des threads POSIX, apportant un gain de rapidité conséquent pour toutes les applications utilisant des threads (notamment
MySQL) par rapport à l'implémentation précédente en N:M. Un
comparatif des performances entre les différentes versions de FreeBSD ainsi qu'avec d'autres systèmes d'exploitations est disponible avec de nombreuses explications techniques.
- Agrégation des interfaces réseaux
Le code permettant d'agréger des interfaces réseaux pour augmenter le débit et améliorer la tolérance aux pannes a été intégré à FreeBSD 7.0. Cet outil
trunk a été importé directement du système d'exploitation OpenBSD.
Toujours dans le domaine des réseaux il est maintenant possible d'utiliser certaines cartes accélératrices de type TSO (
TCP/IP segmentation offload) et LRO (
Large Receive Offload) au lieu de faire ces opérations uniquement avec le processeur central.
- Suppression de l'architecture Alpha
L'architecture Alpha a été abandonnée dans branche RELENG_7 et CURRENT, en revanche le support continue pour les branches RELENG_5 et RELENG_6
- Mise à jours de nombreux logiciels en espace utilisateur :
- bind 9.4.2
- gcc 4.2.1
- netcat (passage à la version d'OpenBSD 4.1)
- ncurses 5.6 avec support de l'Unicode
- pf(4) (passage à la version d'OpenBSD 4.1)
Merci à tout ceux qui ont contribué à la rédaction de cet article sur le wiki et merci à baud123 pour son wiki.
Aller plus loin
# Interressant
Posté par reno . Évalué à 3.
Sinon, l'interview m'a rendu curieux à propos de SCTP que je ne connaissais pas, et c'est vrai que ce "super-TCP" a l'air interressant..
[^] # Re: Interressant
Posté par Samuel Thibault (site web personnel) . Évalué à 2.
Heu, je ne comprends pas. Sous Linux les deux librairies de threads couramment utilisées ont été LinuxThread et NPTL, toutes deux 1:1 (même si dans NPTL une grosse partie du boulot est déléguée au noyau)...
[^] # Re: Interressant
Posté par Samuel Thibault (site web personnel) . Évalué à 1.
[^] # Re: Interressant
Posté par reno . Évalué à 2.
En fait je pensais a la librairie M:N faite par IBM qui était prévue a un moment comme successeur de LinuxThread, mais c'est vrai elle n'a pas été réellement utilisée.
[^] # Re: Interressant
Posté par Samuel Thibault (site web personnel) . Évalué à 1.
En fait, Drepper avait envisagé du N:M pour la NPTL, et vu la complexité, a laissé tomber, considérant que les appels système, de nos jours, c'est peanut.
# Pas pu attendre vendredi....
Posté par patrick_g (site web personnel) . Évalué à 10.
Un certain Warner Losh est employé par sa boite pour bosser sur la problématique de l'embarqué (plus spécifiquement la compatibilité avec les processeurs ARM ou MIPS) et il dit ceci (traduction perso) :
"La montée en puissance de FreeBSD dans le monde de l'embarqué se poursuivra. L'application de plus en plus agressive de la GPL par le Software Freedom Law Center et d'autres a créé une demande pour des logiciels avec une licence qu'il est plus facile de respecter".
Je dois dire que j'ai été choqué quand j'ai lu cette déclaration.
La GPL est souvent violée par les vendeurs de matériel embarqué et la liberté des utilisateurs est foulée aux pieds. Le Software Freedom Law Center se bat pour le respect de la licence et pour que la liberté des utilisateurs de logiciels libres ne soit pas anéantie par des firmes prédatrices.
Et que dit ce monsieur Losh ? Que ce combat pour le respect de la GPL et pour la liberté des utilisateurs est une opportunité pour FreeBSD !
Les firmes voulant nier la liberté de l'utilisateur (en lui vendant un matériel sans donner le code et donc en empêchant le partage) vont se tourner vers FreeBSD. Avant elles violaient tranquillement la GPL mais le combat opiniatre du Software Freedom Law Center a rendu cela difficile et cela ouvre un boulevard pour FreeBSD.
Warner Losh est donc parfaitement conscient que son travail sur l'embarqué est destiné quasi-exclusivement à des firmes non éthiques. Il est parfaitement conscient que le matériel vendu par ces firmes sera une "boite noire" et que l'utilisateur sera verouillé, enfermé, sans possibilité de lire ou de partager le code.
Mais il s'en fout. Tout ce qu'il voit c'est qu'il est payé pour faire ça et tant pis pour les autres. Tout ce qu'il voit c'est que la lutte pour le respect de la liberté de l'utilisateur a "créé une demande" pour FreeBSD dont il peut profiter.
PS : Ce post évoque juste une déclaration d'un dev dans une interview et il n'a rien à voir avec la qualité de FreeBSD. Ce n'est pas une attaque contre cet OS. Je l'ai installé la semaine dernière sur mon second laptop, juste pour voir, et ça à l'air très bien (mais j'ai pas de son pour l'instant). Merci donc de ne pas m'accuser d'être un anti-BSD fanatique.
[^] # Re: Pas pu attendre vendredi....
Posté par Bapt (site web personnel) . Évalué à 10.
Après il s'avère que à chaque fois ou presque (le ou presque est parce que je ne connais pas l'ensemble des boites qui utilisent du BSD et qu'il y en a certainement des plus connes que d'autres) que FreeBSD est utilisé dans un appliance la boite qui gère l'appliance à reversé son code dans le cvs de FreeBSD car il est plus facile de maintenir le code upstream que de maintenir ses patchs dans son coin.
L'exemple récent est cisco qui sponsorise le port de DTrace sous FreeBSD, celui-ci est prêt, disponible et devrait faire son entrée rapidement dans la branche CURRENT et peut-être même 7-STABLE. Porté FreeBSD sur de l'embarqué n'est pas pour faire du proprio mais pour le rendre dispo sur des plateformes qui ont de plus en plus le vent en poupe, le libre (en tout cas FreeBSD) verra rapidement des retours des boîtes qui l'utilisent.
Après celle qui ne joue pas le jeu se retrouvent la plupart du temps rapidement à la rue car gérer sa propres version du sources FreeBSD (ou tout autre projet opensource conséquent) n'est pas trivial.
[^] # Re: Pas pu attendre vendredi....
Posté par patrick_g (site web personnel) . Évalué à 9.
Ok bonne nouvelle alors.
Finalement si ces boites évitent maintenant la GPL et ont basculé vers des logiciels "avec une licence qu'il est plus facile de respecter" c'est juste qu'elles ont considéré qu'il était trop dur de mettre un tar.gz de code source sur leur site web.
Ou alors elles payent leur bande passante au ko et le fait de mettre les sources en download leur couterait des milliards de dollars ?
Ou bien ce serait qu'elles n'ont pas la compétence pour configurer un serveur FTP pour permettre l'accès aux tar.gz des sources ?
Enfin quoi qu'il en soit c'est bon de savoir que le switch vers cette fameuse licence facile à respecter ce n'est pas pour faire du proprio et cela ne va pas du tout impacter la liberté des utilisateurs. J'en ai chaud au coeur.
[^] # Re: Pas pu attendre vendredi....
Posté par Bapt (site web personnel) . Évalué à 8.
Exmple : je voulais développement une application Web je me suis dit tiens je vais faire du Witty : fastcgi, c++ et web 2.0, bref des trucs bien. Problème la lib est en GPL, donc si je me link avec cette lib je ne serais plus libre de mettre la licence qui me plait pour mon code (je voulais faire mon code sous licence ISC)
Autre cas de figure, je voulais me faire un super cli qu'il est beau pour une appli et propre sous licence libre (ISC aussi), je me dit cool readline ça va être sympas de l'utiliser bah non pas le droit sinon mon code doit être sous GPL, moi je voulais ISC, donc j'ai encore fui la GPL pour choisit libedit à la place.
Dans beaucoup de cas des gens fuient la GPL alors qu'ils veulent du libre. Maintenant il ne faut pas être aveugle, il y a aussi des cons qui vont en profiter pour faire du proprio, mais ce n'est pas pour cela que la licence BSD et ses copines ISC, MIT, sont faites...
[^] # Re: Pas pu attendre vendredi....
Posté par psychoslave__ (site web personnel) . Évalué à 6.
En fait d'après ce que je lis sur le site du projet GNU[1], ISC est compatible avec la GPL 2 et 3.
Après, je comprends aussi ceux qui veulent faire du libre et être compatible un max pour être réutilisé partout (coder bien et une fois pour toute).
[1] http://www.gnu.org/licenses/quick-guide-gplv3.html
[^] # Re: Pas pu attendre vendredi....
Posté par sobek . Évalué à 10.
De même, tu peux inclure du code ISC dans du code GPL, mais pas l'inverse. C'est illustré dans le document que tu indiques.
En gros, la licence GPL permet de piocher dans nombre de projets libres sans avoir à redonner en échange si l'autre à une vision du libre qui n'est pas GPL (c'est uniquement suivant le bon vouloir de l'auter, s'il publie sa modification en licence multiple ou non...).
Personnellement, la GPL est une license que j'évite au maximum (et encore plus des "version n ou ultérieur" sans savoir ce que l'avenir réserve) pour ce que je produis, parce que pour moi si la liberté des utilisateurs est importante, la liberté du point de vu programmeur l'est elle aussi.
[^] # Re: Pas pu attendre vendredi....
Posté par BAud (site web personnel) . Évalué à 5.
euh si, tu as tout à fait les droits de faire les deux, simplement faut assumer : passer ton programme binaire en GPL pour la distribution (mais le code source, non lié, peut rester sous la double licence GPL et ISC, ce qui fait que ceux qui utiliseront le code de ton programme mais sans le lier à une bibliothèque GPL pourront le distribuer sous licence ISC).
Tu gardes l'entière propriété de ton programme (des lignes que tu as écrites en tout cas), c'est bien toi qui choisit la licence de ton code source, ce n'est qu'au moment où tu distribues un programme que les contraintes de licences doivent s'appliquer et - effectivement à ce moment - du fait que tu as choisi de reprendre du code GPL, c'est la GPL qui s'applique : le choix de la GPL est bien le tiens, rien ne t'empêche de réécrire ce dont tu as besoin ou d'être plus pragmatique et de distribuer en GPL (de toute façon tu souhaitais le distribuer aussi ton source non ?).
[^] # Re: Pas pu attendre vendredi....
Posté par sobek . Évalué à 4.
C'est bien ce que je voulais dire : tu ne peux faire l'intégration de code GPL dans un programme libre sans devoir passer tout ou partie de ce programme en GPL (au moins le binaire dans ce cas précis). C'est ce que certains appèlent le coté "viral" de la GPL, même vis-à-vis du libre.
ce n'est qu'au moment où tu distribues un programme que les contraintes
En général, si je fait du libre et que je me pose des questions de licenses c'est que je ne compte pas garder ces modifications pour moi, même si la version modifiée n'est pas forcement à diffusion très large.
tu as choisi de reprendre du code GPL, c'est la GPL qui s'applique
On est d'accord : à partir du moment ou une ligne de code GPL est intégré, il est automatiquement "contaminé" et devient à son tour loup-garoup^W^W GPL, quelque soit le choix de license de l'auteur initial.
Ainsi, si on a deux programmes proches, l'un sous license GPL et l'autre sous license BSD.
Si un dév du premier prend un bout de code du second pour améliorer son programme, il est libre de le faire sans problème (et c'est très bien).
En revanche si un dév du second veut s'inspirer du premier pour améliorer son programme alors il n'a qu'une solution : mettre son programme sous GPL.
C'est ce partage à sens unique dans la vision du libre suivant la FSF qui me gène parfois un peu...
d'être plus pragmatique et de distribuer en GPL (de toute façon tu souhaitais le distribuer aussi ton source non ?).
Oui, je voulais le distribuer, mais en lui concervant sa license d'origine.
Pour moi, le monde du logiciel libre ne se limite pas à linux et à la GPL, fort heureusement.
[^] # Re: Pas pu attendre vendredi....
Posté par benoar . Évalué à 4.
Je vois donc cela plutot comme ca : quand on fait un assemblage GPL+BSD, le plus "fort" (oui, on pourrait dire "contraignant") l'emporte pour le projet résultant (i.e. le code qu'on écrit a partir de l'ensemble GPL+BSD de base).
[^] # Re: Pas pu attendre vendredi....
Posté par tuXico . Évalué à 8.
On est d'accord : à partir du moment ou une ligne de code GPL est intégré, il est automatiquement "contaminé" et devient à son tour loup-garoup^W^W GPL, quelque soit le choix de license de l'auteur initial.
Ainsi, si on a deux programmes proches, l'un sous license GPL et l'autre sous license BSD.
Si un dév du premier prend un bout de code du second pour améliorer son programme, il est libre de le faire sans problème (et c'est très bien).
En revanche si un dév du second veut s'inspirer du premier pour améliorer son programme alors il n'a qu'une solution : mettre son programme sous GPL.
C'est ce partage à sens unique dans la vision du libre suivant la FSF qui me gène parfois un peu...
Rien de neuf sous le soleil.
Beaucoup de gens s'intéressent de la manière qui suit aux licences :
J'aime Linux donc la licence de Linux est la bonne(tm)
Du coup, quelle utilité à faire remarquer les différences ?
ça me rapelle le jour où je discutais licence avec mon ex colloc et un pote de travail m'a demandé la différence. Après une explication de moinS de 2 minutes, il était suffisament expert pour littéralement m'hurler après. (mais on s'est repris, on s'aime toujours bien :p)
ça ne veut pas dire que tout le monde réagit aussi mal, ça veut dire que ce sujet est stérile surtout par la voie électronique. Si on dit que la GPL est moinS libre ou ouverte que la BSD, la grosse majorité des gens hurle. Or ils ont tort : on peut dire que la GPL respecte plus la liberté du end user si la formulation fait plus plaisir mais clairement la GPL est une restriction de la BSD. (ce qui ne remet pas en cause les qualités de l'une ou de l'autre)
Politico-philosophiquement, j'ai l'impression que c'est un peu un débat communisme/anarchisme. Les coco : regardez, ça, c'est la liberté dont vous avez besoin, c'est celle qu'il vous faut, c'est celle à laquelle vous avez droit, dans notre bonté, on vous l'impose. Les anar : tiens prends ça, c'est tellement libre que c'est même pas libre si Tu veux.
Perso, je respecte le droit à faire des conneries (passer du libre en non libre) des gens parceque je déteste les gens qui m'expliquent ce qui est le mieux pour moi.
[^] # Re: Pas pu attendre vendredi....
Posté par BAud (site web personnel) . Évalué à 4.
c'est bien ce que je dis : toi comme moi nous attachons au code source, tu gardes l'entière liberté du code et tu peux le distribuer sous ISC. Ce n'est qu'à partir du moment où tu distribues un binaire (pour un utilisateur) que tu le distribues en GPL, ce n'est pas très gênant ; ton code reste bien disponible pour tout le monde en ISC, libre à quelqu'un de faire l'effort de réécrire ce qui est GPL pour distribuer l'ensemble sous une licence qui (vous) convient plus. À la base si je veux exagérer c'est toi qui est une sale feignasse de vouloir reprendre du code GPL, à toi d'assumer ton choix et de ne pas accuser la GPL.
Franchement, la GPL permet d'assurer ce que nous voulons toi comme moi : garantir que le code avec ses évolution est reversé (ça ne coûte pas très cher de mettre le code en ligne hein de nos jours). La BSD est pragmatique et fait confiance (ce que j'aurais tendance à faire : sur le long terme il vaut mieux reverser le code, tout le monde est gagnant), la GPL aussi est pragmatique et incite à directement penser à fournir le code.
Concrètement, si je devais penser à bosser dans l'embarqué, clairement je choisis un kernel Linux : au moins le kernel qui m'est fourni en binaire est utilisable, j'ai toute légitimité à demander le code sans plus d'explication (c'est plus efficace pour tout le monde de suivre la licence), pour un kernel BSD c'est pareil : tout le monde y gagne à s'échanger le code pour l'améliorer (ce qui se passe légitimement en entreprise grâce aux accords croisés qui sont passés). Simplement avec la GPL, la (bonne) décision doit être prise dès le début (il faut réfléchir), avec la BSD la démarche va de soi pour mieux travailler et tout le monde est content (le fournisseur fout rien et automagiquement son code devient de meilleur qualité pour ses autres clients).
Tous ceux qui ont deux doigts de jugeotte tiennent le même raisonnement, ce qui a levé tous mes soucis à fournir du code sous double licence BSD+GPL 2+ pour contenter les meilleurs des deux mondes.
[^] # Re: Pas pu attendre vendredi....
Posté par tuXico . Évalué à 1.
Attention, ça va ressembler à un troll :
ça ressemble à une bonne idée et pourtant, on sait ce qu'il se passe dans ce genre de cas...
[^] # Re: Pas pu attendre vendredi....
Posté par vosgien_ . Évalué à 2.
Attention : si l'auteur du code ISC n'a publié son code que sous licence ISC, ce code peut être inclu dans du code sous GPL, à condition que le code sous licence ISC *reste* sous licence ISC.
C'est à dire que quelqu'un qui inclut du code ISC dans un fichier source sous GPL doit ajouter la licence ISC pour le code ajouté. Ne pas le faire est *illégale* : cela correspondrait à changer la licence originale du code sans accord de l'auteur, ce qui est interdit par la loi.
La licence ISC est très claire :
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.[^] # Re: Pas pu attendre vendredi....
Posté par sobek . Évalué à 3.
[^] # Re: Pas pu attendre vendredi....
Posté par kemar . Évalué à -3.
[^] # Re: Pas pu attendre vendredi....
Posté par TeXitoi (site web personnel) . Évalué à 4.
[^] # Re: Pas pu attendre vendredi....
Posté par vosgien_ . Évalué à 2.
Une licence de type ISC/BSD n'impose pas cette contrainte : le code dérivant d'un projet sous licence ISC/BSD peut être placé sous n'importe quelle licence qu'à choisi l'auteur, y compris propriétaire.
Par contre, ce qui est interdit par la loi, c'est de changer une licence sans l'accord de l'auteur. Quelque soit la licence, il est interdit de prendre du code sous une certaine licence et de le "relicencer" sous une autre licence lors de son inclusion à un projet.
[^] # Re: Pas pu attendre vendredi....
Posté par BAud (site web personnel) . Évalué à 1.
ce serait plutôt un vaccin ou comme disent certains une licence héréditaire : le binaire distribué l'est sous GPL, le code qui en est issu reste sous la licence choisie par leurs auteurs respectifs.
Pour le développeur rien ne change, son code reste sous la licence qu'il a choisie. C'est pour celui qui distribue un binaire qu'il est déconseillé de faire du proprio (dans tous les cas, BSD comme GPL, in fine pour l'un, a priori pour l'autre).
La loi est la même en ce qui concerne la BSD et la GPL effectivement, ce que ne manquent pas de rappeller ni Theo de Raadt, ni Linus, ni Stallman, à raison pour chacun.
[^] # Re: Pas pu attendre vendredi....
Posté par Pierre Jarillon (site web personnel) . Évalué à -1.
Je compare parfois le code sous licence BSD à la production des mulets du Poitou (je suis né à Melle, la capitale de leur élevage). Le mulet est fort comme un cheval et intelligent comme un âne du Poitou mais il est stérile.
[^] # Re: Pas pu attendre vendredi....
Posté par Gniarf . Évalué à 4.
[^] # Re: Pas pu attendre vendredi....
Posté par vjm . Évalué à 10.
Et en plus de DTrace, toute la pile SCTP de FreeBSD, considérée comme l'implémentation de référence du protocole (par l'auteur de la RFC qui est aussi l'auteur de l'implémentation), a été écrit par Randall Stewart qui bosse chez Cisco.
Bref, ils peuvent utiliser FreeBSD comme bon leur semble et ils font quand même des contributions très importantes à FreeBSD.
PS : les BSDistes ne sont pas des violeurs d'enfant, épargnez-nous la rétention de sûreté et vos chocs émotionnels traumatisant.
[^] # Re: Pas pu attendre vendredi....
Posté par IsNotGood . Évalué à -7.
Et la liberté de l'utilisateur ?
Ah oui, downloader FreeBSD. Ben il peut aussi downloader IE.
> Porté FreeBSD sur de l'embarqué n'est pas pour faire du proprio
Si ce n'est pas pour faire du proprio, prend la GPL.
> le libre (en tout cas FreeBSD) verra rapidement des retours des boîtes qui l'utilisent.
Si c'est aussi pour avoir des retours des boîtes qui l'utilisent, prend du GPL.
C'est l'ambiguïté, pour ne pas dire mauvaise foi, classique des fans BSD :
- On veux la même chose que la GPL, mais avant tout il faut surtout permettre de la contourner.
- On ne veut pas des brevets, mais on veut avant tout les permettres.
- On ne veut pas de la tivolisation, mais on veut avant le permettre.
- On veut la libertité de l'utilisateur (modifier, etc), mais on veut avant tout permettre de la lui retirer.
- Etc.
[^] # Re: Pas pu attendre vendredi....
Posté par gaston . Évalué à 6.
C'est l'ambiguïté, pour ne pas dire mauvaise foi, classique des fans BSD :
- On veux la même chose que la GPL, mais avant tout il faut surtout permettre de la contourner.
- On ne veut pas des brevets, mais on veut avant tout les permettres.
- On ne veut pas de la tivolisation, mais on veut avant le permettre.
- On veut la libertité de l'utilisateur (modifier, etc), mais on veut avant tout permettre de la lui retirer.
tivoisation - les permettre - avant 'tout' - liberté. Quand tu t'énerves devant ton clavier ca se voit au nombre de fautes...
Encore une fois, tu montre ce qu'est un fervent défenseur de la GPL stallman-style. Borné, tu n'imagine même pas que des gens puissent avoir une autre vision que TOI de la liberté. Vraiment ridicule.
La GPL me retire des libertés en tant que développeur. Et ca tu ne peux pas le nier.
[^] # Re: Pas pu attendre vendredi....
Posté par TeXitoi (site web personnel) . Évalué à 7.
Enfin, même RMS est pas aussi extremiste : il dit que le BSD c'est libre et qu'on peut utiliser sans problème, et également contribuer. Il ne conseille juste pas cette licence pour démarrer un nouveau projet libre.
[^] # Re: Pas pu attendre vendredi....
Posté par tuXico . Évalué à 4.
Sur ce site, l' "ambiguité classique" de la connerie commence par "Posté par IsNotGood "
[^] # Re: Pas pu attendre vendredi....
Posté par gaston . Évalué à 8.
Vous préférez quoi, que les vendeurs de matos continuent à violer la GPL, ou qu'ils se mettent à utiliser du BSD en respectant la licence ? (l'hypothèse "peu importe la licence pourvu qu'ils mettent à disposition les sources et les docs" est volontairement mise de coté..)
[^] # Re: Pas pu attendre vendredi....
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Bah oui, et alors ? Si les boites qui ne respectent pas la GPL (pour diverses raisons) se font taper sur les doigts sans arret, ca parait logique qu'elles essayent de voir ailleurs, et la BSD est une licence qui correspond pile poil à leurs besoins. Je vois pas de quoi s'indigner là dessus.
>Warner Losh est donc parfaitement conscient que son travail sur l'embarqué est destiné quasi-exclusivement à des firmes non éthiques. Il est parfaitement conscient que le matériel vendu par ces firmes sera une "boite noire" et que l'utilisateur sera verouillé, enfermé, sans possibilité de lire ou de partager le code.
Et alors ? Où est le problème ? La licence BSD le permet à ce que je sache ? Non ?
Je ne comprend pas ton indignation. Si ce monsieur bosse avec une licence BSD, c'est bien qu'il accepte que ce qu'il code/ce qui est dans FreeBSD soit embarqué dans des boites noires... Que ça te plaise ou non, c'est comme ça.
[^] # Re: Pas pu attendre vendredi....
Posté par patrick_g (site web personnel) . Évalué à 8.
Je ne comprend pas ton indignation.
Je fais une différence entre le dev qui code simplement un truc sous licence BSD et le dev qui se réjouit que le combat pour faire respecter les libertés des utilisateurs va en fait ouvrir un boulevard pour le code BSD.
Ce n'est pas la même chose et n'importe qui un tant soit peu honnête en conviendra.
[^] # Re: Pas pu attendre vendredi....
Posté par vjm . Évalué à 6.
[^] # manichéisme
Posté par Kerro . Évalué à 10.
Richard STALLMAN est une personne tout à fait respectable qui fait un travail extraordinaire. En plus il a une bonne bouille (c'est un bon argument pour les politiciens, pourquoi pas pour lui ?). Mais d'autres personnes, ayant des idées différentes, sont tout aussi efficaces en ayant des méthodes qui ne sont pas les mêmes.
[^] # Re: Pas pu attendre vendredi....
Posté par campagnard . Évalué à 2.
(désolé)
[^] # Re: Pas pu attendre vendredi....
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
En fait ce qui t'emmerde, (et qui transpire dans tes propos) c'est que ça puisse gêner la progression de la GPL. Et je ne vois donc pas en quoi il faut s'indigner de propos tout à fait cohérent de la part "de l'autre camp".
[^] # Re: Pas pu attendre vendredi....
Posté par porki . Évalué à 9.
[^] # Re: Pas pu attendre vendredi....
Posté par psychoslave__ (site web personnel) . Évalué à 4.
Bon, finalement on s'en fou un peu de tout ça, parceque vim est mieux que emacs, c'est sûr.
[^] # Re: Pas pu attendre vendredi....
Posté par briaeros007 . Évalué à 2.
[^] # Re: Pas pu attendre vendredi....
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
Il ne se réjouit pas que le code (ou ses utilisateurs ?) soit « enfermé » car il sait que le code placé sous une licence BSD reste libre quoi qu'il arrive, et il est bien placé pour savoir que de nombreuses entreprises utilisatrices de code BSD contribuent d'une façon ou d'une autre en retour.
[^] # Re: Pas pu attendre vendredi....
Posté par briaeros007 . Évalué à 1.
ca fait une belle jambe a celui qui utilise de l'embarqué issu de bsd , mais qui n'a pas le droit de le modifier de savoir "qu'un autre produit lui tu peux le modifier".
il est bien placé pour savoir que de nombreuses entreprises utilisatrices de code BSD contribuent d'une façon ou d'une autre en retour.
Ca semble pas être l'avis de theo de raadt.
[^] # Re: Pas pu attendre vendredi....
Posté par reno . Évalué à 4.
Et bien, il n'a qu'a voter avec son portefeuille et ne pas l'acheter ce produit s'il est "tivo-iser" et que ça ne lui plais pas..
[^] # Re: Pas pu attendre vendredi....
Posté par briaeros007 . Évalué à 0.
Parce que quand tu achete une appliance avec seul 3 constructeur qui le font, et que le client /patron _veut_ une appliance, tu fait quoi ? Tu la recode entièrement ?
[^] # Re: Pas pu attendre vendredi....
Posté par Gniarf . Évalué à 3.
[^] # Re: Pas pu attendre vendredi....
Posté par briaeros007 . Évalué à 1.
[^] # Re: Pas pu attendre vendredi....
Posté par Anonyme . Évalué à 10.
A chacun sa conviction sur le libre et ses licences. C'est aussi ça le libre.
[^] # Re: Pas pu attendre vendredi....
Posté par briaeros007 . Évalué à 2.
Ce qu'"on" (j'ai toujours eu du mal avec les "on" global) c'est deux choses :
Respecter le droit d'auteur. Les boites qui font du proprio sont les première a raler comme des putois quand on respecte pas la leur. Il serait normal en retour qu'elles respectent celle des autres.
Avoir plus de liberté pour les UTILISATEURS, et pas pour les boites qui s'en foutent du droit d'auteur et ne veulent surtout pas que les utilisateurs puissent faire quoi que ce soit.
[^] # Re: Pas pu attendre vendredi....
Posté par Bapt (site web personnel) . Évalué à -1.
Franchement qu'est ce qu'on s'en fout, on est pas pour parler des humeurs des devs ou pour parler d'un OS libre majeur, et de ses dernières versions.
Bordel je viens pas pourrir tes journaux (de qualité, je le reconnais) en te disant merde Linus il a péter trop fort, ou Alan Cox a dit blah ou blah.
Fait un journal pour parler de ton mécontentement de ce qu'à pu dire le dev, envoie lui un mail, mais ça n'a rien a faire ici.
J'ai eu la bêtise de réponde 2 fois précédemment, je m'arrête là.
Laissons le troll BSD/GPL de côté et parlons de FreeBSD et des ces releases.
[^] # Re: Pas pu attendre vendredi....
Posté par Julien Fontanet (site web personnel) . Évalué à 10.
patrick_g exprime juste son point de vu et son ressenti par rapport à ce qu'il a lu, rien de choquant.
Après que ça parte un peu en troll c'est loin d'être dramatique, faut pas exagérer.
[^] # Re: Pas pu attendre vendredi....
Posté par psychoslave__ (site web personnel) . Évalué à 4.
Au fait ils utilisent quoi comme éditeur de texte les développeurs de *BSD? :D
[^] # Re: Pas pu attendre vendredi....
Posté par kowalsky . Évalué à 10.
Ils sont en accord total avec la machine, et par
amour, elle modifie elle même les fichiers, comme
si le développeur l'avait fait lui même.
Les machines et les femmes aiment les développeurs BSD.
[^] # Re: Pas pu attendre vendredi....
Posté par tuXico . Évalué à 2.
mais les développeurs BSD aiment surtout les machines :-D (mux si Tu m'entends...)
[^] # Re: Pas pu attendre vendredi....
Posté par patrick_g (site web personnel) . Évalué à 6.
Bon désolé si tu a le sentiment que cette discussion "pourrit la news" (je ne vois pas trop en quoi des commentaires changent quoi que ce soit au texte de la dépêche mais bon). Je te présente mes excuses.
>>> je me suis fait chié a rédigé une news le plus complet possible, à la faire compléter/corriger par un maximum de gens
Dont moi.
>>> Franchement qu'est ce qu'on s'en fout, on est pas pour parler des humeurs des devs
Le lien vers l'interview d'ONLamp faisant partie de la news j'ai pensé qu'il était intéressant de parler d'une partie son contenu.
>>> Laissons le troll BSD/GPL de côté et parlons de FreeBSD et des ces releases.
OK. Le nouveau jemalloc tourne en espace utilisateur et quand j'ai lu ça cela m'a assez surpris. Est-ce que l'ancien phkmalloc tournait en mode noyau ou en userland ? Est-ce que le fait que jemalloc tourne en userland n'induit pas des coûts lors des changements de contexte ?
[^] # Re: Pas pu attendre vendredi....
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 8.
[^] # Re: Pas pu attendre vendredi....
Posté par karmatronic . Évalué à 6.
je ne vois pas l'intérêt dans tous les cas de venir pourrir un troll avec ce genre de remarques patrick_g , j entends bien que tu me presentes á moi aussi tes excuses :)
[^] # Re: Pas pu attendre vendredi....
Posté par nullisimo . Évalué à 3.
malloc()a toujours ete userland. Ca se base historiquement sur (s)brk(), et de nos jours (s)brk() et mmap() ou seulement mmap().
[^] # Re: Pas pu attendre vendredi....
Posté par patrick_g (site web personnel) . Évalué à 3.
Humm....alors pourquoi dans le lien sur les nouveautés de FreBSD 7 ( http://ivoras.sharanet.org/freebsd/freebsd7.html ) il se sent obligé de dire "a new userland memory allocator was created, named jemalloc" ?
Pourquoi parler d'un "new userland memory allocator" si cela a toujours tourné en userland ?
Moi j'avais interprété cela comme voulant dire que l'ancien n'était pas en mémoire utilisateur.
[^] # Re: Pas pu attendre vendredi....
Posté par nullisimo . Évalué à 8.
Si il fait la distinction, c'est que contrairement a linux qui utilise kmalloc() pour l'allocation memoire kernelland, FreeBSD a aussi un malloc(9). La section '9' sous FreeBSD contient les page du developpeur kernel.
Dans son esprit la disctinction est naturelle, mais chez 99% des gens au moins ce n'est pas si evident ;-)
[^] # Re: Pas pu attendre vendredi....
Posté par nullisimo . Évalué à 6.
[^] # Re: Pas pu attendre vendredi....
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: Pas pu attendre vendredi....
Posté par Psychofox (Mastodon) . Évalué à -1.
Moi j'avais interprété cela comme voulant dire que l'ancien n'était pas en mémoire utilisateur.
La question n'est pas Pourquoi parler d'un "new userland memory allocator" mais Pourquoi j'ai interprété cette phrase n'importe comment.
Cette phrase veut dire ce qu'elle veut dire et rien de plus. Il y'a un nouvel (un de plus) allocateur de mémoire qui tourne en espace utilisateur.
[^] # Re: Pas pu attendre vendredi....
Posté par kowalsky . Évalué à 2.
http://linuxfr.org/~kowalsky/26087.html
Comment ne parler que d'un truc bidon alors qu'il y a plein de
choses à dire ?!!
[^] # Re: Pas pu attendre vendredi....
Posté par FRLinux (site web personnel) . Évalué à 1.
Totalement d'accord, et bravo pour la précisio de ta news, la mienne contenait moins d'informations :)
[^] # Re: Pas pu attendre vendredi....
Posté par imalip . Évalué à 6.
Warner Losh est donc parfaitement conscient que son travail sur l'embarqué est destiné quasi-exclusivement à des firmes non éthiques. Il est parfaitement conscient que le matériel vendu par ces firmes sera une "boite noire" et que l'utilisateur sera verouillé, enfermé, sans possibilité de lire ou de partager le code.Le probleme avec la GPL, c'est que pour la respecter, fournir les sources ne suffit pas. Si ton produit fini contient a la fois du GPL et du non-compatible GPL, que tu distribues les sources de tout ce petit monde et qu'on te colle un proces sur le dos pour non respect de la licence, meme si c'est a tord, tu va commencer a regarder les produits qui ne sont pas GPL. Parce que faire passer le bout pas compatible GPL en compatilbe, ben des fois tu peux pas. Et d'autres impératifs dans ton développement ne te laissent pas le choix (contrats fournisseurs, besoin de faire vivre ton business, etc...). Et la raison sociale de ton business, c'est de vendre des produits, pas de passer ton temps a te défendre en proces.
Je suis perso plus orienté GPL que BSD ; mais vu le comportement de certains défenseurs zélés de la premiere, ca me parrait logique que des boites lorgnent du coté de la seconde.
[^] # Re: Pas pu attendre vendredi....
Posté par benoar . Évalué à 3.
Si, tu as le choix. Dis juste "je préfere mes fournisseurs/mon business a la liberté de mes utilisateurs". C'est un choix que tu as fait, assume le.
[^] # Re: Pas pu attendre vendredi....
Posté par imalip . Évalué à 4.
"je préfere mes fournisseurs/mon business a la liberté de mes utilisateurs"Euh, dans mon exemple, *tout* est libre. Sauf que comme la GPL est un plutot pointilleuse sur ce avec quoi on peut l'associer, on te fait chier.
Et je ne sais pas si/ou tu bosses, mais parfois, le choix se limite a faire des compromis avec ses principes, ou chercher un nouveau boulot.
[^] # Re: Pas pu attendre vendredi....
Posté par benoar . Évalué à 2.
Oui je bosse, et je sais qu'il faut faire des compromis. Mais je n'aime pas ceux qu'on "m'oblige" à faire, alors je pense effectivement chercher un nouveau boulot (bah oui, j'ai le choix ...).
[^] # Re: Pas pu attendre vendredi....
Posté par nullisimo . Évalué à 4.
C'est une relation de cause a effet. Aurait-il du dire
"A cause des entreprises qui ne respecte pas la GPL, le SFLC doit engager des poursuites qui decouragent ces entreprises d'utiliser linux. Helas, elles nous utiliserons plus souvent" ?
Faut pas deconner non plus.
Ne prete pas des intentions malhonnetes a 2 phrases.
# Performances réseaux
Posté par Victor STINNER (site web personnel) . Évalué à 6.
« It seems network performance is much better in 7.0!
Andre Oppermann: In general it can be said that the FreeBSD 7.0 TCP stack is three to five times faster (either in increased speed where not maxed out, or reduced CPU usage). It is no problem to fill either 1 Gb/s or 10 Gb/s links to the max. »
Interview :
http://www.onlamp.com/pub/a/bsd/2008/02/26/whats-new-in-free(...)
Le nouveau scheduler de processus (ULE) et le nouvel allocateur de mémoire montre d'excellentes performances sur des machines multi-processeurs (ce qui sera de plus en plus courant). Petit article que j'ai écrit sur les allocateurs mémoires :
http://www.haypocalc.com/blog/index.php/2007/11/08/87-gestio(...)
# gcc 4.2.1
Posté par zul (site web personnel) . Évalué à 8.
- Intégration de OpenMP facile dans FreeBSD ?
- Intégration de code sous GPLv3 n'a t il pas posé des problèmes légaux dans FreeBSD? ou du moins suscités des questions ? Je demande ça parce que pour le projet NetBSD, ca a pas l'air si evident que ça. On a fait appel à des avocats spécialisés sur ce genre de question, et de nombreux utilisateurs / développeurs continuent à se poser des questions sur la viabilité de la chose ? (en particulier dans l'embarqué).
(oui NetBSD, c'est un vrai méchant projet plein de barbus qui aiment pas le libre, bien sûr).
[^] # Re: gcc 4.2.1
Posté par x0ra . Évalué à 3.
gcc 4.2.1 est le dernier gcc a etre GPLv2, donc pas de problème.
[^] # Re: gcc 4.2.1
Posté par Poulpatine (site web personnel) . Évalué à 2.
[^] # Re: gcc 4.2.1
Posté par zul (site web personnel) . Évalué à 2.
Que fera-t-on si on ne veut pas continuer à distribuer simplement une nouvelle version de gcc ? Probablement, on restera sur cette version de gcc en attendant mieux. A savoir une emergence réelle de pcc (j'y crois pas), ou de llvm-c/c++ (avec le méchant apple qui se sert du libre). (Sinon la GPLv3, c'est une vraie progression ... (ou pas))
[^] # Re: gcc 4.2.1
Posté par Bapt (site web personnel) . Évalué à 3.
et pour ce qui demande du gcc il serait disponible via les ports.
[^] # Re: gcc 4.2.1
Posté par Poulpatine (site web personnel) . Évalué à 1.
[^] # Re: gcc 4.2.1
Posté par Maclag . Évalué à 1.
[^] # Re: gcc 4.2.1
Posté par TeXitoi (site web personnel) . Évalué à 4.
# GPL
Posté par ciol . Évalué à 1.
Pourquoi ?
[^] # Re: GPL
Posté par JoeBar . Évalué à 6.
# TSO et LRO
Posté par Brice Goglin . Évalué à 3.
> d'utiliser certaines cartes accélératrices de type TSO (TCP/IP
> segmentation offload) et LRO (Large Receive Offload) au lieu de
> faire ces opérations uniquement avec le processeur central.
Cartes accélératrices est très abusé là...
TSO c'est juste découper un gros paquet à envoyer en plusieurs MTU et être capable d'ajuster quelques headers genre le numéro de séquence. Pas de quoi casser 3 pattes à un canard. Toutes les cartes modernes dignes de ce nom savent le faire.
LRO, c'est une autre histoire. Il n'a d'Offload que son nom. Agréger des paquets en réception implique de connaître l'état de toutes les connexions. C'est impossible dans les cartes réseau pour des raisons de ressources mémoire, de puissance et synchro avec l'hôte. Toutes les implémentations actuelles de LRO sont logicielles. C'est la pile basse de réception (au niveau des drivers) qui agrège des paquets avant de les passer à la pile haute (genre TCP) pour réduire les coûts. Mais on sait très bien faire ça sans assistance d'une carte "accélératrice". La plupart des drivers Linux qui font du LRO le font purement logiciellement.
Le seul point sur lequel les cartes peuvent aider le LRO, c'est le header-splitting qui consiste à déposer les headers et données en des endroits séparés en mémoire pour faciliter l'agrégation LRO au dessus. Certaines cartes savent faire ça (Neterion notamment), mais beaucoup de drivers n'en ont pas besoin pour avoir du LRO très performant (Myri-10G et eHEA notamment).
[^] # Re: TSO et LRO
Posté par vjm . Évalué à 3.
http://www.FreeBSD.org/cgi/man.cgi?query=nxge&sektion=4&(...)
truc de ouf hein ? ;)
[^] # Re: TSO et LRO
Posté par Brice Goglin . Évalué à 2.
Pour les détails techniques, il vaut mieux regarder
http://lwn.net/Articles/244206/
http://fxr.watson.org/fxr/source/dev/mxge/mxge_lro.c?v=RELEN(...)
http://fxr.watson.org/fxr/source/dev/nxge/if_nxge.c?v=RELENG(...)
On y voit le code qui accumule logiciellement les paquets (code générique dans Linux, et code spécifique à 2 drivers dans FreeBSD). On se demande pourquoi ca s'appelle LR"O" au final...
[^] # Re: TSO et LRO
Posté par benoar . Évalué à 0.
[^] # Re: TSO et LRO
Posté par vjm . Évalué à 2.
http://fxr.watson.org/fxr/source/dev/nxge/xgehal/xgehal-devi(...)
avec l'aide de http://fxr.watson.org/fxr/source/dev/nxge/include/xgehal-typ(...) ?
[^] # Re: TSO et LRO
Posté par Brice Goglin . Évalué à 7.
Je vois un driver qui agrege en software...
Tout se passe dans xge_hal_lro_process_rx():
La carte vient de déposer un nouveau paquet en mémoire, le driver appelle d'abord__hal_lro_capable() pour savoir si on peut agreger ce paquet, puis __hal_get_lro_session() pour recuperer/creer la session de LRO, puis __hal_append_lro() pour accumuler le paquet dans cette session. Il n'y aucune intervention de la carte dans tout ca.
Et comme tu peux le remarquer, le code n'est pas très compliqué. Il s'agit grosso-modo d'ajuster les checksums, longueur et numeros de sequence dans les headers IP et TCP, et de chainer les buffers de donnees.
Tu veux peut-être aussi que je t'explique comment LRO marche dans le driver que je maintiens dans Linux ? :)
[^] # Re: TSO et LRO
Posté par herodiade . Évalué à 6.
Ah, et bien si tu le propose... ça ne serait pas inintéressant de savoir :)
[^] # Re: TSO et LRO
Posté par vjm . Évalué à 3.
Et je suis également de l'avis d'herodiade, dis-nous tout :)
[^] # Re: TSO et LRO
Posté par Brice Goglin . Évalué à 10.
Pour bien suivre la suite, je conseille d'ouvrir net/ipv4/inet_lro.c pour voir le code du LRO générique auquel je vais faire reference ci-dessous ainsi que driver/net/ehea/ehea_main.c pour son utilisation dans le driver eHEA.
Lorsqu'un paquet arrive, les drivers normaux appelent netif_receive_skb() (ou netif_rx() selon si NAPI est actif ou pas) qui passe le paquet aux couches supérieures (genre IP et TCP). Si tu supportes LRO, tu appelles lro_receive_skb() a la place.
La-dedans, le vrai travail est fait dans __lro_proc_skb(). Quand cette fonction n'arrive pas a LROer, elle retourne une erreur et lro_receive_skb() se rabat sur les netif_receive_skb() ou netif_rx() habituels.
Le détail de __lro_proc_skb() maintenant. D'abord, elle utilise un callback get_skb_header() du driver pour recuperer des infos sur le paquet. Comme chaque carte stocke les headers et donnees de sa propre maniere, le callback est defini par le driver a l'initialisation et le LRO l'appelle quand il a besoin de trucs specifiques, l'endroit ou est stocké le header dans le paquet actuel en l'occurence.
Ensuite, __lro_proc_skb() verifie que c'est du IPv4 et TCP puis on essaie de recuperer un "descripteur" de LRO (l'equivalent des sessions de neterion) par lro_get_desc. On l'initialise si nécessaire, on vérifie que le nouveau paquet va bien juste après ce qui a deja ete recu dans ce descripteur, puis l'ajoute avec lro_add_packet()
lro_get_desc(), c'est juste un tableau de connexions en cours de LRO. Chaque driver en supporte un certain nombre (genre 8), limite plus ou moins arbitraire. Chaque arrivee de plein de paquets d'une meme connexion cree une session, et on la flushe un peu plus tard en passant l'agregation de tous les paquets d'un coup aux couches superieures.
Comme en general, meme si on a plein de connexions ouvertes, on a pas plein de paquet entrelacés de toutes les connexions a la fois, 8 sessions suffisent a peu pres pour couvrir les connexions qui bourrinent vraiment. A noter que si une connexion alterne entre activité et calme, elle acquiera/relachera des sessions LRO au fur et a mesure. On ne peut pas garder une session indefiniment, elle sera flushee de force de temps en temps pour la preter aux autres connexions. Bref ca marche :)
__lro_proc_skb() finit par l'ajout de paquet avec lro_add_packet(). C'est des trucs chiants de manipulation des buffers contenus dans le skb (on les chaine a la queueleuleu), et d'adaptation des longueurs, checksums et seqnums, pas grand chose d'intéressant.
La question finale, c'est "quand est-ce qu'on arrete d'agreger?". Deja, il y a un nombre max de paquets defini par le driver (lro_mgr->max_aggr, 64 souvent). De plus Linux n'aime pas les paquets de plus de 64ko, donc on arrete d'agreger avant.
Concretement, arreter d'agreger, c'est fermer une session et la passer aux couches superieures. On utilise lro_flush() pour faire ca. Elle finit d'ajuster les headers TCP/IP et passe le gros paquet agregé a netif_receive_skb() (ou netif_rx() selon si NAPI est actif). Apres ca, le descripteur/session LRO est relaché, donc une autre connexion (ou la meme) pourra l'utiliser.
De plus, on agrege les paquets qui se suivent dans une mem connexion. Mais si ca arrive pas dans l'ordre, on arrete d'agreger. Ca evite d'avoir a gerer des trous. Et aussi ca evite par exemple de passer des paquets tres tres dans le desordre aux couches superieures. Par exemple un paquet recent serait deja remonté pendant que des paquets vieux continueraient a se faire agreger au niveau du driver au lieu de remonter eux aussi.
Et enfin, on arrete d'agreger a intervalle vaguement regulier (quand NAPI fait un coup de polling du driver) pour éviter que des paquets soient ralentis trop longtemps dans le driver pour rien. On appelle lro_flush_all() qui fait lro_flush() sur tous les descripteurs/sessions en cours.
Vous pouvez aussi regarder drivers/net/myri10ge/myri10ge.c qui utilise le LRO generique avec des fragments (pages physiques discontigues) par opposition a eHEA qui utilise des skb lineaires (socket buffer contigus en memoire virtuelle). C'est juste une differente gestion de la memoire et de la facon dont la carte depose les paquets en reception. Le LRO fournit des fonctions *_skb() et *_frags() pour gerer les 2 modeles.
[^] # Re: TSO et LRO
Posté par benoar . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.