Proposal for device-tree walking semantics

Proposal for device-tree walking semantics

[Benjamin Herrenschmidt]

Hi !

We all know those need to change, the way they currently work
by returning a linked list of devices is terminally broken
regarding any form of concurrent access...

Here is an example of semantics that I'm implementing in my
tree (no patch below yet, just the definitions), with the additional
notes below:

 - Though I haven't implemented refcounting, I added a get/put()
set of functions and define that all of those "find" functions
will return a got'en object that need to be put. That will allow
us to add proper refcounting implementation later, or wrap a
kobject in there. The get() function is actually more a try_get()
(the idea is that a remove in progress would make it fail)

 - What about renaming struct device_node to struct of_node ? We
could keep a #define for now (2.5) and get rid of device_node
later ? I find the current naming confusing.

Here we go:

extern struct device_node *of_find_device_by_name(struct device_node
*from,
	const char *name);
extern struct device_node *of_find_device_by_type(struct device_node
*from,
	const char *type);
extern struct device_node *of_find_compatible_device(struct device_node
*from,
	const char *type, const char *compat);
extern struct device_node *of_find_device_by_path(const char *path);
extern struct device_node *of_find_all_devices(struct device_node
*prev);
extern int of_device_get(struct device_node *node);
extern int of_device_put(struct device_node *node);

Comments ?

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Proposal for device-tree walking semantics

[Nathan Lynch]

(Apologies if this doesn't get associated with the original post
correctly, the original post was forwarded to me.)

I've been looking at this issue a bit from the ppc64 side.

 > The get() function is actually more a try_get()
 > (the idea is that a remove in progress would make it fail)

Regarding removal of nodes, how might the removal of files under
/proc/device-tree be handled?  Note that the data pointers associated
with each proc entry refer to struct property's, not device_node's.
Should the struct property's have refcounts too?  Also note that
add_node() in fs/proc/proc_devtree.c creates symbolic links; I haven't
been able to come up with a pleasing solution for removing those.  It
seems to require a manual traversal of the proc_dir_entry's subdir list,
an operation during which the procfs code holds the big kernel lock
(e.g. proc_lookup()).

I agree with renaming device_node to of_node.

Nathan


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Proposal for device-tree walking semantics

[Benjamin Herrenschmidt]

On Tue, 2003-06-24 at 18:53, Nathan Lynch wrote:
> (Apologies if this doesn't get associated with the original post
> correctly, the original post was forwarded to me.)
>
> I've been looking at this issue a bit from the ppc64 side.
>
>  > The get() function is actually more a try_get()
>  > (the idea is that a remove in progress would make it fail)
>
> Regarding removal of nodes, how might the removal of files under
> /proc/device-tree be handled?  Note that the data pointers associated
> with each proc entry refer to struct property's, not device_node's.
> Should the struct property's have refcounts too?  Also note that
> add_node() in fs/proc/proc_devtree.c creates symbolic links; I haven't
> been able to come up with a pleasing solution for removing those.  It
> seems to require a manual traversal of the proc_dir_entry's subdir list,
> an operation during which the procfs code holds the big kernel lock
> (e.g. proc_lookup()).
>
> I agree with renaming device_node to of_node

I currently have no definitive idea on how to implement removal and
such... I think the kobject mecanism may help, but that's not something
I've studied enough. The problem on how memory is allocated for
properties and then how to free it remains.

For now, what I care about is to have proper semantics for "clients" of
the device-tree so that things like removal can be implemented properly
later on.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/