Le Mon, 19 Nov 2001 15:01:48 +0100, [EMAIL PROTECTED] �crivait :
> Le probl�me que je me pose, peut-�tre � tort, est d'utiliser le m�me > noyau pour toutes nos Debian, pour faciliter entre autres les > mises-�-jour. Alors forc�ment, comme elles diff�rent souvent par leurs > mat�riels (en particulier les cartes SCSI), je suis oblig� d'int�grer > tous les pilotes ad�quats. > sauf malchance sur ton parc, tu n'as quand m�me pas autant de machine que de cartes SCSI, non ? Ceci dit, je les gardes quand m�me en module. Sauf en cas de disques SCSI, tu n'emp�ches pas de booter et de charger le module ensuite... Enfin, j'ai pris l'exemple du SCSI mais je crois que tu peux tr�s largement piocher ailleurs (regarde les trucs assez bizarro�des qui ne te serviront jamais dans un labo (normal :-))) > Ce qui m'�tonne le plus dans cette affaire, c'est que l'ajout de > l'option CONFIG_SMP rend le noyau visiblement plus gros. Toujours de m�moire, l'algo de SMP est compl�tement d�corell� du monoprocesseur. L'activer revient � int�grer du code suppl�mentaire (et certainement plus lourd que celui du mono) et donc explique parfaitement l'explosion (d'autant plus que tu �tais d�j� limite). Il me semble me rappeler (c'est d�cidement ma journ�e) que cela avait �t� appremment discut� sur la liste du noyau (de Debian) et que finalement, vu que le nombre de machine SMP �tait franchement minoritaire (� l'�poque) et du ressort d'admin (cadre professionnel), le choix s'�tait port� sur son exemption par d�faut pour int�grer autre chose, un admin pouvant bien recompiler son noyau si le besoin s'en faisait sentir. C'�tait d�j� comme cela pour le 2.x (qui avait un support encore plus exp�rimental du SMP). PK, souvenir, souvenir -- Patrice KARATCHENTZEFF STMicroelectronics Tel: 04-76-92-67-95 850, rue Jean Monnet 38926 CROLLES Cedex, France Courriel: [EMAIL PROTECTED]
