Messages in this thread | | | Date | Wed, 17 Mar 2010 07:22:28 -0400 (EDT) | From | "Robert P. J. Day" <> | Subject | Re: kfifo: possible weird violation of what should be invariant |
| |
On Tue, 16 Mar 2010, Roland Dreier wrote:
> > sure, the code seems to work, but allowing the internal values of a > > kfifo to contain invalid values on a regular basis would seem to make > > a mess of, say, tracing or debugging. making sure that offset values > > actually lie within their valid range would seem to be one of those > > ASSERT() things that should always be true, should it not? is there a > > reason the design is like this? > > Actually I believe having the values be free-running without > clamping them makes the code much simpler -- the reason being that > you preserve the invariant of "in" always being ahead of "out". If > you reduce the pointers modulo the size, then you end up having a > lot of code that has two cases: one to handle "in > out", and one to > handle "in < out because in has wrapped and out hasn't yet".
yes, i see your point. so, as i read it, the internal kfifo "in" and "out" pointers are *never* actually normalized modulo the buffer size, which means that, at any time, you can easily check how much *total* data has gone through the kfifo. potentially useful. perhaps there should be a comment or note to that effect stuffed in there somewhere as some kernel programmers might find that handy, who knows?
rday --
======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ========================================================================
| |