On Wed, 31 Oct 2012 07:30:33 +0100 Stefani Seibold <stefani@xxxxxxxxxxx> wrote:
Yes, and I guess the same to give them a 64-element one.
If there's absolutely no prospect that the kfifo code will ever support
100-byte fifos then I guess we should rework the API so that the caller
has to pass in log2 of the size, not the size itself. That way there
will be no surprises and no mistakes.
That being said, the power-of-2 limitation isn't at all intrinsic to a
fifo, so we shouldn't do this. Ideally, we'd change the kfifo
implementation so it does what the caller asked it to do!
I'm fine with removing the power-of-2 limitation. Stefani, what's your
comment on that?
You can't remove the power-of-2-limitation, since this would result in a
performance decrease (bit wise and vs. modulo operation).
Probably an insignificant change in performance.
It could be made much smaller by just never doing the modulus operation
- instead do
if (++index == max)
index = 0;
this does introduce one problem: it's no longer possible to distinguish
the "full" and "empty" states by comparing the head and tail indices.
But that is soluble.
Andrew is right, this is an API miss design. So it would be good to
rework the kfifo_init () and kfifo_alloc() to pass in log2 of the size,
not the size itself.
The power-of-2 thing is just a restriction in the current
implementation - it's not a good idea to cement that into the
interface. Of course, it could later be uncemented if the
implementation's restriction was later relaxed.