Hello, Michael Kelly, le lun. 09 nov. 2026 19:41:19 +0000, a ecrit: > There is however a potential snag in that the GNUmach and Hurd consoles > don't necessarily work well in combination. [...]
> 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. Yes, that is a common issue with framebuffers. Hiding the messages away however doesn't seem a good approach to me. GNU Mach only prints for really exceptional situations, where having it shown on the screen immediately is probably an important thing. You mentioned the debugger, other prints look similar to me. That is actually what we are already having with the mach console. > In addition to this problem, there is the possibility that each > console might have a different row/column configuration or font size. I don't think it's really a problem if glyphs alignment don't match. A console user would know to type ^L to clear overwrites away. > 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. > Might that device be enhanced to support multiple readers? The problem is that the kmsg device is supposed to be consumed. > 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. Samuel
