I believe that I've completed a minimum necessary to support booting
x86_64 Hurd using UEFI. There are various commits in the pipeline but
once these are agreed and merged the only missing piece is making use of
the UEFI frame buffer that is presented through the multiboot header.
I've got code ready for this that adds a frame buffer driver for the kd
console. There is also an option for using the same frame buffer during
very early boot via a new gnumach build configuration option
'--enable-immc'.
There is however a potential snag in that the GNUmach and Hurd consoles
don't necessarily work well in combination. Realistically, in most
scenarios, once the GNUmach kernel hands over to user land, the Hurd
console takes over and all is well. That is until the case where a
kernel printf occurs or else the kernel debugger is invoked. The problem
is that the same frame buffer is being used by both consoles and GNUmach
output might not present properly. My kd frame buffer driver makes use
of a character value backing buffer which is used to redraw the display
as needed. That buffer is obviously not accurate in the case where Hurd
console has also output content. In addition to this problem, there is
the possibility that each console might have a different row/column
configuration or font size.
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. Might that
device be enhanced to support multiple readers? Is there some method of
achieving this that I'm unaware of? Can the Hurd console do this already?
The kernel debugger can probably just remain as it is now. After all it
is exceptional, and likely fatal, if that is triggered by a fault and in
any case might not be compiled into the kernel at all.
Possibly I'm being over concerned with what is an uncommon scenario. I
can work on generating the patches for my frame buffer code if that's
appropriate or if living with this limitation for a short period is OK
whilst I'm working on a solution. I'm keen to get a UEFI implementation
integrated so that it can be tested on a variety of machines and find
out what other problems arise.
I'd appreciate advice on how to proceed.
All the best,
Mike.
