mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Mikael Petterson <mikpe@it.uu.se>,
	Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [GIT PULL] x86 setup: correct booting on 486 (revised)
Date: Mon, 05 Nov 2007 14:14:56 -0700	[thread overview]
Message-ID: <m1ir4g9yy7.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <472F7D8D.8050505@zytor.com> (H. Peter Anvin's message of "Mon, 05 Nov 2007 12:31:09 -0800")

"H. Peter Anvin" <hpa@zytor.com> writes:

> Eric W. Biederman wrote:
>>>
>>>> However, that being said, doing so is trivial, and it might help some
>>>> debugging hack; anything that makes debugging easier is a Good Thing[TM].
>>> Yeah. Even if it was just re-using the boot-time stack area temporarily, just
>>> to give code the choice to use a common set of instructions.
>>
>> If I had to do it from scratch today I would make the 32-bit entry
>> point require a stack, segments and use C calling conventions to pass
>> struct boot_params *.
>>
>> Besides %esi I'm not really fond of requiring anything in the 32bit
>> entrypoint.  At the same time I totally agree that it is always nice
>> to provide way more then you need.
>>
>
> Nailing down the interface as hard as possible is a good idea, to avoid tying
> your hands for the future.
>
> 	-hpa


I'm just saying be liberal in what you accept and conservative in what
you send.

Making the entire process well defined is useful so things don't break
unnecessarily, and the maintainers of the pieces of software that use
the interface know what they can reliably get away with and what is
just luck.

Currently using the 32-bit entry point reliably requires:
%cs to be set.
%esi to be set.
%ebx be set to 0.
%gdt to be set and have:
  0x10 a 32bit 4G code segment with base of 0
  0x18 a 32bit 4G data segment with base of 0

With the latest generation of the boot protocol if KEEP_SEGMENTS
is set then it is only required that the data segments %ds, %es, %fs,
%gs and %ss be initialized to a valid value.

I have no problem with code providing more then what is required
above, and in fact I think it is likely a good thing.

For future expansion of the protocol things will go easiest if
we don't add additional requirements to the list above, as that
is all that I think all current boot loaders provide.

Anyway this is getting off topic.  So far the changes to pmjump.S
look to be going well.

Eric

  parent reply	other threads:[~2007-11-05 21:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-05  2:16 H. Peter Anvin
2007-11-05  3:58 ` H. Peter Anvin
2007-11-05 17:15   ` Linus Torvalds
2007-11-05 17:56     ` H. Peter Anvin
2007-11-05 18:12       ` Linus Torvalds
2007-11-05 18:32         ` H. Peter Anvin
2007-11-05 18:36           ` Linus Torvalds
2007-11-05 20:21             ` Eric W. Biederman
2007-11-05 20:31               ` H. Peter Anvin
2007-11-05 20:51                 ` Jeremy Fitzhardinge
2007-11-05 21:06                   ` H. Peter Anvin
2007-11-06  0:59                     ` Jeremy Fitzhardinge
2007-11-06  1:11                       ` H. Peter Anvin
2007-11-06  1:18                         ` Jeremy Fitzhardinge
2007-11-06  1:31                           ` H. Peter Anvin
2007-11-06 16:17                             ` Jeremy Fitzhardinge
2007-11-06 16:27                               ` H. Peter Anvin
2007-11-06 16:55                                 ` Jeremy Fitzhardinge
2007-11-06 17:00                                   ` H. Peter Anvin
2007-11-06 17:09                                     ` Eric W. Biederman
2007-11-06 17:57                                       ` H. Peter Anvin
2007-11-06 18:27                                         ` Eric W. Biederman
2007-11-06 18:41                                           ` H. Peter Anvin
2007-11-06 17:04                                 ` Eric W. Biederman
2007-11-05 21:14                 ` Eric W. Biederman [this message]
2007-11-05 21:28                   ` H. Peter Anvin
2007-11-05 21:58                     ` Eric W. Biederman

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=m1ir4g9yy7.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikpe@it.uu.se \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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

all inboxes | Powered by JetHome®