Re: [RFC, 2.6] a simple FIFO implementation

[Stelian Pop]

On Fri, Sep 17, 2004 at 03:41:45PM +0200, Andrea Arcangeli wrote:

> On Fri, Sep 17, 2004 at 03:36:58PM +0200, Stelian Pop wrote:
> > What about leaving kfifo_alloc as is (using kmalloc) and adding
> > 	struct kfifo *kfifo_init(unsigned char *buffer, spinlock_t *lock);
> > 	
> > which let's you specify the buffer and the spinlock you want to use.
> > Of course, one should not call kfifo_free() on such a struct kfifo...
> 
> I guess you need to pass down the size of the buffer too.

Of course... 

> > As a special case, the spinlock can be NULL and in this case it 
> > allocates it. But in this case we should also make a kfifo_delete()
> > to deallocate the lock...
> 
> that's fine with me, but allocating a lock dynamically? then probably
> you should force the caller to allocate it, and force it to pass it down
> either in the alloc or in the init function, the caller is going to have
> a bigger data structure where it will embed the kfifo structure, so it'd
> be normally zerocost for the caller to allocate a lock outside the
> kfifo, even if the API becomes a bit uglier, but I don't see the need of
> separate slab allocation for a single spinlock. 


Hmmm, allocating a single lock is ugly indeed, but I still want
the high level kfifo_get / kfifo_put to do the locking themselves...

We could do that by having a 'spinlock_t internal_lock' and a 
'spinlock_t * lock' fields, in struct kfifo: we always use 'lock' and
we initialize lock to either &internal_lock or to the user lock.

Stelian.
-- 
Stelian Pop <stelian@xxxxxxxxxx>    
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/