Date: Sun, 7 Oct 2001 12:37:37 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ia64/include cpufunc.h Message-ID: <20011007123737.A380@athlon.pn.xcllnt.net> In-Reply-To: <20011007132357.J6012-100000@delplex.bde.org> References: <20011006121654.B68233@kayak.xcllnt.net> <20011007132357.J6012-100000@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 07, 2001 at 02:09:50PM +1000, Bruce Evans wrote:
> On Sat, 6 Oct 2001, Marcel Moolenaar wrote:
>
> > On Sat, Oct 06, 2001 at 10:57:48PM +1000, Bruce Evans wrote:
> > > On Sat, 6 Oct 2001, Marcel Moolenaar wrote:
> > > > o Add memcpy_fromio, memcpy_io, memcpy_toio, memset_io,
> > > > memsetw and memsetw_io. I'm not sure this is the right
> > > > place for it, though.
> > >
> > > Certainly not. As the comment near the beginning says says, cpufunc.h
> > > is "to provide access to special ${MACHINE_ARCH} instructions". It should
> > > not contain anything that can be written in C, including anything that
> > > can be written in C by combining primitives written in inline asm.
> >
> > I thought so. What is the right place, then. It seems that bus_memio.h
> > is a good match, but that file is empty for all ports and thus is
> > making me nervous. The other logical place is bus.h. On alpha the
> > functions are there, but that's mostly because of the implementation.
>
> 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).
> 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).
> 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.
> 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.
> This is closer to the original intended use of cpufunc.h
> than the i386 implementation of bus space. However, I think the i/o
> interfaces are special enough to keep separate (remove all the i/o
> primitives from the i386 cpufunc.h...).
Yes, I can agree with that. I'll probably reshuffle things if and when
I manage to get a bigger picture. I'm too preoccupied ATM with getting
a firm enough grip on the porting work that I don't fall flat on my
face everytime the world changes around me...
Thanks,
--
Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011007123737.A380>