Re: cbuf implementation

Jérome DUVAL <[email protected]> wrote:
> > 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.

It is, in our implementation - but it's actually not really used that 
way. Especially the mouse/keyboard driver are expecting a circular 
buffer. pipefs is using the chained attribute, but it does so 
incorrectly - I always thought of a circular chained buffer - the 
truncate head/tail functions have obviously confused me.

> 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.

Exactly.

> 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.

That wouldn't work well, but might do it as a temporary fix; but since 
a circular buffer is very easy to do, I don't think it's worth the 
effort.

> > 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.

AFAICT that's something pretty much different - one (what we need) is a 
circular buffer, the other one (what is defined in queue.h) is a 
circular list. Both can be useful, but we only need the first one here 
:-)

Bye,
   Axel.



-------------------------------------------------------
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