lkml.org 
[lkml]   [2004]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC, 2.6] a simple FIFO implementation
this is nice, I had to write a ring buffer myself last month for
bootcache (you can find the patch on l-k searching for "bootcache"). It
was fun so I don't mind but certainly it took me a few reboots to make
it work ;)

My main issue with this is that I don't like to use kmalloc, I expect
most people will use a page anyways, I'm using alloc_page myself (and I
may want to switch to vmalloc to get a larger buffer, that's fine for
bootcache since the allocation is in a slow path). I wonder if it worth
to generalize the allocator passing down a callback or something like
that. I can still use kmalloc but it'd be just a waste of some memory
and risk fragmentation for >PAGE_SIZE (OTOH the callback as well will
waste some byte).

The other issue with the locking is that I will not need locking since
I've my own external locking used for other stuff too that serializes
the fifo as well, so I wonder if the "spinlock_t *" could as well be
passed down to kfifo_get so I won't need to allocate the spinlock
structure as well inside the kfifo. Otherwise I could start to use such
a spinlock inside the kfifo for the external locking too (and then I
could call only the __ functions), that means guys outside your
kfifo.[ch] would use the kfifo->lock which doesn't sound that clean,
kfifo using an external lock passed down by the caller as parameter
looks more robust.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.081 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site