From: Jamie Lokier <lk@tantalophile.demon.co.uk>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Grover, Andrew" <andrew.grover@intel.com>,
"'Russell Coker'" <russell@coker.com.au>,
"\"Acpi-linux (E-mail)\""
<acpi@phobos.fachschaften.tu-muenchen.de>,
"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: lilo vs other OS bootloaders was: FreeBSD makes progress
Date: Sat, 1 Sep 2001 16:50:42 +0100 [thread overview]
Message-ID: <20010901165042.B1624@thefinal.cern.ch> (raw)
In-Reply-To: <4148FEAAD879D311AC5700A0C969E89006CDE0DB@orsmsx35.jf.intel.com> <E15cx6w-00049f-00@the-village.bc.nu>
In-Reply-To: <E15cx6w-00049f-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Aug 31, 2001 at 11:50:02PM +0100
Alan Cox wrote:
> All the discussion we have has been based on seriously enhancing and
> expanding the use of the initrd/ramfs layer. Remember we can begin running
> from ramfs without interrupts, pci bus scans or the like. The things it cant
> do are - pick a kernel by processor type, pick SMP/non SMP.
The kernel could be chosen by processor type, if you added a "reboot
into a new kernel" function.
It would be rather large for one initramfs, as _all_ of the modules have
combinations of SMP/non-SMP x i386/486/586/686/athlon/686-PAE versions,
not just the core kernel.
It may still be a useful function for CDROM or network boots though.
I.e. initramfs selects an optimised kernel and set of modules to run,
and replaces the current generic kernel with the optimised one.
-- Jamie
next prev parent reply other threads:[~2001-09-01 17:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-31 21:49 lilo vs other OS bootloaders was: FreeBSD makes progress Grover, Andrew
2001-08-31 22:40 ` Andreas Dilger
2001-08-31 22:50 ` Alan Cox
2001-09-01 15:50 ` Jamie Lokier [this message]
2001-09-08 17:55 ` Eric W. Biederman
2001-09-08 18:55 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2001-09-01 14:55 Samium Gromoff
2001-09-01 12:03 ` Peter Wächtler
2001-09-01 12:39 ` Alan Cox
2001-09-01 14:10 ` Rik van Riel
2001-09-04 21:52 Grover, Andrew
2001-09-05 1:51 ` David S. Miller
2001-09-05 8:03 ` Helge Hafting
2001-09-05 14:26 ` Horst von Brand
2001-09-11 22:48 ` Pavel Machek
2001-09-05 21:18 Grover, Andrew
2001-09-05 22:11 ` Alan Cox
2001-09-05 22:13 ` Tim Hockin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010901165042.B1624@thefinal.cern.ch \
--to=lk@tantalophile.demon.co.uk \
--cc=acpi@phobos.fachschaften.tu-muenchen.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andrew.grover@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=russell@coker.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.