Date: Wed, 14 Oct 2009 23:53:15 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: xcllnt@mac.com Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, jhb@FreeBSD.org Subject: Re: svn commit: r197969 - head/sys/conf Message-ID: <20091014.235315.62961324.imp@bsdimp.com> In-Reply-To: <ECC72CAB-DE06-4921-B228-1DB72F8B9247@mac.com> References: <200910141738.43910.jhb@freebsd.org> <20091014.224434.-345402487.imp@bsdimp.com> <ECC72CAB-DE06-4921-B228-1DB72F8B9247@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <ECC72CAB-DE06-4921-B228-1DB72F8B9247@mac.com>
Marcel Moolenaar <xcllnt@mac.com> writes:
:
: 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.
inb, etc, aren't part of bus_space and exist outside of it. These
functions typically don't exist on !x86 platforms, and when they do
they are very platform specific..
: 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.
The PCI specification says that the frame buffer is at 0xa0000 in the
pci bus space. It doesn't say anything about how that bus space is
mapped into the processor's address space (although it comments on
x86's traditional mapping in many places).
: 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.
There is a real need for orm. I'm open to ways to improve the
situation without requiring the complete implementation of the ISA
stuff. The reason that it does wreck havoc is because there's
problems in the ISA implementation on the platforms it wrecks havoc
on. You can mask these problems by removing orm. However, any other
isa device that reads memory will have issues on these platforms.
The VGA resource issue should be a simple one to deal with via
bus_spae. This is the first time I've heard of it, frankly, so would
be interested in learning more about it.
We've also, as a project, have strongly encouraged drivers to move
away from inb, et al, and direct memory access to using bus_space
interfaces since around FreeBSD 4.0. Many drivers have been
converted. I think the few stragglers were killed as part of the
network modernization efforts, although some pre-ISA PNP support still
uses inb/outb directly.
I think I'd quibble that it is !x86. It is specific to powerpc and
itanium platforms. Sparc64 handles it correctly, as does arm (at east
in the projects/arm tree). I don't think that mips has any ISA
support, even in the projects/mips tree.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091014.235315.62961324.imp>