From owner-cvs-all Sun Oct 7 20:11:42 2001 Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8527E37B401; Sun, 7 Oct 2001 20:11:35 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id NAA31625; Mon, 8 Oct 2001 13:11:27 +1000 Date: Mon, 8 Oct 2001 13:10:45 +1000 (EST) From: Bruce Evans X-X-Sender: To: Marcel Moolenaar Cc: , Subject: Re: cvs commit: src/sys/ia64/include cpufunc.h In-Reply-To: <20011007123737.A380@athlon.pn.xcllnt.net> Message-ID: <20011008122319.M13486-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 7 Oct 2001, Marcel Moolenaar wrote: > On Sun, Oct 07, 2001 at 02:09:50PM +1000, Bruce Evans wrote: > > bus_memio.h is supposed to just enable the memio functions in > > bus_xyz${MACHINE}.h (I don't like this, but...). > > > > Why do you even need these functions? > > Because sys/dev/fb uses it (see below). Ugh. > > They are standard functions in > > Linux, but in *BSD, drivers are supposed to use the bus_space functions > > for all of them except memsetw. E.g., memsetw_io is spelled > > bus_space_set_region_2 in *BSD, except the latter is more general (it > > can handle both memory-mapped ioport-mapped i/o). > > Ok. This indicates that the functions I put in machine/cpufunc.h > should actually be put in in a header in dev/fb (very likely > dev/fb/fbreg.h). I agree. It should its own macros to hide the complications of bus_space if it wants to do that. > > The alpha versions > > of these functions actually seem to be compatibility cruft, mainly for > > NetBSD. > > Above you say that drivers for *BSD are supposed to use the bus_space > functions. This seems to contradict with the statement that we added > the mem*io functions for compatibility with NetBSD on Alpha. This is > fine, but it makes it all the harder for me to figure out what we call > "right", so that I can do it right the first time. I thought that the compatibility cruft was from NetBSD when I wrote my original reply. It was actually added by dfr in rev.1.6 of alpha/include/bus.h. The main problem now is that we have arch-dependent compatibility cruft, so using it not only prolongs the like of the old interfaces but requires messy ifdefs to select a set of interfaces. > > Well, I almost see the reason -- on ia64's, the bus space interfaces > > are implemented using the primitives in cpufunc.h instead of repeating > > lots of code and writing loops in asm (there are no inline asms in the > > ia64 bus.h). > > The bus_space_*_multi* functions will benefit a lot if don't use > the primitives in the way we do now or in the form we now have them. > See also below. I couldn't quite see a continuation below :-). I think you just mean that the bus_space_*_multi* functions really shouldn't exist. They are very easy to synthesize using for loops, and that's exactly how they are implemented except on i386's. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message