svn commit: r197969 - head/sys/conf

[Marcel Moolenaar]

On Oct 14, 2009, at 9:44 PM, M. Warner Losh wrote:
> This is also the source of my frustration with the thread, I think.  I
> don't think that Marcel understood this world view and assumed that no
> mapping was needed and therefore orm was this horribly x86 specific
> code.  Since I didn't understand this until today, I reacted badly and
> lost my temper, for which I'd like to apologize.  I should have
> stopped and explained this view better.

Apology accepted. Sorry, if I appeared frustrated as well.

I can respect the PoV that the hardcoding in drivers are bus addresses.
I have no problem with that. It isn't my PoV, because it doesn't match
with the existence of functions like inb(), outb(), inw(), outw(), etc.
The I/O port numbers passed to those functions are typically absolute
due to the total lack of newbus involvement. I merely extrapolated the
memory addresses as behaving in the same way. They do actually, because
VGA frame buffer memory is at 0xA0000 and part of the PCI specification
and you don't want to translate that, so how does MD code know when to
map and when not to? It doesn't, so the only logical interpretation is
that the addresses are absolute and no mapping can be done.

I don't mind changing the interpretation of I/O ports and memory
addresses as being ISA bus addresses, but that means that we need to
get rid off inb(), outb(), et al and use newbus through out. Until
that's done (and people figure out how to deal with VGA resources) or
there's a real need for orm(4), it's safest for non-PC platforms to not
have orm(4) wreck havoc.

-- 
Marcel Moolenaar
xcllnt at mac.com