Takeshi Sone ts1@tsn.or.jp writes:
On Fri, Dec 19, 2003 at 12:49:42AM -0700, Eric W. Biederman wrote:
Adam Sulmicki adam@cfar.umd.edu writes:
you mean just like dosemu runs under linux ???
Right but for BSD and early versions of windows the dependencies were worse. I don't know which services matter though.
Last time I saw the source code of FreeBSD, its _bootloader_ has its own vm86 monitor (in assembly), works in protected mode, and calls all the BIOS calls (video, keyboard, disk,...) in vm86 mode. Also the kernel calls E820, APM, VESA, etc in vm86. Also I saw a recent version of Windows calls BIOS services in vm86.
Maybe we can modify FreeBSD, and have work-around for Windows, but at least I don't think it's the way to go.
Thanks. I knew this was the biggest danger, and from the description it looks like no half measures will do.
My conclusion then was that PCBIOS had to work in real mode.
If that is the case the PCBIOS has hit an evolutionary dead, as the code size cannot increase, there is very little room for change remaining. This explains ACPI. And it makes EFI look much more attractive.
I think I see one way out of this pickle, implement the firmware in System Management mode. System calls will be slow and we will need an interrupt reflector but this does allow us to escape the bounds of vm86 mode, and the legacy limitations. And our OS will even have some protection from ``user mode''.
System Management mode is essentially big real mode. So code would need to be compiled with .code16gcc, but there is a full 4G available. I know with amd's processors I can switch to 32bit or 64bit protected mode inside of smm mode, Intel's documentation is not clear on that point, so I don't know what we can do there. Depending on what works it may make sense simply to build an smm mode trampoline to get out of vm86 mode.
Maybe we can code it with GCC and .code16gcc hack. If 64KB is not enough, maybe 0xE000 segment can be used so that we have 64KB code and 64KB data segments. And all the "POST" code can be outside the real mode space. So it's not impossible or hard at all.
For just PCBIOS compatibility I agree. Primarily I want that layer to exist as an add-on and an after thought. Something that gives backwards compatibility but allows us to do something better.
With only 256KB of room, there simply is not enough room to implement drivers of interesting hardware. Nor is there enough room to implement interesting protocol stacks. And it limits what we can do in the future.
Eric