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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
