Je viens d’acheter le login n°125 et dans la rubrique actualité j’ai pu lire “les développeurs ne planchent toujours passur la génération 2.7 du noyau linux car…personne ne sait encore quoi à ajouter” et quelques lignes avant Linus torvalds dit que les nouvelles technologie viendront des utilisateurs. Je me suis dit qu’il faut donc tous bêtement demander aux utilisateurs en question ce que l’on pourrait ajouter au noyau pour l’améliorer (autres que des pilotes ou le support de chipset particuliers) 
. Donc si vous avez une idée pour le noyau 2.7 histoire que linux ne meurt pas parque le manque d’imagination des programmeurs. Sinon je sais ou je pourrais contacter c’est programmeurs pour leurs faire par de vos idées en francais, s’il y a des programmeurs du kernel francais?
Je trouve ton initiative très louable mais ds quelle direction il faudrait chercher ?
Si tu pouvais ns tracer une route, on pourrait ptet y trouver des chemins qui y mènent.
je n’ai pas beaucoup d’idée ne fesant pas de programmation systeme tel que le noyau mais je pense que d’autre chose que le support de matériel pourrait être trouvé. Je n’ai pas de direction à propose mais il faut evité le support de nouveau matériel. A plusieur ont à tjr plus d’idée.
une simplification…
Pr le moment difficile de connaitre tous les modules, leur utilite etc etc…
En ce qui me concerne j’ai passe bcp de temps a chercher de quels modules j’avais besoin si je devais les valider en hard ou pas etc.
Bref, c’est pas tres intuitif tout ca et seul un utilisateur experimente pr reellement optimiser son kernel.
J’avoue c’est vague et je ne propose pas de solution mais au moins j’en aurais parle! 
Je dirais aussi qu’il serait genial si, lors de l’install d’une image kernel (dpkg -i kernel-image-2.6.X.deb), celui ci pouvait generer un /boot/config-2.6.X un peu plus optimise…
Pour le moment les 3/4 des modules sont coches par defaut alors qu’on en a pas forcement besoin (par exemple, tous les modules ayant attrait au PCMCIA/Laptop alors qu’on est sur un PC; idem pr les ports: modules ISA coches alors qu’on a que du PCI; etc)
Pour faire moi meme de la prog systeme c’est largement a leur portee!
Bon parcontre c’est clair que ca demande un boulot monstre pr etre realise!
ton idée est tres bien meme si je pense pas que les programmeurs accepterons de simplifier le noyau car cela sera au depi des performance de Linux regarde windows il est telement simplifié qui est devenu deux tensions. Linux est fait pour être performant meme si il faut qu’il soit compliqué et je connais un peu le fonctionnement de linux quand tu regarde de plus pret c’est tres logique. La simplifications ne serait pas sur le noyau mais sur un outils permettant de le manipuler en interface graphique cela pourrait être ajouté et ainsi on garde les performances et ont obtient la simplifiaction. Seule defaut il faut un serveur X.
Une interface graphique??? T’as pas compris ce a quoi je pense
Lors de l’installation d’un kernel-image-2.6.X un programme doit se charger de detecter le materiel (ports, cartes reseau, son, etc)et de conclure quels modules doit etre inclus dans le kernel et a l’ecrire de le /boot/config-2.6.X.
c’est ca le but!
Donc ensuite quand tu compiles le noyau a partir de kernel-source-2.6.X tu commences par copier /boot/config.2.6.X dans /usr/src/kernel-source-2.6.X/
La un utilisateur lambda n’aura pas besoin d’aller modifier ce fichier par un make menuconfig ou autre puisque les modules auront deja ete preselectionne lors de l’install du kernel-image… Tout en laissant aux experts le loisir d’y toucher quand meme.
Donc:
- ca simplifie le procede de compilation: plus besoin de passer du temps a selectionner les bons modules.
- ca ne simplifie pas le fichier de config du kernel qui restera comme il est a l’heure actuelle mais les modules necessaires seront en fait deja valides (ce qui permet a un utilisateur lamba de compiler un nouveau noyau sans connaisances specifiques en la matiere.)
- cette preselection des modules se fera juste a l’installation du kernel-image donc ca ne fait pas de linux un Windows bis.
Ne t’inquiètes pas, la simplification et l’allègement du noyau et de la gestion matèrielle sont des sujets permanents et critiques pour les équipes kernel.
Déja, il y a eu le passage du monolithique au modulaire. Avant (et c’est resté longtemps le cas pour les architectures insolites) on devait compiler le noyau avec à l’interieur tous les composants matèriels de la machine cible. Les modules ont permis dèja le chargement dynamique des routines de gestion hardware, ce qui permet, lors de son fonctionnement, de ne charger que les modules dont la machine a réellement besoin, et de gèrer les dispositifs connectables à chaud.
Alors OK, il reste encore la configuration de ces modules, comme tu le dis, mais ce n’est pas au niveau de la compil, que doit se faire l’optimisation, et le choix des modules qui nous interressent: si tu considères une arborescence complete de modules (/lib/modules/2.X.YY) cela ne prend qu’~ 50 Mo, et que le noyau est aux alentours d’1,4 Mo.
Pourquoi, à part dans une logique embarquée, devrait on se priver d’avoir à disposition tous les modules dont on peut avoir besoin en cas de transfert du disque vers une nouvelle machine, ou de connection d’un dispositif USB.
hotplug et discover font eux mêmes le tri aprés démarrage entre les modules utiles et ceux qui ne le sont pas, et grace à ca, c’est super facile de trimballer son linux de machine en machine. Même si il y a des amèliorations à apporter, ca marche dèjà pas mal avec cette logique.
On pourrait peut etre ne compiler les modules que “juste à temps”, et en fonction de l’architecture détectée. Peut etre qu’il y aurait qqchose à chercher de ce coté là…
Mais sinon, cette présence de “tous les modules compilés”, c’est ce qui permet à ma debian d’avoir plusieurs années, et elle s’est adapté sans problème à plusieurs architectures matérielles allant du PII à l’AMD, en passant par une floppée de pIV différents qui m’ont servit à la faire tourner. Essayes de trimballer un disque de machine en machine sous windows, et compares.
Finalement, je m’étais posé dèjà la même question que toi, mais plus pour optimiser la vitesse que pour économiser de la ressource disque (cela n’a pas de sens de nos jours), et effectivement, ce ne doit pas être trés sorcier (une semaine ou deux de boulot je pense) de faire un script qui analyse le contenu de /proc (voir si c’est comme ca qu’ils détectent le hard chez knoppix), et qui fabrique un .config sur mesure qui ne compile que les modules necessaires au hard courant plus les modules pouvant etre sollicités à chaud, plus ceux choisis “par configuration”, le tout en en l’optimisant pour l’archi.
Il faudrait regarder du coté de libdiscover, je pense.
Pourquoi pas une target “autoconfig” au makefile du kernel ou ajoutée à make-kpkg.
On peut même imaginer l’intègration de tout ca au processus d’install et aux tâches de maintenance: aprés le premier reboot avec un noyau générique, la détection et la recompilation du noyau optimisé se fait automatiquement en tache de fond. Une fois terminé et le nouveau noyau installé, la tache propose un redémarrage, ou le signale quelquepart.
Aprés, derniere étape plus technique, en “préboot”, on surveille le hard, et en cas de détection de modif sur matèriel, ca reboote sur le noyau générique, et ca recommence la compil auto du noyau optimisé…
tiky: tu veux t’y mettre ?
[quote=“MattOTop”]Ne t’inquiètes pas, la simplification et l’allègement du noyau et de la gestion matèrielle sont des sujets permanents et critiques pour les équipes kernel.
Déja, il y a eu le passage du monolithique au modulaire. Avant (et c’est resté longtemps le cas pour les architectures insolites) on devait compiler le noyau avec à l’interieur tous les composants matèriels de la machine cible. Les modules ont permis dèja le chargement dynamique des routines de gestion hardware, ce qui permet, lors de son fonctionnement, de ne charger que les modules dont la machine a réellement besoin, et de gèrer les dispositifs connectables à chaud.
Alors OK, il reste encore la configuration de ces modules, comme tu le dis, mais ce n’est pas au niveau de la compil, que doit se faire l’optimisation, et le choix des modules qui nous interressent: si tu considères une arborescence complete de modules (/lib/modules/2.X.YY) cela ne prend qu’~ 50 Mo, et que le noyau est aux alentours d’1,4 Mo.
Pourquoi, à part dans une logique embarquée, devrait on se priver d’avoir à disposition tous les modules dont on peut avoir besoin en cas de transfert du disque vers une nouvelle machine, ou de connection d’un dispositif USB.
hotplug et discover font eux mêmes le tri aprés démarrage entre les modules utiles et ceux qui ne le sont pas, et grace à ca, c’est super facile de trimballer son linux de machine en machine. Même si il y a des amèliorations à apporter, ca marche dèjà pas mal avec cette logique.
On pourrait peut etre ne compiler les modules que “juste à temps”, et en fonction de l’architecture détectée. Peut etre qu’il y aurait qqchose à chercher de ce coté là…
Mais sinon, cette présence de “tous les modules compilés”, c’est ce qui permet à ma debian d’avoir plusieurs années, et elle s’est adapté sans problème à plusieurs architectures matérielles allant du PII à l’AMD, en passant par une floppée de pIV différents qui m’ont servit à la faire tourner. Essayes de trimballer un disque de machine en machine sous windows, et compares.
Finalement, je m’étais posé dèjà la même question que toi, mais plus pour optimiser la vitesse que pour économiser de la ressource disque (cela n’a pas de sens de nos jours), et effectivement, ce ne doit pas être trés sorcier (une semaine ou deux de boulot je pense) de faire un script qui analyse le contenu de /proc (voir si c’est comme ca qu’ils détectent le hard chez knoppix), et qui fabrique un .config sur mesure qui ne compile que les modules necessaires au hard courant plus les modules pouvant etre sollicités à chaud, plus ceux choisis “par configuration”, le tout en en l’optimisant pour l’archi.
Il faudrait regarder du coté de libdiscover, je pense.
Pourquoi pas une target “autoconfig” au makefile du kernel ou ajoutée à make-kpkg.
On peut même imaginer l’intègration de tout ca au processus d’install et aux tâches de maintenance: aprés le premier reboot avec un noyau générique, la détection et la recompilation du noyau optimisé se fait automatiquement en tache de fond. Une fois terminé et le nouveau noyau installé, la tache propose un redémarrage, ou le signale quelquepart.
Aprés, derniere étape plus technique, en “préboot”, on surveille le hard, et en cas de détection de modif sur matèriel, ca reboote sur le noyau générique, et ca recommence la compil auto du noyau optimisé…
tiky: tu veux t’y mettre ?[/quote]
j’etais en train de recoder malloc, realloc et free…
J’avais le cerveau bien en ebulition
MattOTop m’a fini.
Je n’est jamais fait des truc semblable à cela mais si j’ai le temps je veux bien le faire. Si j’ai bien compris je doit faire un petit prog qui detecté dans le dossier proc le nouveaux matériel et qui recompile le noyau sio nécessaire avec les modules demandé? Si on mais sa au boot il faudrais demander à l’utilisateur si il veut recompiler ou non tous de suite car le noyau c’est long à compiler enfin il faudrais laisser l’ancien au cas ca ne marche pas.
[quote=“MattOTop”]Aprés, derniere étape plus technique, en “préboot”, on surveille le hard, et en cas de détection de modif sur matèriel, ca reboote sur le noyau générique, et ca recommence la compil auto du noyau optimisé…
tiky: tu veux t’y mettre ?[/quote]
Interessant, ça fait donc un moment qu’on est sur le 2.6 …
Je dirai que l’autodetection de tout matériel, tous types confondus, et le dowload des drivers adéquats, leur débianisation si nécessaire, devraient fournir les bases du menu de config avant son affichage, et constituer le corps des options par défault (tenant compte des recommandations modulaire ou en dur). Evidement, faudrait une connection internet … pour la compilation, que l’on appelerait autocompil …
De plus, les options spécifiées par l’autodétection ne viendraient s’ajouter qu’à un noyau minimal …
bah, si on s’y met tous, c’est possible, et là, franchement, linux aura émancipé de nouveaux horizons … ça laisserait plus de temps aux utilisateurs lambda pour apprendre les lignes de commandes unix 
Beaucoup moins de découragement en perspective