public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Booting a modular kernel through a multiple streams file / Making Linux multiboot capable and grub loading kernel modules at boot time.
Date: Wed, 19 Dec 2001 22:57:55 -0800	[thread overview]
Message-ID: <3C218BF3.6010603@zytor.com> (raw)
In-Reply-To: <200112181605.KAA00820@tomcat.admin.navo.hpc.mil>	<m18zbzwp34.fsf@frodo.biederman.org> <3C205FBC.60307@zytor.com>	<m1zo4fursh.fsf@frodo.biederman.org>	<9vrlef$mat$1@cesium.transmeta.com> <m1r8pqv1w3.fsf@frodo.biederman.org>

Eric W. Biederman wrote:

> 
>>Followup to:  <m1zo4fursh.fsf@frodo.biederman.org>
>>By author:    ebiederm@xmission.com (Eric W. Biederman)
>>In newsgroup: linux.dev.kernel
>>
>>>Which just goes to show what a fragile firmware design it is, to have
>>>firmware callbacks doing device I/O.  I think the whole approach of
>>>having firmware callbacks is fundamentally flawed but I'll do my best
>>>to keep it working, for those things that care.  If it works over 50%
>>>of the time I'm happy...
>>>
>>>
>>NAK.  You can make it perfectly robust thankyouverymuch, as long as
>>you don't try to *mix* firmware and poking directly at the
>>hardware... this is a classic "who owns what" class problem.
>>
> 
> I agree that I could keep it working as well as it ever would.  Not
> that x86 firmware or any software is ever perfectly working.
> 


True enough; I guess what I meant is you can design it so that it is *no 
less unreliable than the underlying firmware*.


> At this point in time I live in a world where 99+% of the time the
> hardware is owned by the operating system, and the firmware is just
> there to get the operating system loaded, and to hold details about
> the motherboard that the operating system can not find out by probing
> the hardware.


Right.  My point was that you want to treat the transition as modal -- 
you have "boot mode" and you have "runtime".  My work was to build a 
Linux kernel derivative which could run in "boot mode" and therefore not 
require drivers.  The intent was that this "boot mode" kernel would then 
load the real "runtime" kernel and transition to it.

My comment was mostly that there is a persistent myth that you can't use 
the x86 firmware from protected mode.  You can't, directly, but you can 
get the functionality through other means.  This is hardly a new 
technique; in fact, it's very similar to the DOS extenders of old times; 
in fact, it's somewhat simpler.

	-hpa



  reply	other threads:[~2001-12-20  6:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-18 16:05 Booting a modular kernel through a multiple streams file / Making Linux multiboot capable and grub loading kernel modules at boot time Jesse Pollard
     [not found] ` <m1r8prwuv7.fsf@frodo.biederman.org>
     [not found]   ` <3C204282.3000504@zytor.com>
     [not found]     ` <m1itb3wsld.fsf@frodo.biederman.org>
     [not found]       ` <3C2052C0.2010700@zytor.com>
2001-12-19  9:12         ` Eric W. Biederman
2001-12-19  9:37           ` H. Peter Anvin
2001-12-19 15:57             ` Eric W. Biederman
2001-12-20  3:20               ` H. Peter Anvin
2001-12-20  6:31                 ` Eric W. Biederman
2001-12-20  6:57                   ` H. Peter Anvin [this message]
2001-12-20 16:39                     ` Eric W. Biederman
2001-12-20 18:35                       ` H. Peter Anvin
2001-12-21 16:57                         ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2001-12-17 22:10 Booting a modular kernel through a multiple streams file Grover, Andrew
2001-12-18 15:26 ` Booting a modular kernel through a multiple streams file / Making Linux multiboot capable and grub loading kernel modules at boot time Christian Koenig
2001-12-18 18:32   ` H. Peter Anvin

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=3C218BF3.6010603@zytor.com \
    --to=hpa@zytor.com \
    --cc=ebiederm@xmission.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox