je me pose des questions sur la manière dont les BSD bootent en le
comparant avec linux.
Dans le temps, linux avait besoin d'un noyau auquel on indiquait la
partition racine, soit directement en dur dans le noyau, soit à l'aide
de paramètres passés via un bootloader.
Puis, l'initrd est arrivé proposant un microsystème permettant de
rendre la racine accessible. Puis l'initramfs qui remplace complètement
le mécanisme qui monte la racine et lance le binaire /sbin/init.
Ma question, savez vous si un des BSD propose ce genre de manipulation?
Comment bootent ils en gros? Et si ils n'implémentent pas cette
méthode de boot en deux temps noyau+initramfs, pourquoi?
[le initrd de linux] Ma question, savez vous si un des BSD propose ce genre de manipulation?
NetBSD a implemente quelque chose d'un peu similaire pour pouvoir utilser un / crypte. Ca n'est utilise que pour ce cas particulier.
Comment bootent ils en gros?
Ca depend fortement de l'architecture. Sur NetBSD/x86, des informations sur le disque de boot sont passees par le boot loader au kernel, afin qu'il puisse les comparer avec les disques que ses drivers ont decouvert et retrouver le disque de boot.
Et si ils n'implémentent pas cette méthode de boot en deux temps noyau+initramfs, pourquoi?
Reponse rapide: parce qu'ils n'ont pas besoin de faire un truc aussi tordu. Reponse longue: linux a implemente ce systeme de initrd pour pouvoir charger les drivers necessaire au montage de / en module. les *BSD ont longtemps eu les drivers disque et systeme de fichier compile en statique dans le kernel, donc pas besoin de charger des modules pour pouvoir monter /. Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86 les drivers de systeme de fichiers (et a terme de controlleur de disque) sont en module. Il a donc besoin d'un module pour pouvoir monter / mais c'est le boot loader qui charge le module en meme temps que le kernel, la non plus pas besoin de initrd. Solaris utilise la meme technique.
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Kevin Denis <kevin@nowhere.invalid> wrote:
[le initrd de linux]
Ma question, savez vous si un des BSD propose ce genre de manipulation?
NetBSD a implemente quelque chose d'un peu similaire pour pouvoir utilser
un / crypte. Ca n'est utilise que pour ce cas particulier.
Comment bootent ils en gros?
Ca depend fortement de l'architecture. Sur NetBSD/x86, des informations sur le
disque de boot sont passees par le boot loader au kernel, afin qu'il
puisse les comparer avec les disques que ses drivers ont decouvert et
retrouver le disque de boot.
Et si ils n'implémentent pas cette
méthode de boot en deux temps noyau+initramfs, pourquoi?
Reponse rapide: parce qu'ils n'ont pas besoin de faire un truc aussi tordu.
Reponse longue: linux a implemente ce systeme de initrd pour pouvoir charger
les drivers necessaire au montage de / en module. les *BSD ont longtemps eu
les drivers disque et systeme de fichier compile en statique dans le kernel,
donc pas besoin de charger des modules pour pouvoir monter /.
Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86
les drivers de systeme de fichiers (et a terme de controlleur de disque)
sont en module. Il a donc besoin d'un module pour pouvoir monter / mais
c'est le boot loader qui charge le module en meme temps que le kernel,
la non plus pas besoin de initrd. Solaris utilise la meme technique.
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
[le initrd de linux] Ma question, savez vous si un des BSD propose ce genre de manipulation?
NetBSD a implemente quelque chose d'un peu similaire pour pouvoir utilser un / crypte. Ca n'est utilise que pour ce cas particulier.
Comment bootent ils en gros?
Ca depend fortement de l'architecture. Sur NetBSD/x86, des informations sur le disque de boot sont passees par le boot loader au kernel, afin qu'il puisse les comparer avec les disques que ses drivers ont decouvert et retrouver le disque de boot.
Et si ils n'implémentent pas cette méthode de boot en deux temps noyau+initramfs, pourquoi?
Reponse rapide: parce qu'ils n'ont pas besoin de faire un truc aussi tordu. Reponse longue: linux a implemente ce systeme de initrd pour pouvoir charger les drivers necessaire au montage de / en module. les *BSD ont longtemps eu les drivers disque et systeme de fichier compile en statique dans le kernel, donc pas besoin de charger des modules pour pouvoir monter /. Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86 les drivers de systeme de fichiers (et a terme de controlleur de disque) sont en module. Il a donc besoin d'un module pour pouvoir monter / mais c'est le boot loader qui charge le module en meme temps que le kernel, la non plus pas besoin de initrd. Solaris utilise la meme technique.
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
JKB
Le 05-12-2008, ? propos de Re: Boot des différents BSD, Manuel Bouyer ?crivait dans fr.comp.os.bsd :
Kevin Denis wrote:
[le initrd de linux] Ma question, savez vous si un des BSD propose ce genre de manipulation?
NetBSD a implemente quelque chose d'un peu similaire pour pouvoir utilser un / crypte. Ca n'est utilise que pour ce cas particulier.
Comment bootent ils en gros?
Ca depend fortement de l'architecture. Sur NetBSD/x86, des informations sur le disque de boot sont passees par le boot loader au kernel, afin qu'il puisse les comparer avec les disques que ses drivers ont decouvert et retrouver le disque de boot.
Sur sparc aussi.
Et si ils n'implémentent pas cette méthode de boot en deux temps noyau+initramfs, pourquoi?
Reponse rapide: parce qu'ils n'ont pas besoin de faire un truc aussi tordu. Reponse longue: linux a implemente ce systeme de initrd pour pouvoir charger les drivers necessaire au montage de / en module. les *BSD ont longtemps eu les drivers disque et systeme de fichier compile en statique dans le kernel, donc pas besoin de charger des modules pour pouvoir monter /. Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86 les drivers de systeme de fichiers (et a terme de controlleur de disque) sont en module. Il a donc besoin d'un module pour pouvoir monter / mais c'est le boot loader qui charge le module en meme temps que le kernel, la non plus pas besoin de initrd. Solaris utilise la meme technique.
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est compréhensible, mais pour la racine, je ne comprends pas. Si le pilote fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger. Alors pourquoi donc vouloir à tout prix ne pas avoir ce qu'il faut en statique ? Et la réponse n'est pas une taille maximale de noyau, parce que si ce sont les seuls pilotes en dur dans le noyau, cela ne va pas chercher loin...
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 05-12-2008, ? propos de
Re: Boot des différents BSD,
Manuel Bouyer ?crivait dans fr.comp.os.bsd :
Kevin Denis <kevin@nowhere.invalid> wrote:
[le initrd de linux]
Ma question, savez vous si un des BSD propose ce genre de manipulation?
NetBSD a implemente quelque chose d'un peu similaire pour pouvoir utilser
un / crypte. Ca n'est utilise que pour ce cas particulier.
Comment bootent ils en gros?
Ca depend fortement de l'architecture. Sur NetBSD/x86, des informations sur le
disque de boot sont passees par le boot loader au kernel, afin qu'il
puisse les comparer avec les disques que ses drivers ont decouvert et
retrouver le disque de boot.
Sur sparc aussi.
Et si ils n'implémentent pas cette
méthode de boot en deux temps noyau+initramfs, pourquoi?
Reponse rapide: parce qu'ils n'ont pas besoin de faire un truc aussi tordu.
Reponse longue: linux a implemente ce systeme de initrd pour pouvoir charger
les drivers necessaire au montage de / en module. les *BSD ont longtemps eu
les drivers disque et systeme de fichier compile en statique dans le kernel,
donc pas besoin de charger des modules pour pouvoir monter /.
Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86
les drivers de systeme de fichiers (et a terme de controlleur de disque)
sont en module. Il a donc besoin d'un module pour pouvoir monter / mais
c'est le boot loader qui charge le module en meme temps que le kernel,
la non plus pas besoin de initrd. Solaris utilise la meme technique.
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique
dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est
compréhensible, mais pour la racine, je ne comprends pas. Si le pilote
fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
Alors pourquoi donc vouloir à tout prix ne pas avoir ce qu'il faut en
statique ? Et la réponse n'est pas une taille maximale de noyau, parce
que si ce sont les seuls pilotes en dur dans le noyau, cela ne va pas
chercher loin...
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 05-12-2008, ? propos de Re: Boot des différents BSD, Manuel Bouyer ?crivait dans fr.comp.os.bsd :
Kevin Denis wrote:
[le initrd de linux] Ma question, savez vous si un des BSD propose ce genre de manipulation?
NetBSD a implemente quelque chose d'un peu similaire pour pouvoir utilser un / crypte. Ca n'est utilise que pour ce cas particulier.
Comment bootent ils en gros?
Ca depend fortement de l'architecture. Sur NetBSD/x86, des informations sur le disque de boot sont passees par le boot loader au kernel, afin qu'il puisse les comparer avec les disques que ses drivers ont decouvert et retrouver le disque de boot.
Sur sparc aussi.
Et si ils n'implémentent pas cette méthode de boot en deux temps noyau+initramfs, pourquoi?
Reponse rapide: parce qu'ils n'ont pas besoin de faire un truc aussi tordu. Reponse longue: linux a implemente ce systeme de initrd pour pouvoir charger les drivers necessaire au montage de / en module. les *BSD ont longtemps eu les drivers disque et systeme de fichier compile en statique dans le kernel, donc pas besoin de charger des modules pour pouvoir monter /. Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86 les drivers de systeme de fichiers (et a terme de controlleur de disque) sont en module. Il a donc besoin d'un module pour pouvoir monter / mais c'est le boot loader qui charge le module en meme temps que le kernel, la non plus pas besoin de initrd. Solaris utilise la meme technique.
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est compréhensible, mais pour la racine, je ne comprends pas. Si le pilote fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger. Alors pourquoi donc vouloir à tout prix ne pas avoir ce qu'il faut en statique ? Et la réponse n'est pas une taille maximale de noyau, parce que si ce sont les seuls pilotes en dur dans le noyau, cela ne va pas chercher loin...
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
naddy
Manuel Bouyer wrote:
Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86 les drivers de systeme de fichiers (et a terme de controlleur de disque) sont en module. Il a donc besoin d'un module pour pouvoir monter / mais c'est le boot loader qui charge le module en meme temps que le kernel, la non plus pas besoin de initrd. Solaris utilise la meme technique.
FreeBSD aussi.
Je ne crois pas qu'il soit possible de mettre UFS en module sur FreeBSD, mais c'est bien possible avec des pilotes SCSI, ATA, etc., depuis une dizaine d'années.
-- Christian "naddy" Weisgerber
Manuel Bouyer <bouyer@nerim.net> wrote:
Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86
les drivers de systeme de fichiers (et a terme de controlleur de disque)
sont en module. Il a donc besoin d'un module pour pouvoir monter / mais
c'est le boot loader qui charge le module en meme temps que le kernel,
la non plus pas besoin de initrd. Solaris utilise la meme technique.
FreeBSD aussi.
Je ne crois pas qu'il soit possible de mettre UFS en module sur
FreeBSD, mais c'est bien possible avec des pilotes SCSI, ATA, etc.,
depuis une dizaine d'années.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86 les drivers de systeme de fichiers (et a terme de controlleur de disque) sont en module. Il a donc besoin d'un module pour pouvoir monter / mais c'est le boot loader qui charge le module en meme temps que le kernel, la non plus pas besoin de initrd. Solaris utilise la meme technique.
FreeBSD aussi.
Je ne crois pas qu'il soit possible de mettre UFS en module sur FreeBSD, mais c'est bien possible avec des pilotes SCSI, ATA, etc., depuis une dizaine d'années.
-- Christian "naddy" Weisgerber
Patrick Lamaizière
JKB:
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est compréhensible, mais pour la racine, je ne comprends pas. Si le pilote fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
C'est quoi un oops ?
JKB:
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique
dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est
compréhensible, mais pour la racine, je ne comprends pas. Si le pilote
fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est compréhensible, mais pour la racine, je ne comprends pas. Si le pilote fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
C'est quoi un oops ?
espie
In article , Patrick Lamaizière wrote:
JKB:
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est compréhensible, mais pour la racine, je ne comprends pas. Si le pilote fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
C'est quoi un oops ?
Le cri du pingouin quand il se pisse dessus.
(une panique, si tu preferes).
In article <Xns21C511DB2A003plam@dave.invalid>,
Patrick Lamaizière <patnews1@davenulle.org> wrote:
JKB:
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique
dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est
compréhensible, mais pour la racine, je ne comprends pas. Si le pilote
fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est compréhensible, mais pour la racine, je ne comprends pas. Si le pilote fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
C'est quoi un oops ?
Le cri du pingouin quand il se pisse dessus.
(une panique, si tu preferes).
espie
In article <ghbuqi$2l1k$, Christian Weisgerber wrote:
Manuel Bouyer wrote:
Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86 les drivers de systeme de fichiers (et a terme de controlleur de disque) sont en module. Il a donc besoin d'un module pour pouvoir monter / mais c'est le boot loader qui charge le module en meme temps que le kernel, la non plus pas besoin de initrd. Solaris utilise la meme technique.
FreeBSD aussi.
Je ne crois pas qu'il soit possible de mettre UFS en module sur FreeBSD, mais c'est bien possible avec des pilotes SCSI, ATA, etc., depuis une dizaine d'années.
Et OpenBSD non plus.
Autant pour certains trucs, je peux comprendre l'interet des modules, autant la, j'avoue, surtout sur les machines recentes, je ne vois vraiment pas l'interet pratique.
In article <ghbuqi$2l1k$1@lorvorc.mips.inka.de>,
Christian Weisgerber <naddy@mips.inka.de> wrote:
Manuel Bouyer <bouyer@nerim.net> wrote:
Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86
les drivers de systeme de fichiers (et a terme de controlleur de disque)
sont en module. Il a donc besoin d'un module pour pouvoir monter / mais
c'est le boot loader qui charge le module en meme temps que le kernel,
la non plus pas besoin de initrd. Solaris utilise la meme technique.
FreeBSD aussi.
Je ne crois pas qu'il soit possible de mettre UFS en module sur
FreeBSD, mais c'est bien possible avec des pilotes SCSI, ATA, etc.,
depuis une dizaine d'années.
Et OpenBSD non plus.
Autant pour certains trucs, je peux comprendre l'interet des modules, autant
la, j'avoue, surtout sur les machines recentes, je ne vois vraiment pas
l'interet pratique.
In article <ghbuqi$2l1k$, Christian Weisgerber wrote:
Manuel Bouyer wrote:
Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86 les drivers de systeme de fichiers (et a terme de controlleur de disque) sont en module. Il a donc besoin d'un module pour pouvoir monter / mais c'est le boot loader qui charge le module en meme temps que le kernel, la non plus pas besoin de initrd. Solaris utilise la meme technique.
FreeBSD aussi.
Je ne crois pas qu'il soit possible de mettre UFS en module sur FreeBSD, mais c'est bien possible avec des pilotes SCSI, ATA, etc., depuis une dizaine d'années.
Et OpenBSD non plus.
Autant pour certains trucs, je peux comprendre l'interet des modules, autant la, j'avoue, surtout sur les machines recentes, je ne vois vraiment pas l'interet pratique.
Kevin Denis
Le 05-12-2008, JKB a écrit :
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique dans un noyau ce qu'il faut pour monter la racine.
Trois cas concrets: -racine chiffrée. Il faut bien demander le mot de passe à l'utilisateur. -réseau à mot de passe. Genre un nfsroot over Wifi qui demande un mot de passe. -Une racine distante située sur un périphérique qui met du temps à apparaître (typiquement une racine sur USB dont le bus met des plombes à se réveiller). Soit tu mets un timer long comme la mort pour être sur que la racine soit apparente, soit tu mets en oeuvre un système plus malin.
Alors pourquoi donc vouloir à tout prix ne pas avoir ce qu'il faut en statique ? Et la réponse n'est pas une taille maximale de noyau, parce que si ce sont les seuls pilotes en dur dans le noyau, cela ne va pas chercher loin...
Il y a 20 ans, effectivement, c'était simple. La racine était soit sur un disque, soit en nfs. Aujourd'hui, c'est tout de même plus vaste que ça. L'initramfs permet donc de répondre à ces nouvelles problématiques de manière judicieuse. -- Kevin
Le 05-12-2008, JKB <knatschke@koenigsberg.fr> a écrit :
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique
dans un noyau ce qu'il faut pour monter la racine.
Trois cas concrets:
-racine chiffrée. Il faut bien demander le mot de passe à l'utilisateur.
-réseau à mot de passe. Genre un nfsroot over Wifi qui demande un mot
de passe.
-Une racine distante située sur un périphérique qui met du temps à
apparaître (typiquement une racine sur USB dont le bus met des plombes
à se réveiller). Soit tu mets un timer long comme la mort pour être sur
que la racine soit apparente, soit tu mets en oeuvre un système plus
malin.
Alors pourquoi donc vouloir à tout prix ne pas avoir ce qu'il faut en
statique ? Et la réponse n'est pas une taille maximale de noyau, parce
que si ce sont les seuls pilotes en dur dans le noyau, cela ne va pas
chercher loin...
Il y a 20 ans, effectivement, c'était simple. La racine était soit sur
un disque, soit en nfs. Aujourd'hui, c'est tout de même plus vaste que
ça. L'initramfs permet donc de répondre à ces nouvelles problématiques
de manière judicieuse.
--
Kevin
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique dans un noyau ce qu'il faut pour monter la racine.
Trois cas concrets: -racine chiffrée. Il faut bien demander le mot de passe à l'utilisateur. -réseau à mot de passe. Genre un nfsroot over Wifi qui demande un mot de passe. -Une racine distante située sur un périphérique qui met du temps à apparaître (typiquement une racine sur USB dont le bus met des plombes à se réveiller). Soit tu mets un timer long comme la mort pour être sur que la racine soit apparente, soit tu mets en oeuvre un système plus malin.
Alors pourquoi donc vouloir à tout prix ne pas avoir ce qu'il faut en statique ? Et la réponse n'est pas une taille maximale de noyau, parce que si ce sont les seuls pilotes en dur dans le noyau, cela ne va pas chercher loin...
Il y a 20 ans, effectivement, c'était simple. La racine était soit sur un disque, soit en nfs. Aujourd'hui, c'est tout de même plus vaste que ça. L'initramfs permet donc de répondre à ces nouvelles problématiques de manière judicieuse. -- Kevin
Kevin Denis
Le 05-12-2008, Patrick Lamaizière a écrit :
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est compréhensible, mais pour la racine, je ne comprends pas. Si le pilote fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
C'est quoi un oops ?
Ce qui précède un kernel panix. -- Kevin
Le 05-12-2008, Patrick Lamaizière <patnews1@davenulle.org> a écrit :
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique
dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est
compréhensible, mais pour la racine, je ne comprends pas. Si le pilote
fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est compréhensible, mais pour la racine, je ne comprends pas. Si le pilote fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
C'est quoi un oops ?
Ce qui précède un kernel panix. -- Kevin
Kevin Denis
Le 05-12-2008, Manuel Bouyer a écrit :
Et si ils n'implémentent pas cette méthode de boot en deux temps noyau+initramfs, pourquoi?
Reponse rapide: parce qu'ils n'ont pas besoin de faire un truc aussi tordu. Reponse longue: linux a implemente ce systeme de initrd pour pouvoir charger les drivers necessaire au montage de / en module.
Mais pas que.
les *BSD ont longtemps eu les drivers disque et systeme de fichier compile en statique dans le kernel, donc pas besoin de charger des modules pour pouvoir monter /. Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86 les drivers de systeme de fichiers (et a terme de controlleur de disque) sont en module. Il a donc besoin d'un module pour pouvoir monter / mais c'est le boot loader qui charge le module en meme temps que le kernel, la non plus pas besoin de initrd. Solaris utilise la meme technique.
Ok. -- Kevin
Le 05-12-2008, Manuel Bouyer <bouyer@nerim.net> a écrit :
Et si ils n'implémentent pas cette
méthode de boot en deux temps noyau+initramfs, pourquoi?
Reponse rapide: parce qu'ils n'ont pas besoin de faire un truc aussi tordu.
Reponse longue: linux a implemente ce systeme de initrd pour pouvoir charger
les drivers necessaire au montage de / en module.
Mais pas que.
les *BSD ont longtemps eu
les drivers disque et systeme de fichier compile en statique dans le kernel,
donc pas besoin de charger des modules pour pouvoir monter /.
Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86
les drivers de systeme de fichiers (et a terme de controlleur de disque)
sont en module. Il a donc besoin d'un module pour pouvoir monter / mais
c'est le boot loader qui charge le module en meme temps que le kernel,
la non plus pas besoin de initrd. Solaris utilise la meme technique.
Et si ils n'implémentent pas cette méthode de boot en deux temps noyau+initramfs, pourquoi?
Reponse rapide: parce qu'ils n'ont pas besoin de faire un truc aussi tordu. Reponse longue: linux a implemente ce systeme de initrd pour pouvoir charger les drivers necessaire au montage de / en module.
Mais pas que.
les *BSD ont longtemps eu les drivers disque et systeme de fichier compile en statique dans le kernel, donc pas besoin de charger des modules pour pouvoir monter /. Le systeme de modules de NetBSD a recemment ete revu, et maintenant pour x86 les drivers de systeme de fichiers (et a terme de controlleur de disque) sont en module. Il a donc besoin d'un module pour pouvoir monter / mais c'est le boot loader qui charge le module en meme temps que le kernel, la non plus pas besoin de initrd. Solaris utilise la meme technique.
Ok. -- Kevin
JKB
Le 05-12-2008, ? propos de Re: Boot des différents BSD, Kevin Denis ?crivait dans fr.comp.os.bsd :
Le 05-12-2008, Patrick Lamaizière a écrit :
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est compréhensible, mais pour la racine, je ne comprends pas. Si le pilote fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
C'est quoi un oops ?
Ce qui précède un kernel panix.
Non, pas forcément. Un Oops, c'est un plantage d'une partie non cruciale du noyau (du style pilote foireux d'une carte son) qui n'empêche pas d'arrêter correctementle système. Un panic, c'est un peu plus violent.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 05-12-2008, ? propos de
Re: Boot des différents BSD,
Kevin Denis ?crivait dans fr.comp.os.bsd :
Le 05-12-2008, Patrick Lamaizière <patnews1@davenulle.org> a écrit :
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique
dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est
compréhensible, mais pour la racine, je ne comprends pas. Si le pilote
fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
C'est quoi un oops ?
Ce qui précède un kernel panix.
Non, pas forcément. Un Oops, c'est un plantage d'une partie non
cruciale du noyau (du style pilote foireux d'une carte son) qui
n'empêche pas d'arrêter correctementle système. Un panic, c'est un peu
plus violent.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 05-12-2008, ? propos de Re: Boot des différents BSD, Kevin Denis ?crivait dans fr.comp.os.bsd :
Le 05-12-2008, Patrick Lamaizière a écrit :
Je me suis _toujours_ demandé pourquoi ne pas mettre en statique dans un noyau ce qu'il faut pour monter la racine. Pour le reste, c'est compréhensible, mais pour la racine, je ne comprends pas. Si le pilote fait un oops, de toute façon, c'est mort, on ne pourra pas le recharger.
C'est quoi un oops ?
Ce qui précède un kernel panix.
Non, pas forcément. Un Oops, c'est un plantage d'une partie non cruciale du noyau (du style pilote foireux d'une carte son) qui n'empêche pas d'arrêter correctementle système. Un panic, c'est un peu plus violent.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
