lkml.org 
[lkml]   [2010]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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
========================================================================


\
 
 \ /
  Last update: 2010-03-17 12:27    [W:0.062 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site