Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!sdd.hp.com!col.hp.com!csn!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: 16 bit implications (Re: 7bit unclean considered harmfull (was: Re: Need your opinion (TTYDEF ))8-bit clean state)) Message-ID: <1993Jun20.053917.15742@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <1993Jun18.072919.23475@gmd.de> <CGD.93Jun18011958@crucifixion.CS.Berkeley.EDU> <DERAADT.93Jun18201134@newt.fsa.ca> Date: Sun, 20 Jun 93 05:39:17 GMT Lines: 60 In article <DERAADT.93Jun18201134@newt.fsa.ca> deraadt@fsa.ca (Theo de Raadt) writes: >In article <CGD.93Jun18011958@crucifixion.CS.Berkeley.EDU> cgd@crucifixion.CS.Berkeley.EDU (Chris G. Demetriou) writes: >> *i* have a great distaste for putting the character flags >> in a seperate ring buffer, etc. it just complicates everything, >> and unless it's done with another ring buffer (i.e. with >> another instance of the already-existing ring-buffer data types), >> it adds an unnecessary set of functions to the kernel... >> in any case, it requires double the work in all places >> where characters are used. > >I too, have a great distaste for that idea. All of the ring buffer >functions will need to be modified to play with two ring buffers >simultaneously. It easier to double the size of the rbchar type. > >Holger -- it does not sound like you've looked at the NetBSD tty >subsystem changes. I suggest you do -- they really are good >portable changes. Looking at this code soon will avoid the console >mailing list people following the "Not Invented Here" syndrome that >makes linux what it is. I have to say that I've looked at the changes, and they're not portable (or at least general!) enough. Consider an ISO 10646 32 bit chracter stream. Since the problems being discussed are really problems in cannonical processing, *not* problems in character stream representation, character stuffing NULL's from the device to the cannonical processor would also work (and avoid the second pointer/buffer problem of maintaining and synchronizing character attributes [like "quoted"] which are seperate from the character data itself). For a NULL, it's NULL NULL in the stream; for quoted, it could be NULL SOA, etc. Personally, I don't think this will be that be an issue. The one problem would be in the input mode synchronization between the device and the cannonical processing module to ensure "quoting" and other function aren't sent by the device without cannonical processing present. If character stuffing is unusable, then I'd have to vote for a seperate buffer so that we can add mode or character bits without one effecting the other, even if that meant more processing. I *know* that I, at least, *will* be using Unicode (my rendering engine for X is alpha -- no it does not include ligatures), and I suspect there will be 10646 advocates in the near future (such as Japanese users who want JIS 208/212 code pages in the 10646 name space to tag characters by national origin for direct rendering). On the other hand, I also expect a lot of systems to stay at 8 bits for some time until the applications can catch up. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.