Tom Zanussi wrote: > In userspace, the sub-buffer reading loop looks at the commit value in > the sub-buffer, and if it matches (sub-buffer size - padding), the > buffer has been completely written and can be saved, otherwise it's > not yet complete and is checked again the next time around. This way, > there's no need for a deliver() callback, the relay_commit() is > replaced with the increment of the reserved commit value, the arrays > aren't needed and you get the same result in the end in a much simpler > way, IMHO.
Actually this has a much greater potential of loosing buffers because we have to poll the buffer for completion. Seen another way, the kernel- side has got to wait until the user-side has "figured out" that it needs to commit content to disk. As it was originally, it was relatively straightforward to dertermine why data was lost: ok, we've signaled it from kernel space, but the daemon never flushed it out. Without commit/ deliver, things are much less clear, and I still miss what gain we are making by removing them. I would very much like to see the commit/deliver functionality back. Such mechanisms are required for any sane producer-consumer model. Karim -- Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
