Re: cbuf implementation

Jérome DUVAL <[email protected]>
Newsgroups gmane.os.openbeos.kernel.devel
Message-ID <[email protected]>
Hi Axel,

----- Original Message ----- 
From: "Axel Dörfler" <[email protected]>
To: "OpenBeOS Kernel" <open-beos-kernel-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>;
<[email protected]>
Sent: Tuesday, April 12, 2005 4:30 PM
Subject: [Open-beos-kernel-devel]cbuf implementation


>
> I just had another look at our cbuf implementation, and on how it is
> used:
> it seems that everyone (excluding the ports subsystem) has taken cbuf
> to be more or less a circular buffer. But it is not - it was used
> completely wrong everywhere, and is used very inefficient by the ports
> implementation. That's BTW why the keyboard and mouse drivers don't
> work as expected - it's less obvious in the keyboard driver, as it
> overwrites the same byte over and over again (instead of buffering the
> input), but the mouse driver only writes to byte 1 and reads out 3
> bytes as a packet - go figure.

i thought cbuf was an acronym for "chain buffer", not circular.
In my mind, the R5 cbuf adapter wraps cbuf calls in R5 cbuf get/put calls
which work for ps2_hid, so i suspect they have a (good) pipe behavior.
On the mouse driver, it appears to me we should at least memcpy with an
offset instead of pushing everything on the chain head.
To enable a queue behavior, maybe we could also use a merge_chain.

>
> IOW we don't need our cbuf implementation - we need something that we
> are already using but don't have :)
> In case anyone steps up now, you have the job, if not, I'll be doing
> it. Unless I hear something else in the mean time, I start doing it in
> around 5 hours.
>

I can't really do this in the way you already thought about it, for sure ;)
But i'm used to these behaviors described at the top of this header :

http://svn.berlios.de/viewcvs/haiku/haiku/trunk/src/add-ons/kernel/drivers/audio/echo/queue.h?rev=11769&view=auto

queue.h macros are fine for pointer management but there is no locking, no
preallocation and memory management, no index.
Actually I'd like to be able to map queue.h operations when possible,
easying driver writing.
In the end, using two buffer queues (free and used) with these macros gives
a good behavior.

Bye,
Jérôme




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.