Date: Wed, 13 Feb 2008 23:20:07 -0800 From: Julian Elischer <julian@elischer.org> To: Ed Schouten <ed@fxq.nl> Cc: Marcel Moolenaar <xcllnt@mac.com>, FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: Proposal for redesigning the TTY layer Message-ID: <47B3EBA7.2020005@elischer.org> In-Reply-To: <20080213192808.GL1340@hoeg.nl> References: <20080213150500.GH1340@hoeg.nl> <A86365DD-5D15-42F2-A810-493B9F9E7AA3@mac.com> <20080213192808.GL1340@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Ed Schouten wrote: > * Marcel Moolenaar <xcllnt@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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47B3EBA7.2020005>