Messages in this thread | | | Subject | Re: Elimination of klists | From | James Bottomley <> | Date | Sun, 11 Sep 2005 18:37:50 -0500 |
| |
On Sun, 2005-09-11 at 15:25 -0700, Andrew Morton wrote: > James Bottomley <James.Bottomley@SteelEye.com> wrote: > > > > Actually, the concept of a klist is quite nice, and the beauty is that > > all the locking is internal to them, so users can't actually get it > > wrong (I like interfaces like this). > > You're a bit screwed if you want to use them from interrupts..
Yes, but then they're for refcounted lists. Quite a few of our refcounted structures aren't safe for final put from interrupt either. I take the implied point about wanting to leave the lock selection up to the list head provider... I just can't see an elegant way of implementing it given how tightly klist iterators have to bind to the locking and refcounting. We could always add another pair of list_head_lock() list_head_unlock() functions which it's up to the list_head provider also to supply ... I'm just surprised I didn't get hammered for using that nasty OO concept of delegates with the get/put functions ... I'm sure someone will notice if I do it a second time.
James
James
- 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/
| |