Samuel,
On 09/11/2026 22:32, Samuel Thibault wrote:
It would be better, I think, for GNUmach console to no longer output
anything directly to the frame buffer after the Hurd console has started.
I'm wondering if it would be better for the Hurd console to 'listen' for
GNUmach output, perhaps via the kmsg device.
That could be a thing. But then if the system is going bad, you won't
have the prints showing up to tell you about it.
Yes, that's true if you are using the console. I've only used Hurd with
ssh, serial connection and the Hurd console itself. What happens to the
Mach printf output whilst running X (or equivalent), for example?
I've not delved deeply into the Linux console code but old versions used
some kind of device write to send console output to multiple consoles.
That might not still be true, perhaps someone here knows?
Might that device be enhanced to support multiple readers?
The problem is that the kmsg device is supposed to be consumed.
Do you mean that each kernel message is removed once it has been read?
Couldn't that still apply but only when the last reader has read the
message?
Is there some method of achieving this that I'm unaware of? Can the
Hurd console do this already?
It doesn't support it currently, but it could, or better perhaps have
syslog etc. handle it.
I've spent quite a lot of time thinking of ways to work around the
console output issue without adding the complexity of Hurd console
managing Mach output. I can't think of any simple solution that I am
satisfied with. The best 'bodge' that I can imagine would be:
1) Add a 'ctrl-l' feature to the kernel debugger so that you can clear
the screen which would correctly reset the GNUmach display so that
scrolling worked correctly. I prototyped this with just a few lines of
code which sends the 'ESC [ 2 J ' sequence to the terminal and
redisplays the debugger prompt. This could be done on debug entry but I
think it's better done manually in case there is some output already on
the console that you want to see first. This part I think might be
acceptable.
2) Some how identify when Mach might lose total control of the frame
buffer, perhaps after any user process has made a request to 'mbinfo'.
From that point on, don't maintain the character backing buffer for
printfs and do scrolling by memmove of the frame buffer memory. This
memmove method is extremely slow with something like 2 scrolls per
second on my hardware machine. With my frame buffer code, this is
perhaps nearer 50 scrolls per second and I'm certain it's far from
optimal. This performance increase is because with the character backing
buffer there are no reads to the video memory and only writes. We'd have
to very confident that printf calls were rare after this mode was
triggered. It might also be difficult to find an appropriate trigger
point in the code that didn't look like a massive hack.
Solving point 2) is essential because in the case of a printf, scroll
and printf sequence, some or all of the output from the first printf
might be lost with the my current implementation.
Cheers,
Mike.
