Re: [NILO-discuss] Zen and the art of running in real mode

[H. P. A. <hp...@zy...>]

Marty Connor wrote:
> 
> Drivers we can fix.  Older ones are probably simpler anyway, and newer 
> ones probably use inX/outX already.
> 

Not all drivers *can* be modified to use in/out (i.e. portio) as opposed 
to read/write (i.e. MMIO.)  It's a function of the hardware.

> 
> If you say so :)  Sounds like a somewhat fragile hack, but sometimes 
> that's all we've got that gets the job done.
> 

It's not fragile, you just have to put the proper entry point code at 
both the 16- and the 32-bit entry point.

>> I appreciate that all this is quite involved, so I'm going to attempt a
>> brief summary:
>>
>> o  We can support genuine real-mode operation, V86-mode operation and the
>>    PXE-specified 16-bit protected-mode operation.
>> o  Doing this gives us compatibility with FreeBSD and with any
>>    as-yet-undiscovered program that uses the PM entry point.
> 
> Are things that do this "broken" or "violating the spec" somehow?
> 
> What I'm getting at, is how hard we should try to get people to fix 
> their code to work with ours?  I can already hear comments like "well it 
> works with my Intel boot ROM on my eepro100... and also with my 3C905 
> MBA Boot ROM..."   It would be nice to have some good reasons why they 
> should fix it.

Perhaps the first thing to do is to print a legible message if something 
tries to call the PM entry point and/or invoke the RM entry point in V86 
mode.  Something asking them to report what they're trying to do, and we 
could evaluate the importance at that point.

	-hpa