All of lore.kernel.org
 help / color / mirror / Atom feed
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: Sun, 28 Jan 2024 22:09:04 +0000	[thread overview]
Message-ID: <20240128220904.GF2087318@ZenIV> (raw)
In-Reply-To: <CAHk-=wj8LUAX_rwM4=N9kNGeg=E+KoxY6uQfyqf=k7MOrb4+aA@mail.gmail.com>

On Sun, Jan 28, 2024 at 01:55:31PM -0800, Linus Torvalds wrote:
> On Sun, 28 Jan 2024 at 13:15, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > The thing is, VT_BUF_HAVE_... are defined in asm/vga.h, so if you don't
> > have VGA_CONSOLE or MDA_CONSOLE you are going to get the default ones.
> > In case of scr_memcpyw() it's going to end up with memcpy(); on alpha
> > that does *not* match the native scr_memcpyw() instance.
> >
> > Since we have vga.h in mandatory-y, with asm-generic fallback being
> > reasonable enough...  Should that include of asm/vga.h be conditional
> > in the first place?
> 
> It should be conditional, because that's the only case you want to
> actually have that special scr_memsetw() etc.
> 
> I think the problem is that you added the vtbuf include to <asm/io.h>,
> which gets included from VGA_H early, before vga.h has even had time
> to tell people that it overrides those helper functions.

Nope.  It's arch/alpha/kernel/io.c growing an include of linux/vt_buffer.h
and blowing up on allnoconfig.  The reason for that include was the
"missing prototype" on scr_memcpyw() definition in there...

> I assume that moving the
> 
>     #define VT_BUF_HAVE_RW
>     #define VT_BUF_HAVE_MEMSETW
>     #define VT_BUF_HAVE_MEMCPYW
> 
> to above the
> 
>     #include <asm/io.h>
> 
> fixes the build?

No such thing...  I can add an explicit extern in io.c, but that's
really obnoxious ;-/

> That said, a good alternative might be to just stop using 'inline' for
> the default scr_memsetw() and scr_memcpyw() functions, make them real
> functions, and mark them __weak.
> 
> Then architectures can override them much more easily, and inlining
> them seems a bit pointless.
> 
> But I doubt it's even worth cleaning things up in this area.

Do we ever use that thing on iomem in non-VGA setups?

  reply	other threads:[~2024-01-28 22:09 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 [this message]
2024-01-28 22:39       ` Linus Torvalds
2024-01-29  2:13         ` Al Viro
2024-01-29  5:03           ` Al Viro

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=20240128220904.GF2087318@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.