From: Segher Boessenkool <[EMAIL PROTECTED]> Date: Mon, 1 Jan 2007 04:33:13 +0100
> >>> All we've done is created a trivial implementation for exporting > >>> the device tree to userland that isn't burdened by the powerpc > >>> and sparc legacy code that's in there now. > >> > >> So now we'll have _3_ different implementations of exporting > >> the OFW device tree via procfs. Your's, the proc_devtree > >> of powerpc, and sparc's /proc/openprom > >> > >> That doesn't make any sense to me, having 3 ways of doing the same > >> exact thing and making no attempt to share code at all. > > Not the same exact thing -- using a text representation for > the property contents is a very different thing (and completely > braindead). The filesystem bit is for groveling around and getting information from the shell prompt, or shell scripts. Text processing. If you want the binary bits, export it with something like /dev/openprom. We don't generally export binary representation files out of /proc or /sys, in fact this rule I believe is layed our precisely somewhere at least in the sysfs case. > Every architecture that supports the device tree filesystem, > initialises a "struct device_tree_ops" with a bunch of > pointers to functions that allow you to traverse the device > tree and read its properties (and maybe write properties, or > even delete and create new nodes. The devtree filesystem code > simply calls into these functions to do the actual operations > on the device tree (access an in-kernel data structure, call > the OF, or both -- or something entirely different, who knows). That's the only key point in my opinion, any clean interface that sits in front of this stuff is fine as long as it encompasses all of the necessary operations and allows just about any implementation underneath. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
