From owner-freebsd-hackers  Sat Dec 13 22:16:19 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA13123
          for hackers-outgoing; Sat, 13 Dec 1997 22:16:19 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from m16.boston.juno.com (m16.boston.juno.com [205.231.101.192])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA13115
          for <hackers@freebsd.org>; Sat, 13 Dec 1997 22:16:13 -0800 (PST)
          (envelope-from wakkym@juno.com)
Received: (from wakkym@juno.com)
 by m16.boston.juno.com (queuemail) id B}W21229; Sun, 14 Dec 1997 01:15:27 EST
To: hackers@freebsd.org
Subject: Re: Beginning SPARC port 
Message-ID: <19971214.011331.5303.2.wakkym@juno.com>
References: <16085.882074445@coconut.itojun.org>
X-Mailer: Juno 1.15
X-Juno-Line-Breaks: 0,2-23,35
From: wakkym@juno.com (Lee Cremeans)
Date: Sun, 14 Dec 1997 01:15:27 EST
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


On Sun, 14 Dec 1997 13:40:45 +0900 Jun-ichiro itojun Itoh
<itojun@itojun.org> writes:
>
>>> pccard/pcic.c
>>> pci/aic7870.c
>>> pci/if_de.c
>>> pci/ncr.c
>>> pci/tek390.c
>>> pci/wd82371.c
>>What makes you think outb is i386 specific? Surely since it is 
>defined
>>in a machine header to some asm fn, what it really means is that
>>it is GNU C specific? If you think about it, if a platform needed
>>a bit of complexity to do inb/outb, you #define them to funciton
>>calls.
>
>	hardware I/O model is CPU specific.  There are architectures
>	that do not have inb/outb instruction, and maps I/O device 
>control
>	registers onto memory.  I dunno how Sparc-with-PCI motherboard
>	access pci registers, but I'm sure there has to be bunch of 
>changes.

Why not make it so that the PCI chip stuff is accessed through a standard
API, i.e. make something like a pci_machdep.c and put the
architecture-specific details in there (each architecture that we have
PCI support for would have its own version; in fact, it could be named
something more orthogonal, like pci_sparc.c or pci_alpha.c or
pci_i386.c), then make it so that the drivers operate through that? I'm
operating on just a basic understanding of PCI programming, tho; I'm
assuming, for example, that all PCI host-to-bus bridges have at least
somewhat similar register interfaces, which may not be the case (I don't
have any manuals here, and can't get them since I don't have a real
Internet feed here anymore...). Of course, I guess that all that needs to
be managed is the I/O details; it doesn't have to be very high-level.