All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: lilo vs other OS bootloaders was: FreeBSD makes progress
Date: 8 Sep 2001 11:55:04 -0700	[thread overview]
Message-ID: <9ndpi8$64u$1@cesium.transmeta.com> (raw)
In-Reply-To: <E15cx6w-00049f-00@the-village.bc.nu> <m1iteth8j8.fsf@frodo.biederman.org>

Followup to:  <m1iteth8j8.fsf@frodo.biederman.org>
By author:    ebiederm@xmission.com (Eric W. Biederman)
In newsgroup: linux.dev.kernel
>
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
> > > So of course I realize this wouldn't happen any time soon, but has any
> > > discussion taken place regarding enhancing the bootloader (grub? Steal
> > > FreeBSD's?) to load modular drivers very early, and possibly abstracting
> > > SMP/UP from the kernel proper? Wouldn't this be a better solution than
> > > initrd?
> > 
> > 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.
> > 
> > As it happens both of those are things that are deeply buried in the whole
> > compile choices and how we generate the code itself - so they do need to
> > be boot loader driven (or user driven)
> > 
> > So the path for ACPI could indeed go
> > 
> > load kernel
> > load initial ramfs
> > Discover we have ACPI
> > load acpi core
> > load acpi irq router
> > load acpi timers
> > [init hardware]
> > load ide disk
> > load ext3
> > mount /
> 
> Sounds about right.  
> 
> If we really need to do weird things like pick a kernel by processor
> type, or pick SMP/non SMP.  You can even do those from an initramfs
> with a linux  booting linux kernel patch.
> 

I discussed something like this before using "Genesis"; the idea
behind it was to make sure we have enough modules to access the
filesystem before the kernel starts (by using pre-initialization code
that can read filesystem using the firmware interface.)  Unfortunately
life got busy on me, but I still think that it is probably the right
way to approach this.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

  reply	other threads:[~2001-09-08 18:55 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
2001-09-08 17:55   ` Eric W. Biederman
2001-09-08 18:55     ` H. Peter Anvin [this message]
  -- 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='9ndpi8$64u$1@cesium.transmeta.com' \
    --to=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.