Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!howland.reston.ans.net!newsserver.jvnc.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.111540.9920@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.93Jun18011958@crucifixion.CS.Berkeley.EDU>
Date: Fri, 18 Jun 1993 11:15:40 GMT
Lines: 45
In article <CGD.93Jun18011958@crucifixion.CS.Berkeley.EDU>, cgd@crucifixion.CS.Berkeley.EDU (Chris G. Demetriou) writes:
|> In article <1993Jun18.072919.23475@gmd.de> veit@mururoa.gmd.de (Holger Veit) writes:
|> >There is no such 16bit clean code in the entire kernel,
|> >so a plugin-and-play solution cannot be expected.
|>
|> NetBSD's ring-buffer code will be N-bit clean, as long
|> as you typedef "rbchar"s as a data type with >= 2N bits.
|> right now, our rbchars are a short, so our ringbuffer
|> code is 8-bit clean. (386bsd's, as of the latest patchkit,
So with ISO-10646 (32bit chars) you would have to rely
on the g++ longlong type, right?
|> uses chars as their ring buffer entries. they're 8-bit clean,
|> but e.g. the quote flags is thrown away, and ^v^d<return>
|> does interesting things.)
|>
|> *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.
The handling could be done nearly transparently, by modifying the existing
ringbuf functions to handle both the list of rbchars and a bitvector.
What you might need is an access function to get the current flags,
it is no longer simply ((rbchar)foo) & TTY_QUOTE, but I believe the
number of occurencies in the system is not large. The bitvector in
parallel trades off space (half used longs for 16bit vs half used shorts
in 8 bit) vs. code size and access speed/comfort; reminds me of the
old rule that the product time*space=const. What you will do is
not my problem, but at least the
#define TTY_QUOTE 0x00000100 fails the above rule, perhaps
#define TTY_QUOTE (1<<(sizeof(rbchar)*8)) is better :-)
Holger
--
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