Simon wrote on 2005-01-15 01:12 UTC: > However, how does this user-space software for console look like? > What exactly should it do? What's to remove/modify from the kernel?
The user-mode console communicates with the applications connected to it using the "pseudo-terminal" device, the same kernel mechanism that allows xterm, sshd or iscreen to look for their applications virtually like a good old serial port into which a DEC VT102 is plugged. See "man pts" for details. The user-mode console communicates with the keyboard and VGA card using a low-level graphics-mode and keyboard library such as SVGAlib or libSDL, or alternatively, using the same kernel direct memory mapping mechanisms and raw keyboard modes that these libraries and the X server or these libraries use already today. The user-mode console has to be started as one of the very first programs by the init process. This way even the stdout of the boot scripts is already rendered by it. The only text still rendered by the old kernel console would be: - initialization messages by the kernel and its drivers - kernel error messages (before klogd is started) - kernel panic messages All of these are only intended for expert users and will therefore without doubt remain in English for the next 25 years. I believe that there are no extensions whatsoever necessary to the kernel to support a user-mode console. All the necessary mechanisms have been used by X servers for more than 13 years now. I'm not sure, whether init should start the user-mode console or vice versa. Alternatively, the user-mode console could be started much later in the boot process, more like the X server is today. It could even be started in .profile (like many people do with ssh-agent). Such details might well differ from distribution to distribution. What I want to say is that something like this is pretty standard and not at all difficult to implement. Unfortunately, so far the path of least resistance has guided people towards fiddling with the emergency-terminal (shall we call it "panic terminal", after its main purpose?) in the kernel, as opposed to building a simple proper one. Perhaps the only reason that this has not been done yet is that nobody has felt an itch strong enough to fill the gap between the slightly bloated kernel terminal and the massively bloated X11 environment, with slim a user-level VT100 emulator with direct non-X framebuffer and keyboard access. (The valid question remains, whether in the end, the result with "full Unicode 4.1 support" will be any more light weight than X11. I reserve the right to remain sceptical here.) > Any proof-of-concept code that can show the validity of direction? Look at the X server and GNU screen, as well as some of the other pieces of software mentioned above. Markus -- Markus Kuhn, Computer Lab, Univ of Cambridge, GB http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__ -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
