From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: oe-kbuild-all@lists.linux.dev, linux-fsdevel@vger.kernel.org
Subject: Re: [viro-vfs:work.alpha 5/8] arch/alpha/kernel/io.c:655:1: error: redefinition of 'scr_memcpyw'
Date: Mon, 29 Jan 2024 05:03:23 +0000 [thread overview]
Message-ID: <20240129050323.GJ2087318@ZenIV> (raw)
In-Reply-To: <20240129021309.GG2087318@ZenIV>
On Mon, Jan 29, 2024 at 02:13:09AM +0000, Al Viro wrote:
> On Sun, Jan 28, 2024 at 02:39:35PM -0800, Linus Torvalds wrote:
> > On Sun, 28 Jan 2024 at 14:09, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >
> > > Do we ever use that thing on iomem in non-VGA setups?
> >
> > On iomem? No. But I think several of the routines just work on either
> > VGA screen memory directly (c->vc_origin = vga_vram_base), or normal
> > RAM (vc_allocate)
> >
> > But who knows.. I *used* to know all this code, but happily no longer.
>
>
> I hadn't finished going through the callers, but AFAICS in !VGA && !MDA
> case alpha should be just fine with the fallbacks, so we could just
> put the instance in io.c under the same ifdef that pulls asm/vga.h into
> linux/vt_buffer.h
BTW, fun observation:
#ifndef VT_BUF_HAVE_MEMCPYW
static inline void scr_memcpyw(u16 *d, const u16 *s, unsigned int count)
{
#ifdef VT_BUF_HAVE_RW
count /= 2;
while (count--)
scr_writew(scr_readw(s++), d++);
#else
memcpy(d, s, count);
#endif
}
#endif
is... interesting. VT_BUF_HAVE_MEMCPYW is defined in asm/vga.h on alpha,
mips, powerpc and sparc. VT_BUF_HAVE_RW is defined precisely in the
same cases. In other words, fallback is *always* memcpy(). Now, note
that
arch/mips/include/asm/vga.h:50:#define scr_memcpyw(d, s, c) memcpy(d, s, c)
arch/powerpc/include/asm/vga.h:45:#define scr_memcpyw memcpy
and on sparc we have
static inline void scr_memcpyw(u16 *d, u16 *s, unsigned int n)
{
BUG_ON((long) d >= 0);
memcpy(d, s, n);
}
IOW, we might as well kill VT_BUF_HAVE_MEMCPYW on everything except
alpha and turn the bit in vt_buffer.h into
#ifndef VT_BUF_HAVE_MEMCPYW
#define scr_memcpyw memcpyw
#endif
Furthermore, scr_memmovew() situation is not far from that - we
have
* architectures other than alpha/mips/powerpc/sparc - all end
up with memmove(), since neither VT_BUF_HAVE_MEMMOVEW nor
VT_BUF_HAVE_RW is defined
* mips/powerpc/sparc - memmove(), since it's explicitly defined
that way.
* alpha - that weird shit.
Incidentally, why do we play with asm/vga.h on sparc? Had there ever
been sparc boxen with VGA card in them that would be in text mode?
prev parent reply other threads:[~2024-01-29 5:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-27 22:59 [viro-vfs:work.alpha 5/8] arch/alpha/kernel/io.c:655:1: error: redefinition of 'scr_memcpyw' kernel test robot
2024-01-28 21:15 ` Al Viro
2024-01-28 21:55 ` Linus Torvalds
2024-01-28 22:09 ` Al Viro
2024-01-28 22:39 ` Linus Torvalds
2024-01-29 2:13 ` Al Viro
2024-01-29 5:03 ` Al Viro [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240129050323.GJ2087318@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox