Michael Kelly, le mar. 10 nov. 2026 20:43:40 +0000, a ecrit: > 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?
In the current textual console, it won't show up, which pose some problems. > 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? The Linux text console would emit printfs on the console, and not under X. With some machines where there is no text console and a framebuffer instead, the text would show up on top of the user console content. > > > 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. I'm not sure to understand. Do you mean that reads from video memory are *extremely* slow? i.e. that we are fine with writing the whole console, but reading it to re-write it with a vertical offset, is awfully slow? That is *very* surprising. I mean, even if video memory is on a separate video card, the PCI bus is not that slow, a 1600x1200x32bpp framebuffer is 7MB, by nowadays' bandwidth standards that should be just a millisecond to read. Samuel
