Date: Thu, 28 Apr 2011 00:45:50 +0200 From: Bartosz Fabianowski <freebsd@chillt.de> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, Hans Petter Selasky <hselasky@c2i.net> Subject: Re: Is there some implicit locking of device methods? Message-ID: <4DB89C9E.1070004@chillt.de> In-Reply-To: <20110427223811.GA48734@deviant.kiev.zoral.com.ua> References: <4DB695DB.1080505@chillt.de> <201104271019.31844.jhb@freebsd.org> <4DB818A3.1020104@chillt.de> <201104271334.07170.jhb@freebsd.org> <4DB8873C.5020608@chillt.de> <20110427215228.GY48734@deviant.kiev.zoral.com.ua> <4DB89559.3080008@chillt.de> <20110427223811.GA48734@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> This is a strange architecture, esp. amusing is the kernel-mode > traffic multiplier. This mimics the Linux input events framework. The architecture is not mine, I am just implementing it under FreeBSD. > - use usermode daemon that multiplies traffic for all connected > clients; A better architecture for sure - but I want to stay compatible with code written for Linux and so must provide concurrent access via a single device node. > - or, implement a ring buffer that cyclically stores the received > data, and keep only the current read pointer in the cdevpriv. Good idea. This will save a few kilobytes of memory. > You need to handle the overflow case (eq. to the stuck reader) > somehow in the current scheme anyway. Reader may now read from its > current read position in the buffer up to the fill point. If the > buffer wrapped for the reader, it should get some error. Yes, of course. I am checking the queue fill state and making sure not to overflow it. - Bartosz
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DB89C9E.1070004>