From: David Miller <davem@davemloft.net>
To: segher@kernel.crashing.org
Cc: hch@infradead.org, linux-kernel@vger.kernel.org,
devel@laptop.org, dmk@flex.com, wmb@firmworks.com, jg@laptop.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem
Date: Mon, 01 Jan 2007 00:57:14 -0800 (PST) [thread overview]
Message-ID: <20070101.005714.35017753.davem@davemloft.net> (raw)
In-Reply-To: <445cb4c27a664491761ce4e219aa0960@kernel.crashing.org>
From: Segher Boessenkool <segher@kernel.crashing.org>
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.
next prev parent reply other threads:[~2007-01-01 8:57 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-31 1:38 [PATCH] Open Firmware device tree virtual filesystem Mitch Bradley
2006-12-31 5:19 ` David Miller
2006-12-31 9:36 ` Mitch Bradley
2006-12-31 9:52 ` David Miller
2006-12-31 10:11 ` David Kahn
2006-12-31 10:49 ` David Miller
2006-12-31 11:47 ` Rene Rebe
2006-12-31 11:53 ` David Kahn
2007-01-01 3:48 ` Segher Boessenkool
2007-01-02 3:56 ` Benjamin Herrenschmidt
2007-01-02 18:43 ` Richard Smith
2006-12-31 15:41 ` Christoph Hellwig
2006-12-31 20:46 ` David Miller
2007-01-01 3:37 ` David Kahn
2007-01-01 8:54 ` David Miller
2007-01-02 4:02 ` Benjamin Herrenschmidt
2007-01-02 12:28 ` Segher Boessenkool
2007-01-01 3:33 ` Segher Boessenkool
2007-01-01 8:57 ` David Miller [this message]
2007-01-01 17:48 ` Segher Boessenkool
2007-01-01 23:08 ` David Miller
2007-01-01 23:52 ` Segher Boessenkool
2007-01-02 3:31 ` David Miller
2007-01-02 11:26 ` Segher Boessenkool
2007-01-02 1:40 ` David Kahn
2007-01-02 3:36 ` David Miller
2007-01-01 18:10 ` Mitch Bradley
2007-01-01 19:21 ` Jan Engelhardt
2007-01-02 4:05 ` Benjamin Herrenschmidt
2007-01-02 4:30 ` David Miller
2007-01-02 4:57 ` Benjamin Herrenschmidt
2007-01-02 5:01 ` David Miller
2007-01-02 5:09 ` Benjamin Herrenschmidt
2007-01-02 5:44 ` David Miller
2007-01-02 12:36 ` Segher Boessenkool
2007-01-02 11:03 ` Segher Boessenkool
2007-01-02 3:53 ` Benjamin Herrenschmidt
2007-01-02 12:22 ` Segher Boessenkool
2007-01-02 20:12 ` Benjamin Herrenschmidt
2007-01-02 21:28 ` Segher Boessenkool
2007-01-02 21:32 ` Benjamin Herrenschmidt
2007-01-02 21:40 ` Segher Boessenkool
2007-01-02 22:10 ` David Miller
2007-01-02 22:05 ` David Miller
2007-01-03 0:48 ` Segher Boessenkool
2007-01-03 4:34 ` David Miller
2007-01-03 15:23 ` Segher Boessenkool
2007-01-04 2:15 ` David Miller
2007-01-02 3:45 ` Benjamin Herrenschmidt
2007-01-02 3:49 ` David Miller
2007-01-02 11:45 ` Segher Boessenkool
2007-01-02 20:07 ` Benjamin Herrenschmidt
2006-12-31 13:24 ` Pekka Enberg
2006-12-31 18:55 ` Mitch Bradley
2006-12-31 14:12 ` Jan Engelhardt
2006-12-31 20:45 ` David Miller
2006-12-31 21:30 ` Jan Engelhardt
2007-01-02 3:43 ` Benjamin Herrenschmidt
2007-01-02 11:37 ` Segher Boessenkool
2007-01-02 13:22 ` Stefan Reinauer
2007-01-02 20:08 ` Benjamin Herrenschmidt
2007-01-02 20:11 ` Mitch Bradley
2007-01-02 20:48 ` Benjamin Herrenschmidt
2007-01-02 21:37 ` Segher Boessenkool
2007-01-02 21:47 ` Benjamin Herrenschmidt
2007-01-03 0:35 ` Segher Boessenkool
2007-01-03 0:44 ` Benjamin Herrenschmidt
2007-01-03 1:14 ` Segher Boessenkool
2007-01-03 4:35 ` David Miller
2007-01-02 22:07 ` David Miller
2007-01-03 0:52 ` Segher Boessenkool
2007-01-03 1:13 ` Jan Engelhardt
2007-01-03 4:38 ` David Miller
2007-01-03 5:05 ` Benjamin Herrenschmidt
2007-01-03 15:59 ` Segher Boessenkool
2007-01-03 15:31 ` Segher Boessenkool
2007-01-03 4:34 ` David Miller
2007-01-02 21:15 ` Segher Boessenkool
2007-01-02 21:59 ` David Miller
2007-01-01 3:40 ` Segher Boessenkool
2007-01-01 4:21 ` Segher Boessenkool
-- strict thread matches above, loose matches on Subject: below --
2007-01-11 17:39 ron minnich
2007-01-11 17:53 ` Mitch Bradley
2007-01-11 17:55 ` ron minnich
2007-01-11 18:36 ` Segher Boessenkool
2007-01-11 18:20 ` Stefan Reinauer
2007-01-11 18:47 ` Segher Boessenkool
2007-01-11 19:12 ` ron minnich
2007-01-11 19:11 ` ron minnich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070101.005714.35017753.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=devel@laptop.org \
--cc=dmk@flex.com \
--cc=hch@infradead.org \
--cc=jg@laptop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=segher@kernel.crashing.org \
--cc=wmb@firmworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox