Proposal for redesigning the TTY layer

[Julian Elischer]

Ed Schouten wrote:
> * Marcel Moolenaar <xcllnt at mac.com> wrote:
>> On Feb 13, 2008, at 7:05 AM, Ed Schouten wrote:
>>
>>> The last couple of days I've been working on a document which describes
>>> the changes I'm going to perform. I have just finished this document, so
>>> I'm sending it to this list, so you can give your opinion on this
>>> matter.
>> You mention the console. It would be best not to tie it up
>> with the TTY layer, because we typically need the console
>> way before we can have a TTY layer. A better approach would
>> be to treat the console as a logging facility that can log
>> to various destinations. The message buffer is one, a
>> system console can be another. That system console should
>> use the TTY layer so that it can accept input. The reason
>> not to tie them and instead think of printf() as a logging
>> request is that it makes matters simpler in a multi-console
>> setup.


does anyone have a copy of the old console-NG design from 386BSD 
(1993/4 or so I think) ?

> 
> I'm planning on keeping the console code as it is. It will only need
> small changes to make it work with the new TTY layer.
> 
>> Also, it may be worthwhile to keep Unicode in mind when you
>> are reworking the clists. If the TTY layer operates on
>> wchar_t instead of char, then all it needs is a device driver
>> that consumes the wchar_t to have native Unicode support.
>> Non-Unicode drivers can use UTF-8 interfaces.
> 
> I personnally think we shouldn't put multibyte-handling inside the
> clists, but within the drivers, like syscons. A lot of drivers just need
> to send the raw 8-bit data to the other side, so it would be better to
> leave the generic TTY layer like that. Syscons could perfectly parse the
> UTF-8 and use a 16-bits font to draw them on screen.
> 
> One thing I really think the TTY code should have somewhere in the
> future, is something similar to Linux's c_iflag `IUTF8', which fixes the
> backspace key in canonical mode.
> 
> Thanks for the suggestion by the way. I'll write it down, but I don't
> think I can do something about this in the nearby future.
>