[servers/console] Support memory-mapped text console

[perlun]

Similar to #125, but much less drastic.

When a process is allocating a text console, a memory region is allocated by the console server. This memory is only being written to by the console server; all access to it has to go via IPC. When the console is the active physical console, the console server replaces the pointer to the "framebuffer" with a pointer to the real EGA text console - 0xB8000.

This works reasonable enough for many applications, but for some - the modplay program in particular, it's extremely inefficient. The modplayer writes a lot of output to the console, because it uses very simple "text-based visualization" of the module currently being played. All of this could be just memory writes within the same process if we would allow the following to happen:

• Add a new API/flag in console_open indicating that you want a memory mapped console instead of an IPC based one.
• Notify the client (calling console_open) what the virtual memory address for the new buffer will be.
• When the console gets activated, make the console server tell the kernel to map the physical EGA text buffer (0xB8000 again) into the virtual memory buffer above.
• When the console gets deactivated, copy the content of the EGA text buffer into the shared memory buffer.

This of course depends on some form of shared memory - a concept we don't really support at the moment. But we could cheat a bit and use the "global memory" concept for this - since we're only talking about 80x50x2 = 8000 bytes we would only be wasting 2x4 KiB pages for this, and it'll definitely be the easiest way to get this going.

If we'd do this, I think the end user experience of "realtime" programs like the modplayer will be much appreciated.

[doverhill]

what we should do is improve IPC overall by mapping a physical page in both processes address spaces when doing ipc_connect. The ipc_connect function should return a pointer to the logical address where the page is mapped and we should put our ipc_structure pointer there. when we have a message to send we should call message_send like we do now, but this will not do any copying of data whatsoever but instead just wake the blocked process on the other end. i think this should be doable without too much changes of current applications

[perlun]

@doverhill Good ideas that will reduce the amount of IPC roundtripping indeed. How about multiple threads reading/writing to this page at the same time? Some form of synchronization mechanism like a mutex or similar will be required, to avoid the reader trashing the state for the writer or vice versa.

[perlun]

(See also #158 which is semi-related.)