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