Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!usc!howland.reston.ans.net!agate!agate.berkeley.edu!cgd
From: cgd@crucifixion.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: comp.os.386bsd.development
Subject: Re: 16 bit implications (Re: 7bit unclean considered harmfull (was: Re: Need your opinion (TTYDEF ))8-bit clean state))
Date: 18 Jun 93 01:19:58
Organization: Kernel Hackers 'r' Us
Lines: 30
Message-ID: <CGD.93Jun18011958@crucifixion.CS.Berkeley.EDU>
References: <1993Jun14.081754.18248@alf.uib.no> <1vi6ak$hs7@umd5.umd.edu>
<CGD.93Jun17215526@crucifixion.CS.Berkeley.EDU>
<1993Jun18.072919.23475@gmd.de>
NNTP-Posting-Host: crucifixion.cs.berkeley.edu
In-reply-to: veit@mururoa.gmd.de's message of Fri, 18 Jun 1993 07:29:19 GMT
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,
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.
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