[Discussion] Recompilation de son kernel

[quote=“Ashgenesis”]Oulah zen les gars :wink:

C’est de la mauvaise foi,de ma part mai je l’avais dit en fin de post :laughing:
il fallait pas le prendre aux premier degré. :smt005 :blush:

[quote]Certes je pourrai faire mieux pour les commentaires, C’est a dire ne pas en mettre, un bon code n’en a pas besoin,le problème ce pose que si il a besoin de recevoir des informations de l’utilisateur.
donc juste faire une en-tête mai bon c’est vrai qu’aux départ ce petit “programe” était pas destiner a être publier :smt002 [/quote]

[quote]Faux, un bon code à besoin de commentaire mais pas trop. Il en faut le minimum pour les subtilitées que tu as trouvé au moment où tu l’as conçu, je te met au défis de reprendre n’importe quel code sans commentaire et de réussir à le comprendre en très peu de temps, même l’un des tiens que tu aurais fait il y a 6 mois.
[/quote]

Je suis a 200% d’accord avec fran.b le nom des variables est importante et souvent négligée.et a mieux su s’exprimer sure le sujet :smt006

J’ai trouver un qui est en français, mai pas tout a fait dans le même but que le tien, bien que sur le même sujet :slightly_smiling:

[quote=“thialme”]

Pff … préfère pas répondre. comme l’a rappeler Ashgenesis j’ai coder pour moi même avant tout et plutôt que de le garder pour moi j’ai préférer le poster. de cette manière il peux être repris en partie. Après sa plait ou pas.

Recevoir une critique est toujours la bienvenue. Mai bon il y a la manière de le faire ou plutôt de le dire :astonished: fran.b a donner un exemple concret et je trouve cela plus approprier.je trouve que ta critique manque de modestie et d’humours. Monte donc pas si vite dans les tours, si quelque chose ne te convien pas tu peux le souligner comme la fait fran.b,Ashgenesis qui je trouve est plus constructif.

Effectivement je pourrait revoir le nombre de variable et les nom pour faire plus cours.
oui mai sa sera plus large :smt019 :smt077 :laughing:

Désolé d’avoir mis mon grain de sel.

Voila un bout de code (DU CONCRET) de l’un de mes projets. Toute le présentation est cassée mais normalement, je ne laisse pas un truc qui ne soit pas aligné si je peux (je suis trop maniaque). Les 72/80 caractères, j’essaye mais je ne sais pas toujours comment m’en sortir ; le but étant simplement d’éviter des lignes de 4m de long. On y trouve du bon et du pas bon (bcp de fautes d’orthographe je pense), mais l’idée générale est là.

/*--------------------------------------------------------------------------*/
/*                                                                          */
/*          Logiciel embarqué de la carte XXXXX               */
/*                                                                          */
/*--------------------------------------------------------------------------*/

/** \file  Max6955.c
\brief <B> Module contenant les fonctions de gestion du Max6955
      </B>

Ce module contient les fonctions de gestion du composant Max6955
(Led Display Driver).

<TT> produit..:
\n   version..: 00
\n   auteur...: Fr. JONCOURT
</TT>
*/

/*-------------------------------- Librairies ------------------------------*/

#include "XXXXX.h"


/*------------------- Declarations des variables locales -------------------*/

static TMax6955Reg Max6955Reg;          ///< Registres de controle du Max6955


/*------------------- Affectation des segments du Lexan --------------------*/

// Tableau de croisement entre les digits du Max6955 et les digits softs utilisés
// dans le module affichage.c
static const U8 CODE affiCrossedTable[NB_SS_PHY][3] =
{ //     CENTAINES         DIZAINES             UNITES
  {  REG_DIGIT_0_P0P1,  REG_DIGIT_1_P0P1,  REG_DIGIT_2_P0P1 },    // SS_I_INFO
  { REG_DIGIT_0A_P0P1, REG_DIGIT_1A_P0P1, REG_DIGIT_2A_P0P1 },    // SS_I_REGU_LO
  { REG_DIGIT_3A_P0P1, REG_DIGIT_4A_P0P1, REG_DIGIT_5A_P0P1 }     // SS_I_REGU_HI
};

// Tableau de croisement entre les voyants du Max6955 et ceux utilisée dans
// le module affichage.c
static const U8 CODE ledsCrossedTable[LED_I_ALL][2] =
{
  //       REGISTRE       POSITION
  {    REG_DIGIT_4_P0P1,    0x40   },     // LED_I_MODE_1
  {    REG_DIGIT_4_P0P1,    0x20   },     // LED_I_MODE_2
  {    REG_DIGIT_4_P0P1,    0x10   },     // LED_I_MODE_3
  {    REG_DIGIT_4_P0P1,    0x08   },     // LED_I_MODE_4
  {    REG_DIGIT_4_P0P1,    0x04   },     // LED_I_MODE_5
  {    REG_DIGIT_3_P0P1,    0x10   },     // LED_I_READY_HI
  {    REG_DIGIT_4_P0P1,    0x40   },     // LED_I_READY_LO
  {    REG_DIGIT_5_P0P1,    0x80   },     // LED_I_REGUL_HI
  {    REG_DIGIT_5_P0P1,    0x40   },     // LED_I_REGUL_LO
  {    REG_DIGIT_3_P0P1,    0x04   },     // LED_I_PEDALE
  {    REG_DIGIT_3_P0P1,    0x02   },     // LED_I_VENTILO
  {    REG_DIGIT_3_P0P1,    0x01   },     // LED_I_FORWARD
  {    REG_DIGIT_5_P0P1,    0x20   },     // LED_I_REARM
  {    REG_DIGIT_4_P0P1,    0x02   },     // LED_I_MARCHE1
  {    REG_DIGIT_4_P0P1,    0x02   }      // LED_I_MARCHE2
};

#define REGISTRE  0x00
#define POSITION  0x01

/****************************************************************************/
/** <B> Charger la configuration actuelle dans le Max6955.
</B>

Cette fonction permet d'initialiser les registres du MAX6955 avec la
configuration presente. dans la structure de controle.
*/
static void load_config (
  U8 slaveAddress)      ///< Adresse du slave avec qui communiquer
{
    Max6955Write(slaveAddress, REG_DECODE_MODE,
                  sizeof(TConfigReg),
                  (U8*)&Max6955Reg.configReg);
    Max6955Write(slaveAddress, REG_KEY_A_PRESSED,
                  sizeof(Max6955Reg.configReg.digitType),
                  &Max6955Reg.configReg.digitType);
}

/****************************************************************************/
/** <B> Attends que le MAX6955 soit prêt
</B>

Cette fonction locale attend pendant 10ms maximum que le MAX6955 réponde à
son adresse sur le bus. Ce temps correspond au temps maximum d'écriture d'une
donnée dans le MAX6955.

\return OUI si EEPROM prête à recevoir des instructions.
        NON si EEPROM ne répond plus.
*/

static max6955_ready(
        U8   slaveAddress)      ///< Adresse du slave avec qui communiquer
{
    U8 tim;    /* compte-rendu de la fonction */

    // Attendre pendant 10ms que le MAX6955 soit pret
    for (tim=40 ; tim != 0 ; tim--)
    {
        // Sortir si adresse du max6955 est prise en compte
        I2cStart();
        if (I2cWrite(0xC0 | (slaveAddress << 1) | WR_MAX6955))
            break;
        mDelayMs(10);
    }

    // Retourner le compte rendu
    return (tim != 0) ? OUI : NON;
}

/****************************************************************************/
/** <B> Initialiser le MAX6955
</B>

Cette fonction permet d'initialiser la structure de controle du MAX6955.
*/
void Max6955Init (void)
{
  U8 ix;      ///< Variable temporaire pour l'initialisation des digits

  // Initialiser le bus I2C - déjà fait
  // I2cInit();

  // Mettre en place la configuration du MAX6955
  Max6955Reg.configReg.decodeMode         = 0x00;     // Enlever le decode mode
  Max6955Reg.configReg.globalIntensity    = 0x0E;     // Positionner l'intensite globale au minimum
  Max6955Reg.configReg.scanLimit          = 0x06;     // Scanner sur 7 digits
  Max6955Reg.configReg.controlRegister    = 0x09;     // Mettre le driver en mode normal avec blinking mode enabled
  Max6955Reg.configReg.gpioData           = 0x05;     // Valeur par defaut (non utilisee)
  Max6955Reg.configReg.portConfiguration  = 0x40;     // Scanner KEY_A et KEY_B pour les touches
  Max6955Reg.configReg.digitType          = 0x00;     // Mode 16 ou 7 segments pour les digits 0 à 7

  // Eteindre toutes les leds
  Max6955Reg.reloadDigit = 0xFF;

  for (ix = 0 ; ix < sizeof(Max6955Reg.digit) ; ix++)
  {
      Max6955Reg.digit[ix] = 0x00;
      Max6955Reg.blink[ix] = 0x00;
  }

  // Mettre à jour la configuration
  load_config(SLAVE_ADDRESS);

  // Mettre à jour les données
  Max6955Update();
}

/****************************************************************************/
/** <B> Ecrire une plage de donnees dans les registres du Max6955
</B>

Cette fonction ecrit une plage de donnees dans un des registres du Max6955,
en fonction de la cde passée en paramètre et de l'adresse de l'esclave.

return  OUI si l'ecriture c'est bien passee
        NON
*/
U8 Max6955Write (
        U8   slaveAddress,      ///< Adresse du slave avec qui communiquer
        U8   reg,               ///< Registre à charger
        U8   taille,            ///< la taille des donnees en octets a ecrire
        U8  *donnee)            ///< Pointeur sur la donnee
{
    U8 correct;                 ///< Détection d'une erreur

    // Attendre que le max6955 soit pret
    if (!max6955_ready(slaveAddress))
        return NON;

    // Envoyer la commande
    if (!I2cWrite(reg))
        return NON;

    /* Tant que tous les octets n'ont pas été écrits, */
    correct = OUI;
    while (taille-- != 0)
    {
        if (correct)
            correct = I2cWrite(*donnee++);
        else
            break;
    }

    // Envoyer l'octet de STOP
    I2cStop();

    return correct;
}

[…]

Et voila une fonction beaucoup trop longue car je suis loin d’être tout blanc, mais j’essaye :


/****************************************************************************/
/** <B> Met la structure de controle du MAX6955 a jour
</B>

Cette fonction permet de mettre a jour la structure de controle du MAX6955,
en fonction de l'affichage en cours.
*/
void Max6955UpdateReg(
  U8 mode,            ///< Mode d'affichage a prendre en compte
  U8 identifiant)     ///< Id(specifique au mode) a mettre a jour
{
  U8  col;             ///< Variable temporaire
  U8  ix;              ///< Digit du driver a mettre a jour
  U8  idVirtuel;       ///< Identifiant de l'afficheur virtuel au premier plan
  U16 position;        ///< Position de la led en cours de mise a jour
  U8  segment;         ///< Segment du bargraphe en cours de mise a jour

  switch (mode)
  {
    case MODE_AFFICHEURS :

      // Obtenir l'identifiant de l'afficheur virtuel au premier plan pour le
      // 7 segments selectionne
      for (ix=0x00 ; ix<SS_V_MAX ; ix++)
      {
        if ((tabAffi[identifiant].mode >> ix) == 0x01)
        {
          idVirtuel = ix;
          break;
        }
      }

      // Parcourir toutes les colonnes (unites, dizaines, centaines) de
      // l'afficheur virtuel en cours
      for (col=CENTAINES ; col<=UNITES ; col++)
      {
        // Obtenir le digit du MAX6955 associe au digit "soft"
        ix = affiCrossedTable[identifiant][col] - REG_DIGIT_0_P0P1;

        // Mettre en evidence une demande de rechargement du driver pour
        // le digit specifie
        Max6955Reg.reloadDigit |= (1<<ix);

        // Mettre a jour la structure de controle du Max6955
        Max6955Reg.digit[ix] = tabAffi[identifiant].affiVirtuel[idVirtuel][col];

        if (tabAffi[identifiant].affiClign[idVirtuel][col])
          Max6955Reg.blink[ix] &= ~Max6955Reg.digit[ix];
        else
          Max6955Reg.blink[ix] = Max6955Reg.digit[ix];
      }

      break;

    case MODE_LEDS :

      // Obtenir le digit du MAX6955 associe au digit "soft"
      ix       = ledsCrossedTable[identifiant][REGISTRE]  - REG_DIGIT_0_P0P1;
      position = ledsCrossedTable[identifiant][POSITION];

      // Mettre en evidence une demande de rechargement du driver pour
      // le digit specifie
      Max6955Reg.reloadDigit |= (1<<ix);

      // Mettre a jour la structure de controle du Max6955
      Max6955Reg.digit[ix] &= ~position;
      Max6955Reg.blink[ix] &= ~position;

      if (tabLeds.etat & (1<<identifiant))
        Max6955Reg.digit[ix] |= position;

      if ( (tabLeds.blink ^ tabLeds.etat) & (1<<identifiant) )
          Max6955Reg.blink[ix] |= position;

      break;

    case MODE_BARGRAPHE :

      // Parcourir tous les segments disponibles pour le bargraphe en cours
      for (segment=0 ; segment<tabBg[identifiant].niveau ; segment++ )
      {
        // Obtenir le digit du MAX6955 associe au digit "soft"
        ix = bgCrossedTable[identifiant][segment][REGISTRE]   - REG_DIGIT_0_P0P1;
        position = bgCrossedTable[identifiant][segment][POSITION];

        // Mettre en evidence une demande de rechargement du driver pour
        // le digit specifie
        Max6955Reg.reloadDigit |= (1<<ix);

        // Mettre a jour la structure de controle du Max6955
        Max6955Reg.digit[ix] &= ~position;
        Max6955Reg.blink[ix] &= ~position;

        if (tabBg[identifiant].etat & (1 << segment))
          Max6955Reg.digit[ix] |= position;

        if ( (tabBg[identifiant].clignotement ^ tabBg[identifiant].etat) & (1 << segment) )
          Max6955Reg.blink[ix] |= position;
      }

      break;
  }
}

J’ai encore beaucoup de choses à faire pour m’améliorer que ce soit au niveau algo, méthodes, clarté mais je teste et je vois ce que cela donne et ce que les autres en pense. Cela fait maintenant un peu moins de 2 ans et demi que je travaille, et du soft j’en fait 75% du temps autrement je fais les cartes qui vont avec. Du coup, avoir quelque chose de propre, de réutilisable et de maintenable s’impose.

Une demande de modification de soft tombe, alors que je suis sur un autre projet, ou le client appelle et veut savoir pourquoi le soft fait cela mais il reste en ligne.

Pas de commentaire et incompréhensible => trop de temps à retrouver ses petits => BIP !

Question bête pourquoi tu préfère :

/**********************************/ /*Mes lignes de commentaire sont là et il y en a plusieurs et plus encore */
à

[code]
/* Mes lignes de commentaire sont là

  • et il y en a plusieurs
  • et plus encore
    */[/code]
    (ou un dérive du même type)

Je pense que c’est pour mettre en évidence les fonctions et les séparer. J’aime bien les
(************************************)
en caml aussi…

Pour continuer sur le même sujet et vous présentez quand même ce que j’ai fait ashgenesis.debian-fr.net/docs/ca … main.c.txt C’est un calendrier tout simple rien de complexe mais l’important est le code et la façon dont il est structuré, je suis sur qu’il y a des choses à redire dessus mais cela me convient comme ça.

Je le présente pour que l’on puisse aussi critiquer car j’en ai fait beaucoup (de critique) jusque maintenant sans pouvoir avoir de retour sur mes pratiques. Je sais il doit manquer un peu de commentaire :wink:

Sinon thialme, je vois bien que ton code est structuré mais à première vue il me paraît bordélique. Bon après avoir regardé plus attentivement on s’aperçoit que ce n’est pas le cas. Je pense que ça doit venir du fait que tu utilise différents types de commentaires et aussi différentes positions par rapport au reste du code et cela me perturbe quelque peu.
Sinon aussi pour ton switch case je n’ai pas regardé ce que tu implémentais mais si tu peux le scinder de manière à appeler des fonctions ça réduirais celle contenant le switch et ça permetterais une meilleure lisibilité. Mais bon après c’est comme tout panthere toi et moi avons 3 façons de coder différentes qui ne sont pas forcément compatible sur tout. L’important est de pouvoir en discuter et réfléchir sur les meilleurs méthodes à utiliser. Étrangement, je respecte au maximum la règle des 80 caractères pour du code en C mais j’ai vraiment des difficultés à faire la même chose pour des scripts PHP où là je préfère clairement passé à 120 caractères et pour les commentaires type PHPdoc (javadoc)

[quote=“MisterFreez”]Question bête pourquoi tu préfère :

/**********************************/ /*Mes lignes de commentaire sont là et il y en a plusieurs et plus encore */
à

[code]
/* Mes lignes de commentaire sont là

  • et il y en a plusieurs
  • et plus encore
    */[/code]
    (ou un dérive du même type)[/quote]

Cela scinde bien les fonctions c’est tout.

C’est normale toute la présentation est cassée avec les espaces et les tabulations. De plus les balises et différents types de commentaires sont liées à l’utilisation de Doxygen auparavant.
Les variables locales de plus ne devraient pas être commentées par ///< mais par // simplement. J’ai aussi quelques soucis pour placer les commentaires de temps en temps car je ne sais pas où les mettre quand j’ai plusieurs longues lignes à se suivre.

[quote]
Sinon aussi pour ton switch case je n’ai pas regardé ce que tu implémentais mais si tu peux le scinder de manière à appeler des fonctions ça réduirais celle contenant le switch et ça permetterais une meilleure lisibilité.[/quote]
Oui, c’est bien pour cela que je disais qu’elle était trop longue :p! L’utilisation de fonctions aurait été plus net. Pour ce qui est de comprendre ce que j’ai écrit ce n’est pas le but de la manoeuvre car tout le code source du driver n’est pas présent tout comme pour les headers. Et en plus je n’ai jamais expliqué ce que cela faisait.

Enfin bref, retournons à la compilation du noyau.

Justement reprenons :smiley:
il serai intéressant d’avoir une traduction des option qui ce trouve dans les utilitaire de xconfig,menuconfig ect et sa existe deja un peux sur le net
linux-france.org/article/min … yau-3.html

pourquoi ne pas integrer sa aux soft ? a la limite fournir les lien sur le topic principal ?

Salut,

pour les options , un très bon travail a été fait --> Options de compilation

pratique pour faire un kernel string :slightly_smiling:

Interessant.
Il est mintenu a jours ,?
j’ai pas vu de commentaire a ce sujet ?
Car des nouvelle option arrive et d’autre disparaisse, ce qui fait la principal dificulter (mine de rien) !

Salut,

depuis le 2.6.23, les options n’ont pas été rajoutées
c’est peut-etre en cours, m’enfin il y a déjà de quoi faire :slightly_smiling:

Bonsoir,

Ce sujet date un peu certes mais il m’est actuellement très utile étant donné que je me penche à fond dans la compilation du dernier noyau.

C’est vraiment très intérressant mais entre les lignes de code que je suis incapable de comprendre et certaines dérives je n’ai pas le courage de lire en entier pour le moment.

Mais bon, je voulais vous remercier pour votre investissement car grâce à vous j’apprend et comprends. :wink:

Bonne continuation et à bientôt.

Un sujet c’est fait pour être remonté.
Si tu as des questions au sujet de commandes ou autres n’hésite pas.

(dans le sujet sur les scripts tu peut trouver deux scripts qui automatisent la compilation ou la recompilation)

Salut,
je profite de la remontée du sujet pour une interrogation que j’ai sur la compilation :

est t-il nécessaire de compiler à chaque màj du kernel pour profiter des modifs :
Exemple : j’ai compilé le noyau 2.6-24 à sa sortie pour mon portable, entre temps sort 2.6-24-1, puis 2.6-24-2 etc …

Merci :smt002

Bonjour Fyfee,

Je peux déjà partiellement te répondre sur un point que je n’avais pas encore compris hier mais sous réserve que cette fois j’ai bien compris, ce qui n’est pas sûr:

Le mieux est de compiler à partir des sources Débian (expliqué dans le premier sujet) qui est actuellement le linux-source-2.6.18.

Personnellement j’ai tenté pendant deux jours de compiler les sources 2.6.24-2 et j’ai rencontré un problème qui m’a empêché d’installer le pilote nvidia.

Si tu tiens à toujours avoir la dernière version du noyau il te faudras, je supposes, soit le patcher soit recompiler les dernières sources mais ce travail peut être facilité si tu récupère le .config de ton noyau actuel.

Merci MisterFreez, je prend note de ta proposition qui n’a pas rencontrée l’oeil d’un aveugle. :wink:

Pour le moment je vais tenter de simplement compiler les sources 2.6.18 afin de résinstaller ma Débian avec que j’ai maltraitée ces derniers jours… :blush:

Par contre je dois bien avouer que je ne suis pas confiant dans le fait de faire la compilation en root car j’ai toujours appris que je devais le faire en fakeroot et je n’ai pas trouvé d’explications satisfaisantes me permettant de croire que celà n’est pas dangereux.

Donc pour le moment je vais me concocter un noyau aux petits oignons d’après la méthode que je suit depuis quelques années (http://formation-debian.via.ecp.fr/wiki/index.php/Compiler_son_propre_noyau) à partir du noyau Débian et sans script car autrement je n’apprendras pas ou pas bien. :wink:

EDIT:
Par contre les fichiers génerés par vote méthode décrite ici m’intérressent donc j’aurais effectivement quelques questions concernant cette méthode:

Configurant moi-même les options du noyau afin d’avoir le noyau le plus rapide/petit possible n’est-il pas préferable d’installer également les sources generées ? Je supposes actuellement que c’est effectivement mieux.

Les autres fichiers genérés servent-ils par la suite ?
Et dernière petite question: est-il possible d’obtenir ces fichiers en utilisant fakeroot ?

Au niveau des patchs je pense que je devrais aussi également le recompiler à chaque sortie du noyau Débian car je tiens également à avoir la plus récente version disponible mais non seulement par respect pour l’équipe Débian-kernel, mais aussi parce que je leur fais aveuglément confiance vu leur qualité de travail ainsi que leur philosophie, je préfère compiler les sources Débian.

P.s: Que pensez-vous de la manière de compiler du lien que je vous ai communiqué s’il vous plait ? Ca me plairait assez d’avoir votre avis car actuellement elle est pour moi la meilleure méthode, ce qui ne veux pas dire la plus rapide mais la plus instructive. :smt003

Je vous remercie. :smt002

quote=“Squalthor”
Je peux déjà partiellement te répondre sur un point que je n’avais pas encore compris hier mais sous réserve que cette fois j’ai bien compris, ce qui n’est pas sûr:
Le mieux est de compiler à partir des sources Débian (expliqué dans le premier sujet) qui est actuellement le linux-source-2.6.18.[/quote]Non. le 2.6.18 n’est pas la version actuelle >debian<, mais pour être précis, c’est la version >etch< (ou stable). Mais dans l’absolu, on peut aussi utiliser un noyau lenny, sid, ou experimental sur une etch, ça n’a pas d’importance.[quote=“Squalthor”]Personnellement j’ai tenté pendant deux jours de compiler les sources 2.6.24-2 et j’ai rencontré un problème qui m’a empêché d’installer le pilote nvidia.[/quote]Il n’y a >à priori< pas de lien entre spécifiquement nvidia et la version de noyau, sauf que ce qui a dû te gèner, c’est que tu as dû prendre les sources etch de nvidia pour les compiler avec ton 2.6.24, or il faut prendre les sources des modules externes dans la release ou on a pris le noyau. Pour le nvidia, il faut en plus prendre le nvidia-glx qui va avec. [quote=“Squalthor”]Si tu tiens à toujours avoir la dernière version du noyau il te faudras, je supposes, soit le patcher soit recompiler les dernières sources mais ce travail peut être facilité si tu récupère le .config de ton noyau actuel.[/quote]Jamais entendu parler sous debian de patcher un noyau pour le mettre à jour. Il faut effectivement recompiler, et le meilleur moyen est effectivement de trimballer son .config de noyau en noyau. quote=“Squalthor”
Pour le moment je vais tenter de simplement compiler les sources 2.6.18 afin de résinstaller ma Débian avec que j’ai maltraitée ces derniers jours… :blush: [/quote]Même maltraitée, une debian ne se reinstalle pas, on la répare. On est pas sous windows :wink:[quote=“Squalthor”]Par contre je dois bien avouer que je ne suis pas confiant dans le fait de faire la compilation en root car j’ai toujours appris que je devais le faire en fakeroot et je n’ai pas trouvé d’explications satisfaisantes me permettant de croire que celà n’est pas dangereux.[/quote] En as tu trouvé de valable qui te dise pourquoi c’est dangereux ? La sécurité peut toujours être poussée un peu plus loin, mais il y a des moment ou il faut arbitrer entre sécurité extrême et prise de tête. Tu me diras, peut être que fakeroot est simple à utiliser, mais je n’en sais rien, je n’ai jamais ressenti le besoin de l’utiliser. [quote=“Squalthor”]Donc pour le moment je vais me concocter un noyau aux petits oignons d’après la méthode que je suit depuis quelques années (http://formation-debian.via.ecp.fr/wiki/index.php/Compiler_son_propre_noyau) à partir du noyau Débian et sans script car autrement je n’apprendras pas ou pas bien. :wink: [/quote] Trés bon reflexe d’éviter les trucs qui masquent ce qui se passe… Sauf que make-kpkg est lui même un script qui masque la manière dont se fait le make :mrgreen: [quote=“Squalthor”]EDIT:
Par contre les fichiers génerés par vote méthode décrite ici m’intérressent donc j’aurais effectivement quelques questions concernant cette méthode:[/quote] Euh, à part les erreurs encore présentes partout dans cette daube de formation debian qui n’a de debian que le nom, c’est grossièrement la même méthode. De quoi veux tu donc parler ?[quote=“Squalthor”]
Configurant moi-même les options du noyau afin d’avoir le noyau le plus rapide/petit possible n’est-il pas préferable d’installer également les sources generées ? Je supposes actuellement que c’est effectivement mieux.[/quote]D’abord, le gain de vitesse obtenu par amaigrissement du noyau est exactement le temps qu’il faut pour lire sur le disque les quelques octets que tu as réussi à économiser, ni plus, ni moins, donc autant dire que c’est insignifiant. S’il y a un gain de vitesse à obtenir en ajustant sa config noyau, c’est en choisissant des optimisations spécifiques correspondant aux composants de la machine sur laquelle on va le faire tourner (options amd avec un processeur amd, etc). Somme toute, le gain de vitesse n’est pas une bonne raison pour faire maigrir son noyau. Diminuer les possibilités de plantage ou de faille en limitant ce qu’il contient au strict nécessaire, ça, c’est une vraie raison de faire maigrir le noyau. [quote=“Squalthor”]Les autres fichiers genérés servent-ils par la suite ?
Et dernière petite question: est-il possible d’obtenir ces fichiers en utilisant fakeroot ?[/quote]Je ne vois pas du tout de quels fichiers génèrés tu parles. [quote=“Squalthor”]Au niveau des patchs je pense que je devrais aussi également le recompiler à chaque sortie du noyau Débian car je tiens également à avoir la plus récente version disponible mais non seulement par respect pour l’équipe Débian-kernel, mais aussi parce que je leur fais aveuglément confiance vu leur qualité de travail ainsi que leur philosophie, je préfère compiler les sources Débian.[/quote] :question: [quote=“Squalthor”]P.s: Que pensez-vous de la manière de compiler du lien que je vous ai communiqué s’il vous plait ? Ca me plairait assez d’avoir votre avis car actuellement elle est pour moi la meilleure méthode, ce qui ne veux pas dire la plus rapide mais la plus instructive. :smt003 [/quote]Ben déjà, la partie configuration explique comment récupèrer un noyau kernel.org, et explique longuement les options d’un noyau qui n’existe même plus dans les depots debian. Ensuite, la compilation qui se découpe en “Compilation avec ou sans modules externes” complique les choses et - à moins que ça n’ai changé - ne peut pas fonctionner telle qu’elle est décrite si on ne précise pas à make-kpkg quels sont les --added-modules. Puis, l’utilisation de 'alias ethX ’ dans un fichier de modprobe.d pour nommer une carte est limitée en cas de multiples cartes du même type, et rendue obsolète par le renommage automatique des cartes par udev. Il parle inopinément de l’install d’alsa dans cette section sur la compilation du noyau mais oublie par ailleurs de parler de update-grub, qu’il est nécessaire de lancer si celui ci n’est pas configuré comme post-install script.
Bref, ce tuto est comme à chaque fois que j’y ai mis le nez pour vérifier, faussement exhaustif, mal organisé, truffé de fautes, et partiellement obsolète.

Bonsoir et merci pour toutes ces précisions, j’y vois un peu plus clair. :smt003

Malheureusement ca me fais prendre conscience qu’il va me falloir énormément de temps pour comprendre et assimiler tout ça… :confused: Et le temps je ne l’ai malheureusement pas… :frowning:

Je vais donc laisser tomber pour le moment et m’y remettrais quand j’aurais trouvé de quoi et quand ce serât plus calme niveau boulot. :cry:

P.s: J’ai répondu bien plus tôt mais impossible d’envoyer le message, je ne sais pas d’où ca vient, et pourtant jai réi-installé… Je sais c’est pas obligatoire mais je n’ai franchement pas le temps pour localiser les multiples problèmes que j’ai crée. :blush:

Bonne continuation. :smt002

[quote=“Squalthor”]
Le mieux est de compiler à partir des sources Débian (expliqué dans le premier sujet)[/quote]

Je précise donc en plus je ne compile qu’avec les sources Debian (… courageux mais pas téméraire :stuck_out_tongue: )

J’ai donc pris les sources 2.6-24 debian à leur sortie , mais lorsque les correctifs sortent (2.6-24-1 etc…) pouvez vous me confirmer qu’il faut recompiler à nouveau à chaque fois ?

NOYAU COMPILE = NOYAU FIGE ?

( :arrow_right: ce cas de figure pourrait se poser par exemple sur un ancien noyau compilé et la mise à jour pour la “faille” shell user–>root)

quote="mattotop"
Jamais entendu parler sous debian de patcher un noyau pour le mettre à jour. Il faut effectivement recompiler, et le meilleur moyen est effectivement de trimballer son .config de noyau en noyau.
(…)[/quote]

merci, :neutral_face: désolé de ne pas avoir lu entre les lignes ce long topic