Proposal for redesigning the TTY layer

[Ed Schouten]

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

-- 
 Ed Schouten <ed at fxq.nl>
 WWW: http://g-rave.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080213/d3eacc86/attachment.pgp