mais à part jouer à c'est moi qui ait la plus grosse ca sert à quoi de gagner 3 secondes sur un boot ?
Dans le cadre d'une application embarquée sur base de noyau Linux, cela permet d'éviter de sucer la batterie avec une veille ou d'implémenter un système "compliqué" soit à base de (S)RAM rafraîchie pour maintenir le système dans un état donné une fois le processeur "arrêté".
Je suis en ce moment en train de bosser sur une telle appli' embarquée, et l'application doit être économe en courant ET répondre rapidement à un évènement extérieur.
Dans ce genre d'application embarquée, la première chose qu'on fait, c'est réduire le noyau au maximum, avec seulement les périphériques utiles et les démons vitaux, mais cela n'est pas toujours chose aisée, car les pilotes sont parfois écrits d'une certaine manière qui oblige à compiler le support pour 30 périphériques dérivés d'un contrôleur alors qu'un seul nous intéresse, et par là-même impose la détection de ces 30 possibilités au démarrage.
[^] # Re: "L'optimisation de l'image du noyau au démarrage"
Posté par Sylvain Briole . En réponse à la dépêche Sortie du noyau Linux 2.6.17. Évalué à 9.
Dans le cadre d'une application embarquée sur base de noyau Linux, cela permet d'éviter de sucer la batterie avec une veille ou d'implémenter un système "compliqué" soit à base de (S)RAM rafraîchie pour maintenir le système dans un état donné une fois le processeur "arrêté".
Je suis en ce moment en train de bosser sur une telle appli' embarquée, et l'application doit être économe en courant ET répondre rapidement à un évènement extérieur.
Dans ce genre d'application embarquée, la première chose qu'on fait, c'est réduire le noyau au maximum, avec seulement les périphériques utiles et les démons vitaux, mais cela n'est pas toujours chose aisée, car les pilotes sont parfois écrits d'une certaine manière qui oblige à compiler le support pour 30 périphériques dérivés d'un contrôleur alors qu'un seul nous intéresse, et par là-même impose la détection de ces 30 possibilités au démarrage.