From owner-cvs-all  Tue Aug 18 07:21:36 1998
Return-Path: <owner-cvs-all>
Received: (from daemon@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id HAA25068
          for cvs-all-outgoing; Tue, 18 Aug 1998 07:21:36 -0700 (PDT)
          (envelope-from owner-cvs-all)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA25056;
          Tue, 18 Aug 1998 07:21:30 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id AAA09667;
	Wed, 19 Aug 1998 00:20:52 +1000
Date: Wed, 19 Aug 1998 00:20:52 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199808181420.AAA09667@godzilla.zeta.org.au>
To: bde@zeta.org.au, dfr@nlsystems.com
Subject: Re: cvs commit: src/sys/i386/include cpufunc.h
Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG
Sender: owner-cvs-all@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>> >  Modified files:
>> >    sys/i386/include     cpufunc.h 
>> >  Log:
>> >  Add macros for accessing device memory.
>> 
>> This is completely misplaced.  i386/include/cpufunc.h is for
>> "providing access to special i386 functions".  Device memory
                                     oops, instructions (quote from cpufunc.h)
>> access functions are already in <machine/bus.h>.
>
>The memory access macros should go in the same place as the port access
>ones.  If they should move to <machine/bus.h> then so should inx/outx.

No they shouldn't, unless they are (confused with) "special i386
instructions".  inb() and outb() etc. are not port access macros; they
are functions to "access special i386 instructions".  <machine/bus.h>
already provides higher level i/o access functions, partly built out of
these primitives and partly with direct asms.  Many drivers still access
inb() and outb() directly but probably shouldn't.

Bruce