From owner-freebsd-hackers  Sat Sep 30 05:52:39 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id FAA29405
          for hackers-outgoing; Sat, 30 Sep 1995 05:52:39 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA29400
          for <hackers@freebsd.org>; Sat, 30 Sep 1995 05:52:24 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA02664; Sat, 30 Sep 1995 22:50:18 +1000
Date: Sat, 30 Sep 1995 22:50:18 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199509301250.WAA02664@godzilla.zeta.org.au>
To: bde@zeta.org.au, davidg@Root.COM
Subject: Re: correctness of isa.c
Cc: hackers@freebsd.org, julian@ref.tfs.com
Sender: owner-hackers@freebsd.org
Precedence: bulk

>   It has no i386 dependencies as far as the interface of the function, but the
>function itself has almost no independencies. :-)

This makes it (pmap_mapdev()) like cpu_switch() - machine-dependent internally
but worth having for all arch's.

>>  Why doesn't VM distinguish between the types of physical and virtual
>>addresses?

>   I don't understand this question. Different types? Do you mean kernel/user
>or managed/unmanaged, or what?

The same C type, vm_offset_t, is used for both physical and virtual
addresses.  This is bad if physical addresses have a different number of
bits than virtual addresses and the type big enough for both is too
inefficient or isn't a scalar type.  E.g., i386 virtual addresses
really have 16 bits of segment info and 32 bits of offset.  We can get
away with not supporting them generally only because there is no way
the general case can be efficient so no one wants it.

Bruce