Date: Sun, 14 Dec 1997 01:15:27 EST From: wakkym@juno.com (Lee Cremeans) To: hackers@freebsd.org Subject: Re: Beginning SPARC port Message-ID: <19971214.011331.5303.2.wakkym@juno.com> References: <16085.882074445@coconut.itojun.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971214.011331.5303.2.wakkym>