Si vous voulez devenir un kernel hacker et tomber les filles il faut que vous soyez au courant de toutes les "bonnes pratiques" du développement du noyau.
C'est votre jour de chance car Jonathan Corbet, l'homme derrière LWN vient de publier sur le site de la Linux Foundation un guide du développement Linux.
http://ldn.linuxfoundation.org/book/1-what-this-document-is-(...)
C'est très complet, très intéressant et c'est bourré de conseils d'un des types qui connaît le mieux le processus de dev du noyau. J'en conseille vraiment la lecture même si vous n'avez jamais écrit le moindre patch car on comprends beaucoup mieux toute l'organisation et le fonctionnement de la grosse machine qui crache un nouveau noyau tous les 3 mois.
Pour l'instant ce n'est accessible que sous la forme de pages web successives mais la création d'un gros pdf global est prévue.
Journal Participer un développement de Linux
13
août
2008
# typo
Posté par patrick_g (site web personnel) . Évalué à 6.
C'est évidemment "Participer au développement de Linux"
[^] # Re: typo
Posté par NeoX . Évalué à 3.
;-)
# Bien sur ...
Posté par Elfir3 . Évalué à 10.
Et pourquoi pas devenir chuck norris aussi ... ? Au moins tu aurais parlé de quelque chose que nous connaissons un tant soit peu ;)
# Ne pas participer au developpement de Linux...
Posté par Jerome Herman . Évalué à 4.
Vous avez intéret à avoir beaucoup de temps libre ou une équipe de 10 personnes qui connaissent déjà bien pour vous aider. Parcequ'en ce moment, le temps de comprendre comment fonctionne une API kernel elle est déjà obsolette...
Ah, au fait si vous voulez écrire du code qui vise à améliorer le comportement desktop, favoriser la virtualisation, ajouter l'API OSS4 ou glicer les #@*!! de MTRR de daube qui auraient du mourir au profit du PAT il y a de celà 15 ans, laissez tomber. La réponse est non. Et ne cherchez pas à comprendre.
(A titre d'exemple il a fallu 4 ans à Alan Cox pour convaincre Linus de foutre à la poublelle l'ancienne API IDE et au final c'est lui tout seul qui s'est paluché la nouvelle quasiment tout seul. Résultat : 3 ans plus tard le Sata reppart sur une pseudo émulation SCSI et s'enlise lentement dedans....)
[^] # Re: Ne pas participer au developpement de Linux...
Posté par patrick_g (site web personnel) . Évalué à 1.
Ce serait redondant avec ALSA non ?
[^] # Re: Ne pas participer au developpement de Linux...
Posté par Jerome Herman . Évalué à 5.
[^] # Re: Ne pas participer au developpement de Linux...
Posté par GeneralZod . Évalué à 3.
Si tu as du temps pour intégrer OSS4, mets le plutôt à profit en écrivant de la documentation, des tests, des patchs pour ALSA.
[^] # Re: Ne pas participer au developpement de Linux...
Posté par Jerome Herman . Évalué à 5.
Et alors ? On s'en fout. On a du code GPL donc on en fait ce qu'on en veut. Avec ou sans les équipes OSS.
Si tu as du temps pour intégrer OSS4, mets le plutôt à profit en écrivant de la documentation, des tests, des patchs pour ALSA.
Alsa c'est près de 2000 fonctions dont seulement une vingtaine sont documentées (et encore à des niveaux très variables et pas forcément à jour). Alsa c'est 3 révisions d'API avec des modules de compatibilités et des wrappers encastrées les uns dans les autres. Alsa c'est pas moins de trente méthodes différentes pour initialiser une carte (sans aucune doc pour dire quelle méthode utiliser et dans quelles circonstances - faites confiance au pilote les gars, il s'en occupe).
A l'impossible nul n'est tenu. J'aurais plus vite fait de réécrire un système de gestion de son moi-même que de chercher à deviner comment telle ou telle fonction au nom barbare peut bien fonctionner.
Et pour finir Alsa c'est par linux 2.6, pour linux 2.6 et seulement linux 2.6.
Et moi j'aime bien que mon code marche sur BSD, Windows, AIX et autre.
[^] # Re: Ne pas participer au developpement de Linux...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Ne pas participer au developpement de Linux...
Posté par Anonyme . Évalué à 2.
Ha ha. Moi j'ai un proverbe : "ca sent rarement la merde quand il n'y a pas un gros tas de fumier". Et remuer la merde en creusant a côté des copains n'est sans doutes pas une bonne idée.
Alors, oui, alsa a certainement des (gros) problèmes et des (grosses) lacunes, ca n'en fait pas un mauvais projet pour autant. Certains objectifs ont été accomplis, comme la faible latence, une configuration (un peu kung fu) mais très souple et un large panorama de matériel géré, comme par exemple la carte un peu ésotérique mais annoncée compatible linux que j'ai acheté 300€ il y a 5 ans. (équivalent "grande marque" compatible linux a 100% : 500€). Alsa avait beau être jeune, supportait déjà cette carte, de manière franchement incomplète certes, mais pour OSS, je peux toujours me brosser (enfin brosser mes 200€).
Donc voilà quoi, y'a des lacunes, mais faut pas s'étonner vu le travail accompli par ailleurs.
[^] # Re: Ne pas participer au developpement de Linux...
Posté par Guillaume Knispel . Évalué à 0.
C'est pas en faisant ça que ALSA arrêtera d'être tout pourri... :/
[^] # Re: Ne pas participer au developpement de Linux...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Alan Cox est parti réécrire une meilleur couche. Mais on ne bascule pas d'une api à une autre sur un truc aussi sensible sur la préservation de ses données !
De plus, l'api Sata et IDE doit avoir les bons drivers de chipset. Il en manquait plein pendant longtemps pour lla lib sata.
Donc je comprends Linus qui ne veut pas tout de suite d'un code qui fait en sorte que du matos ancien qui marchait ne marche plus.
"La première sécurité est la liberté"
[^] # Re: Ne pas participer au developpement de Linux...
Posté par Jerome Herman . Évalué à 7.
Je ne parle pas du tout de l'API coté hard c'est à dire des différents pilotes qui initialisent le bus IDE et qui se chargent de reprendre les infos du BIOS, mais de la couche d'abstraction qui permet de finir l'initialisation du disque, d'en régler la vitesse et d'interagir physiquement avec les différents périphériques du bus de façon générique.
En ce qui concerne la perte de données potentielle, une fois qu'un disque a été initialisé avec le bon nombre de têtes et de cylindres et qu'il est accessible via les IRQs et autres appels systèmes, c'est le boulot de la couche encore au dessus (à savoir les pilotes file system)
Pour finir, ce n'est pas que Linus ne veut pas tout de suite d'un code qui bousille le matos ancien, mais c'est qu'on se retrouve au contraire avec une seule API bas niveau (ici SCSI) qui gère deux types de matos très différents. On se retrouve donc à voir arriver dans l'API SCSI des modifs qui ne servent qu'au SATA (Genre les patchs bien gruik sur IO_WAIT_SCAN). Donc loin de préserver une API sensible des modifications, on se retrouve à ajouter des verrues dans une API éprouvée pour palier à des bugs de chipsets peu répandus...
[^] # Re: Ne pas participer au developpement de Linux...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
As-tu posé la question sur ses points précis sur le "pourrissement" de l'interface SCSI ?
D'ailleurs, il me semblait que le sata proposait de plus en plus de fonctionnalité SCSI. Tu as l'air de pensé qu'il faudrait une api de plus haut niveau entre sata et scsi ?
Du point de vue utilisateur, les "sda, hda" ont toujours paru étrange, à pret tout il ne s'agit que de disque dur. (seul le driver diffère)
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.