Behdad Esfahbod wrote on 2005-01-11 11:06 UTC: > The point people miss is that: We don't have a userspace > terminal emulator that supports all Unicode scripts yet, not that > the concept is well-defined at all, not that all scripts can be > rendered in such a grid. As soon as we have a clue about what it > should look like (mlterm tries to do figure out), then we can > think about if anybody wants to port/write all the code in kernel > too or not.
What I never understand is: Why do people want to have a full-blown Unicode renderer and input-method *in the kernel*? Can anyone name me a *single* reason (other than a bad taste in matters of software architecture)? The very idea sounds foolish and unnecessary to me. The main purpose of the kernel terminal emulator is to give you the minimally necessary bare-bones administrative interface needed to boot the machine and repair it if something goes wrong. Very few people want to have Mongolian top-down and Syriac conjoining left-right boot messages, I presume/hope. Linux has all the facilities in place for a plain normal user process to take over complete control over the video card, keyboard and the terminal driver that connects both to applications. The kernel will even provide you the Alt-Ctrl-F\d\d? switching mechanism to switch between several of such user applications or the built-in poor-man VT100. The X server is one example application that does that. If you don't like X, for example you think it is too slow, too resource hungry, too complex, too insecure, too politically incorrect, then there are plenty of libraries (svgalib, etc.) that allow you to write from scratch very easily a terminal emulator that will *not* depend in any way on either X11 or the very pathetic bare-bones VT100 rip-off found in the kernel, and can replace it completely without any drawbacks. As a user process, you have easy and safe access to all the huge tables, font libraries, and dynamic memory that any interface offering a substantial fraction of the whole Unicode will require. It is already bad enough that modern Linux kernels just about fit onto seven boot floppy disks (used to be less than one) and that you can make it an (fairly easy) undergraduate student exam problem to find five new Linux kernel security problems in five hours. I'd rather not see that double again. Perhaps all support for any form of ISO 2022 switching, any non-CP437 ROM glyphs, any mouse operations, etc. should *removed* from the kernel, to avoid that people get the wrong expectation that the bare-bones emergency terminal emulator is a worthwhile construction site for future bloat. This would -- as a benefitial side effect -- also dramatically reduce the number of states in which the kernel VT100 can be, ensuring that people cannot get into these states by accident. Then the kernel terminal would finally be well-suited again for what it really is there fore: a safe and robust boot-and-emergency device. The underlying problem is perhaps that people find it so much easier to think about extending something existing, even if it is at the wrong place, rather than building something new at the right place. Remember that a Unix kernel does -- by wise design -- not even know about local time, login name, locale. So why should it have to know about fonts and keyboard input methods. The low frequency of context switches (typically << 100 Hz) or privileges required between a VT100 application and a VT100 terminal really does not justify running the normally used terminal emulator into the kernel. The one currently in there should be seen as a bare-bones emergency device for use by administrators only, and preferably be stripped down accordingly. 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/
