Proposal for redesigning the TTY layer

[Marcel Moolenaar]

On Feb 13, 2008, at 11:28 AM, 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.
>
> 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.

The problem with doing it that way is that insertion of control
characters, like XON/XOFF or STOP may happen right in the middle
of UTF-8 sequences. This may be problematic...

> 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.

That's fine. Just keeping it in the back of your mind helps...

-- 
Marcel Moolenaar
xcllnt at mac.com