Hi Markus, I very like to agree with you on that implementing Unicode in kernel is not feasable at all, but I much prefer to see the console is refactored and implemented as a user-space application instead, and then supports all good stuff. The reason for that, not mine, but I heard that: "A japanese system administrator should be able to read the error messages in japanese." and deep down there we all know that it's true. Any argument against that, has its roots in "we are not technically advanced enough to get there yet".
behdad On Fri, 14 Jan 2005, Markus Kuhn wrote: > 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 > > --behdad http://behdad.org/ -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
