This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: IO space memcpy support for userspace.
From: "Carlos O'Donell" <carlos@systemhalted.org>
Date: Fri, 5 Dec 2008 12:32:04 -0500
> On Thu, Dec 4, 2008 at 10:40 PM, Dave Airlie <airlied@gmail.com> wrote:
> > I'm sure this has come up before and I'm sure I'll either wish I never
> > posted this or someone will show me the crisp corpse of the last guy
> > who suggested it.
>
> Do you plan to prevent the compiler from issuing the same sorts of
> instructions that might appear in an optimized memcpy?
>
> Isn't it dangerous to have memory that doesn't behave like normal
> memory, and yet try to treat it like normal memory?
>
> This mismatch of abstractions is a warning that must not be ignored.
This is basically my opinion as well.
You'll pretty much need to surround accesses to these places with
accessor macros that do whatever is necessary on a given platform and
avoids the "dangerous" instructions in cases like IA64.
Treating them like normal memory isn't going to work on all systems.
BTW, the sunffb xorg driver has special code for "graphics copy"
which is essentially just a scanline by scanline GCOPY using the
MMX like stuff sparc64 has. It also is mindful of avoiding access
patterns that are known to lock up that chip :)
That's just an aside, since sunffb doesn't provide any offscreen
pixmap memory and thus shouldn't be susceptible to this problem being
discussed here.