Manolo,
On 08/10/2026 10:27, Manolo de Medici wrote:
Just a suggestion, instead of doing this, wouldn't it make more sense
to implement a dmesg device as a ring buffer in memory, and play those
message from the ring buffer on the com port if available? Then have
the hurd console open that device and replay the dmesg on boot on the
screen if available?
All kernel output already enters a 'consbuf' string buffer at times
before the console is initialised. This output is then fed to the
console after it is initialised.
The only thing affected would be the kernel debugger that would
require a com port, but that's normal!
I think we should get rid of graphics drivers in gnumach and rely just
on userspace for that. This is not based on ideology but on practical
considerations.
The frame buffer I am referring to is set up by the firmware and
references to it are maintained within gnumach for use by user tasks. I
too don't think that adding direct use of the frame buffer by gnumach is
the best place for implementing boot output. I am looking to see if the
UEFI GOP boot service provides a trivial text output method until a user
land console is available.
An alternative approach might be to use a version of the Hurd console
with a builtin 'boot' font that could be launched before the file system
is available and loading it via a multiboot2 module.
Cheers,
Mike.
