From owner-freebsd-arch@FreeBSD.ORG Wed Feb 13 19:28:10 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 366DD16A418 for ; Wed, 13 Feb 2008 19:28:10 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 5597D13C45E for ; Wed, 13 Feb 2008 19:28:09 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 6DD0E1CC76; Wed, 13 Feb 2008 20:28:08 +0100 (CET) Date: Wed, 13 Feb 2008 20:28:08 +0100 From: Ed Schouten To: Marcel Moolenaar Message-ID: <20080213192808.GL1340@hoeg.nl> References: <20080213150500.GH1340@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zbynv6TNPa9FrOf6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: FreeBSD Arch Subject: Re: Proposal for redesigning the TTY layer X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2008 19:28:10 -0000 --Zbynv6TNPa9FrOf6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Marcel Moolenaar 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. --=20 Ed Schouten WWW: http://g-rave.nl/ --Zbynv6TNPa9FrOf6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkezRMgACgkQ52SDGA2eCwXQXwCeJil6UO6KBZcnhzOmsQoIldlG m68An1DzcJPIhoEVsWo2x2Ng5X62XPC0 =0Zci -----END PGP SIGNATURE----- --Zbynv6TNPa9FrOf6--