On Saturday 22 August 2009, George Spelvin wrote: > >> It seems that the problem lies on the gs_buf_space_available(), more > >> specifically related to that "-1" you added, I believe, to report > >> "correctly" when you have an empty buffer, since: > >> > >> (buf_size + buf_get - buf_put) % buf_size > >> > >> would return 0 on that situation. > > > That's fairly standard for ring buffers; it avoids an extra > > state varible to distinguish whether "both pointers are the > > same" means empty or full. That simplifies the logic. > > The other way to do it, when buf_size is a power of 2 (as it is in this case), is > to have get and put *offsets* (not pointers) which count mod UINT_MAX, and > you mask them mod WRITE_BUF_SIZE (== 8192) before indexing into the buffer. > > That lets you use every byte in the buffer. > > (You can do it with non-power-of-2 buffers actually, but you have to have > the offsets operate mod 2*buf_size and it gets a bit more intricate.) There are a whole lot of tricks folk use to speed up ring buffer code; yes. > One thing I wonder is why have a run-time buf_size variable if its value > is always a compile-time constant... I suspect that code just got recycled from somewhere else. Patches accepted. :) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
