Re: [6/9] [RFC] Steps to fixing the driver model locking

[Christoph Hellwig]

On Mon, Mar 21, 2005 at 12:48:47PM -0800, Patrick Mochel wrote:
> 
> ChangeSet@xxxxxx, 2005-03-21 11:45:16-08:00, mochel@xxxxxxxxxxxxxxxxxx
>   [klist] Add initial implementation of klist helpers.

>   This klist interface provides a couple of structures that wrap around
>   struct list_head to provide explicit list "head" (struct klist) and
>   list "node" (struct klist_node) objects. For struct klist, a spinlock
>   is included that protects access to the actual list itself.

Not sure this is a good idea.  Usually you want a lock protect slightly
more than just list operations, e.g. refcounting of objects in list,
some short-term manipulations, etc.

>   struct
>   klist_node provides a pointer to the klist that owns it and a kref
>   reference count that indicates the number of current users of that node
>   in the list.
> 
>   The entire point is to provide an interface for iterating over a list
>   that is safe and allows for modification of the list during the
>   iteration (e.g. insertion and removal), including modification of the
>   current node on the list.
> 
>   It works using a 3rd object type - struct klist_iter - that is declared
>   and initialized before an iteration. klist_next() is used to acquire the
>   next element in the list. It returns NULL if there are no more items.
>   This klist interface provides a couple of structures that wrap around
>   struct list_head to provide explicit list "head" (struct klist) and
>   list "node" (struct klist_node) objects. For struct klist, a spinlock
>   is included that protects access to the actual list itself. struct
>   klist_node provides a pointer to the klist that owns it and a kref
>   reference count that indicates the number of current users of that node
>   in the list.

Yikes.  It's really not that hard to get traversal of a refcounted list
right, and you're adding lots of obsfucation over that rather easy thing.
The driver model and kfoo stuff already got us lots of layer of obsfucation,
but we should really stop at some point where it makes the underlying
operations much more complicated.

>   There are primitives for adding and removing nodes to/from a klist.
>   When deleting, klist_del() will simply decrement the reference count.
>   Only when the count goes to 0 is the node removed from the list.

This sounds rather odd, and doesn't make much sense to me.  In all cases
I've seen you want to disallow lookup imediately (list_del), which is
completly separate from object lifetime rules.

-
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/