Hello, all I have a few questions about kfifo, wishing your opinions. 1. Why __kfifo_init() roundup_pow_of_two(size) nor down? __kfifo_init() is called by kfifo_init() to initialize a fifo using a preallocated buffer. If the buffer size is not pow_of_two, it will be rounded up to the next power of two. But __kfifo_init() only adjusts the fifo's internal argument 'mask' to reflect the new size, DOES NOT adjust the preallocated buffer! If so, there would be a potential 'memory collapse'. Fortunately, I haven't caught any complaint about this. Maybe as kfifo_init() is the only caller and no much driver use it.
From http://linux-kernel.2935.n7.nabble.com/template/NamlServlet.jtp?macro=search... , I know, before 3.9 its algorithm was round down. After a big discussion, __kfifo_alloc and __kfifo_init all adopted 'to alloc at least the requested number of elements'. For __kfifo_alloc there is no problem, but for __kfifo_init it is wrong I think, because __kfifo_alloc's buffer is managed by kernel itself, __kfifo_init's buffer by user.
My question is, though few application scenarios and 'pow_of_two' rule should be obey, is it more robust back to round down? Then, 'if a user do the wrong thing, then the user will get also a wrong result', but NOT a wrong system. 2. Is it better to optimize __kfifo_in_r()? __kfifo_in_r() is an enqueue function, first it calls __kfifo_poke_n() to write the number of elements, then kfifo_copy_in() for actual elements. In kfifo_copy_in(), it adjusts 'buffer offset' by multiply 'element size' if esize != 1 before writing, but __kfifo_poke_n() doesn't -- that is, in special situation __kfifo_in_r() may use inconsistent offset unit to write this 2 kinds of data. Dequeue function __kfifo_out_r() also has the issue. I learn that the FIFO model with 'sizeof(datatype)>1 && recsize>0' is actually not supported by kernel. But to make a more 'generic kernel FIFO implementation', is it better to do a little fix of 2 helpers __KFIFO_PEEK and __KFIFO_POKE? Thanks, laokz