From: Al Viro <viro@zeniv.linux.org.uk>
To: linux-arch@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCHES][RFC] cleaning up asm/vga.h situation
Date: Wed, 6 Nov 2024 06:09:38 +0000 [thread overview]
Message-ID: <20241106060938.GW1350452@ZenIV> (raw)
asm/vga.h and linux/vt_buffer.h are playing odd games that might
or might not have made sense once upon a time, but currently they are
too convoluted for no good reason.
vt_buffer.h defines the primitives for access to vt contents -
scr_{read,write,memcpy,memmove,memset}w(). In all cases it's an array of
16bit values - attribute/symbol pairs. Normally it's just a kmalloc'ed
buffer; there are few exceptions:
* vgacon.c has the active console contents directly in VRAM;
for such consoles vt.c code will end up accessing that.
* vgacon.c and mdacon.c use those to access the text-mode screen
image directly in VRAM.
VRAM is little-endian; for kmalloc'ed buffers the endianness is
up to us - all accesses will be via scr_... primitives, so in absence
of VGA_CONSOLE and MDA_CONSOLE we can simply keep them host-endian and
turn the accessors into obvious inlines; that's the default.
The few architectures that might have VGA_CONSOLE or MDA_CONSOLE
may override that. Overrides are too convoluted - we have 4 macros
(VT_BUF_HAVE_{RW,MEMCPYW,MEMSETW,MEMMOVEW}) asm/vga.h may define to
control what gets overridden. Situation:
* alpha: needs separate handling for mem and iomem cases,
overrides everything.
* arm: fine with defaults.
* mips: keeps everything little-endian, nothing special needed
for VRAM access. Overrides everything, replacements for memcpy/memmove
are identical to defaults.
* powerpc: more than slightly ridiculous - if VGA_CONSOLE or
MDA_CONSOLE is enabled, same as mips, defaults otherwise. The ridiculous
part is that VGA_CONSOLE is actually impossible to enable there, but
MDA_CONSOLE (that is to say, support of ISA Hercules cards for the second
monitor) *is* possible. On the boxen with ISA slots, that is...
* sparc: overrides everything, replacements are all identical to
defaults. Neither vgacon or mdacon are possible there, so that's fine,
but why bother with overrides in the first place?
* x86: fine with defaults.
Defaults themselves are also overcomplicated - there's e.g. handling
of the case when we'd overridden read/write, but not memcpy (which
never happens).
There are several other things in asm/vga.h, in addition
to these overrides. One is the helpers for byte VRAM accesses -
vga_{read,write}b(), used only by vgacon.c and only to read/modify the
screen font. Hell knows whether it really needs to be done byte-by-byte;
pointer is always to VRAM. Incidentally, the loops in there are
just weird - 8192 bytes of iomem read or written one by one, with
cond_resched() after each. Apparently, qemu with 64 vcpu managed to be
stuck in that for more than a minute... Another thing is VGA_MAP_MEM()
- finding where VRAM is mapped. Used by vgacon, mdacon and vga16fb
(the last one - x86-only).
All of those are provided by asm/vga.h on anything that
might support any of the users, so there's no point keeping them in
asm-generic/vga.h - as the matter of fact, that file can be empty,
which would kill arch/sh/include/asm/vga.h.
Patch series cleaning that up lives in
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.vt_buffer
Individual patches in followups; please, review.
Shortlog:
Al Viro (4):
vt_buffer.h: get rid of dead code in default scr_...() instances
asm/vga.h: don't bother with scr_mem{cpy,move}v() unless we need to
sparc: get rid of asm/vga.h
empty include/asm-generic/vga.h
Diffstat:
arch/mips/include/asm/vga.h | 4 ---
arch/powerpc/include/asm/vga.h | 5 ----
arch/sh/include/asm/vga.h | 7 -----
arch/sparc/include/asm/vga.h | 60 ------------------------------------------
include/asm-generic/vga.h | 23 +---------------
include/linux/vt_buffer.h | 24 -----------------
6 files changed, 1 insertion(+), 122 deletions(-)
delete mode 100644 arch/sh/include/asm/vga.h
delete mode 100644 arch/sparc/include/asm/vga.h
next reply other threads:[~2024-11-06 6:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-06 6:09 Al Viro [this message]
2024-11-06 6:10 ` [PATCH 1/4] vt_buffer.h: get rid of dead code in default scr_...() instances Al Viro
2024-11-06 6:10 ` [PATCH 2/4] asm/vga.h: don't bother with scr_mem{cpy,move}v() unless we need to Al Viro
2024-11-06 6:11 ` [PATCH 3/4] sparc: get rid of asm/vga.h Al Viro
2024-11-06 6:11 ` empty include/asm-generic/vga.h Al Viro
2024-11-21 8:35 ` [PATCHES][RFC] cleaning up asm/vga.h situation Geert Uytterhoeven
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=20241106060938.GW1350452@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=arnd@arndb.de \
--cc=linux-arch@vger.kernel.org \
--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.