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;
as well as URLs for NNTP newsgroup(s).