14
JUNE 2021 ISSUE 247 LINUX-MAGAZINE.COM | LINUXPROMAGAZINE.COM
Kernel News
NEWS
[…]
“Kernel is now very verbose, so impor-
tant messages during bootup scroll away.
It is way bigger deal when you can no
longer get to them using shift-pageup.
“fsck is rather verbose, too, and there’s
no easy way to run that under X termi-
nal… and yes, that makes scrollback very
useful, too.”
Pavel put his money directly where his
mouth was, saying, “If it means I get to
maintain it… I’m not happy about it but
that’s better than no scrollback.”
Adam Borowski felt Pavel’s cry of
pain. Adam unleashed his own tor-
mented howl of “I concur,” lamenting,
“this a serious usability regression for
regular users.”
Adam pointed out that “without some
kind of scrollback, there’s no way of
knowing why eg. your rootfs failed to
mount (there was some oops, but its rea-
son was at the beginning…). Or, any
other problem the user would be able to
solve, or pass the error messages to
someone more knowledgeable.”
He also said to Linus:
“I also wonder why did you choose to
remove softscrollback which is actually
useful, yet leave hardscrollback which
doesn’t come to use on any non-ancient
hardware:
* on !x86 there’s no vgacon at all
* on x86, in-tree drivers for GPUs by
Intel, nVidia and AMD (others are dead)
default to switching away from vgacon
* EFI wants its own earlycon
”… thus, the only niche left is nVidia
proprietary drivers which, the last time I
looked, still used CGA text mode.”
Finally, to Pavel’s willingness to main-
tain the code in question, Adam re-
marked, “That’d be greatly appreciated.
There are also some simplifications/ re-
writes that could be done, like getting rid
of redundant 1-byte/ 4-byte storage (or
even the code for 1-byte…). Hard scroll-
back could be axed altogether (it pro-
vides only a small amount of scroll).
Etc….”
Throwing his lot in with the rebellious
Adam and Pavel, Maciej W. Rozycki con-
firmed that “For the record I keep using
the console scrollback all the time, and
FWIW I have gone through all the hoops
required to keep using VGA hardware
emulation and its console text mode
with my most recent laptop, which is a
ThinkPad P51; no longer manufactured,
but still hardly an obsolete device by to-
day’s standards I believe.” He therefore
concluded that “no, it’s not that nobody
uses that stuff anymore, and not with
obsolete hardware either.”
At that point, the matter rested and
several months passed. Then, as if no
time whatsoever had passed, Phillip Susi
replied to Pavel, “Amen! What self re-
specting admin installs a gui on servers?
What do we have to do to get this back
in? What was so buggy with this code
that it needed to be removed? Why was
it such a burden to just leave it be?”
To which Linus replied:
“It really was buggy, with security im-
plications. And we have no maintainers.
“So the scroll-back code can’t come
back until we have a maintainer and a
cleaner and simpler implementation.
“And no, maintaining it really doesn’t
mean ‘just get it back to the old broken
state’.
“So far I haven’t actually seen any
patches, which means that it’s not com-
ing back.”
Philip asked if there was any more in-
formation available. He said, “I can’t try
to fix it if I don’t understand what is
wrong with it. Are there any bug reports
or anything I could look at?”
Meanwhile, Daniel Vetter was not
going to let scrollback return without a
fight. In addition to the problems Linus
had identified, Daniel said, “on anything
that is remotely modern […] there’s a
pile more issues on top of just the scroll-
back/ fbcon code being a mess.” He con-
tinued:
“Specifically the locking is somewhere
between yolo and outright deadlocks.
This holds even more so if the use case
here is ‘I want scrollback for an oops’.
There’s rough sketches for how it could be
solved, but it’s all very tricky work.
“Also, we need testcases for this, both
in-kernel unit-test style stuff and uapi
testcases. Especially the full interaction
on a modern stack between /dev/ fb/ 0, /
dev/ drm/ card0, vt ioctls and the console
is a pure nightmare.
“Altogether this is a few years of full
time hacking to get this back into shape,
and until that’s happening and clearly
getting somewhere the only reasonable
thing to do is to delete features in re-
sponse to syzkaller crashes.”
At this point, Greg Kroah-Hartman
piled in, saying, “Along with what
Daniel has already pointed out, just
look at all of the old syzbot reports for
the code in this area. Try fixing one of
those reports in an older kernel to give
yourself an idea of the issues involved.
Best of luck!”
Philip was utterly unwilling to let this
go, however. And when Geert Uytterho-
even offered some comments on the
overall situation, Philip said, “Judging
from some of the comments in the code,
it looks like you were one of the original
authors of fbcon?” And Geert replied,
“Indeed, a looooong time ago….”
The two of them embarked on an im-
plementation discussion. Philip said he
was willing to try to rewrite scrollback
from scratch if that was what it took,
and he proposed some ideas about how
to do that. And Geert replied:
“There are multiple ways to implement
scrolling:
1. If the hardware supports a larger vir-
tual screen and panning, and the virtual
screen is enabled, most scrolling can be
implemented by panning, with a casual
copy when reaching the bottom (or top)
of the virtual screen. This mode is (was)
available on most graphics hardware
with dedicated graphics memory.
2. If a 2D acceleration engine is avail-
able, copying (and clearing/ filling) can
be implemented by rectangle copy/ fill op-
erations.
3. Rectangle copy/ fill by the CPU is al-
ways available.
4. Redrawing characters by the CPU is
always available.
“Which option was used depended on
the hardware: not all options are avail-
able everywhere, and some perform bet-
ter than others.”
Several people joined the discussion,
but no patches seemed to come out of it.
Reimplementing this feature seems, on
the one hand, like something a fair num-
ber of people want badly enough to do
just about anything for it and, on the
other hand, like something that’s very
hard to get right. And Linus doesn’t
seem inclined to accept any patches that
don’t actually get the thing right.
Will it come back? It seems like a
fairly large mountain to climb for a fea-
ture that is only really useful for kernel
developers debugging kernel code. And
yet, it does seem to have a special place
in the hearts of a fair number of those
kernel developers. Time will tell.
nnn