Re: [GIT PULL] x86 setup: correct booting on 486 (revised)

[ebiederm@xmission.com (Eric W. Biederman)]

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

> Eric W. Biederman wrote:
>>
>> I'm just saying be liberal in what you accept and conservative in what
>> you send.
>>
>
> Absolutely.
>
>> 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
>>
>
> Actually, I suspect the currently code will handle %ebx with any value, but some
> older kernels might not handle that correctly.

Correct.  So a bootloader must set %ebx to zero to handle those older kernels.
Since it has always been this way we can count on it.

>> 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.
>
> Specifying now that unused GPRs should be zeroed will allow for changes if and
> when we need it.  It's an easy requirement to fulfill, so boot loader authors
> can put it through the pipe now.  Then, if we find ourselves in a corner in the
> future, we have a possible out.

Sure it is reasonable to ask for.  The bootloader pipe is awfully long though.
But putting it in at the time we clean up the rules for the 32bit entry point
is the best chance we are going to get to be able to change things.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/