Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!usc!howland.reston.ans.net!xlink.net!gmd.de!mururoa!veit
From: veit@mururoa.gmd.de (Holger Veit)
Subject: Re: 16 bit implications (Re: 7bit unclean considered harmfull (was: Re: Need your opinion (TTYDEF ))8-bit clean state))
Message-ID: <1993Jun18.072919.23475@gmd.de>
Sender: veit@mururoa (Holger Veit)
Nntp-Posting-Host: mururoa
Organization: GMD, Sankt Augustin, Germany
References: <1993Jun14.081754.18248@alf.uib.no> <1vi6ak$hs7@umd5.umd.edu> <CGD.93Jun17215526@crucifixion.CS.Berkeley.EDU>
Date: Fri, 18 Jun 1993 07:29:19 GMT
Lines: 69
In article <CGD.93Jun17215526@crucifixion.CS.Berkeley.EDU>, cgd@crucifixion.CS.Berkeley.EDU (Chris G. Demetriou) writes:
|> In article <1993Jun16.154152.5624@gmd.de> veit@mururoa.gmd.de (Holger Veit) writes:
|> |> Will this require making the characters 32 bits in the input queue, to allow
|> |> out of band info?
|> >
|> >For Heaven's sake, there are more clever mechanisms we (*) want to have.
|> >The discussion is about 16bit systems first, i.e. Unicode (although this is not
|> >the only way to do it), not ISO-10646 or other 32 bit systems.
|>
|> Peter'ss not asking about the *character* representation, he's
|> asking about things like (from sys/tty.h):
|>
|> #define TTY_QUOTE 0x00000100 /* Character quoted */
|>
|>
|>
|> currently, we've got 8bit chars, and therefore need a 16-bit
|> data type in the ring buffer code.
|>
|>
|> if you've got 16bit chars, will we need a 32-bit data type in the
|> ring buffer code? unless you do something nasty, we will...
|>
Ah, now I understand now. The driver will have different interfaces,
an 8 bit interface which is compatible without problems to the existing
tty driver, and will have a 16bit interface, which does require
several changes when you want to pass such data through the tty message
channels. There is no such 16bit clean code in the entire kernel,
so a plugin-and-play solution cannot be expected. I suggest as the first
step to leave the tty interface as is, and let the console driver for
the 16 bit mode emulate the most important parts of the tty system by
itself. I believe 75% of the tty functions is not necessary with the console;
the 16bit part is just some special character device (like the lpt driver)
doing its own buffering and scatter/gather block processing. I did this
(although by using clists available by the system, for convenience)
in the /dev/kbd part of codrv; something like this with adding some
compatibility ioctls should be sufficient for first experiments with 16 bit
mode. In the long term, of course it could be necessary to replace
considerable amounts of the tty driver. For the above mentioned
TTY_QUOTE bit, I could imagine a bitvector, parallel to the ring buffer
for the actual characters, rather than packing additional flags
directly together with the character (which is more convenient and
probably a bit faster in access. With swapping out character flags, you
could reduce the necessary size of buffers. I haven't had a look into
sys/tty.h to find out whether there are more of these bits >=bit8 there;
if not, you already spent 7 bits for the future, going to 32 bit
ring buffer data elements will give you 23 unused ones in the moment
(and if some day 10646 will come up, you are again short in space).
The TTY_QUOTE bit above is now not a 7bit-ism, but an 8bit-ism,
which is as bad if we consider 16 bit. Once you have such 7/8-bit-polluted
definitions like this in publicly available include files, it is hard
to get rid of them again. So try to think a bit further.
|>
|> chris
|>
|> --
|> Chris G. Demetriou cgd@cs.berkeley.edu
|>
|> "386bsd as depth first search: whenever you go to fix something you
|> find that 3 more things are actually broken." -- Adam Glass
--
Dr. Holger Veit | INTERNET: Holger.Veit@gmd.de
| | / GMD-SET German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Computer Science | Fax: (+49) 2241 14 2342
| | / P.O. Box 13 16 | Three lines Signature space
| |/ Schloss Birlinghoven | available for rent. Nearly
DW-5205 St. Augustin, Germany | unused, good conditions