From: Segher Boessenkool <segher@kernel.crashing.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-kernel@vger.kernel.org, devel@laptop.org,
jengelh@linux01.gwdg.de, David Miller <davem@davemloft.net>,
wmb@firmworks.com, jg@laptop.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem
Date: Tue, 2 Jan 2007 22:15:50 +0100 [thread overview]
Message-ID: <c7212f93de62c2f7f50be71f257c8974@kernel.crashing.org> (raw)
In-Reply-To: <1167768494.6165.63.camel@localhost.localdomain>
>> Are you really suggesting that using a kernel copy of the
>> device tree is the correct thing to do, and the only correct
>> thing to do -- with the sole argument that "that's what the
>> current ports do"?
>
> Well, there are reasons why that's what the current ports do :-)
Sure. It might have been a good choice for the current two ports
(probably was even, at least at that point in time the choice was
made -- doesn't mean you can't ever step back on it).
That doesn't mean it's a good choice for everything and certainly
it's not the only realistic choice for everything.
> We could of course have the interface work either on a copy of the tree
> or on a real OF
Yes. I'd like to steer in that direction eventually.
> (though that means changing things like get_property on
> powerpc
You can keep the function name, and have it redirect through
a struct device_tree_ops or similar.
> and fixing the gazillions of users)
which isn't needed if we can manage to keep the function arguments
identical.
We also can keep the old names as compatibility accessors for
PowerPC only for a while, until everything is converted -- SPARC
can do the same then. You can't really keep the old PowerPC names
in kernel-wide code anyway, "get_property" is a way too generic
name for that for example.
> but I tend to think that
> working on a copy always is more efficient.
In general, nothing using the device tree cares about a few
cycles extra (well, a few thousand perhaps). The sole exception
would seem to be the filesystem; and it could easily keep a cache,
one with a global invalidate (via callback?) on any device tree
change even -- changes are infrequent, and basically non-existent
after early kernel boot. Does any generic such cache for all
simple filesystems exist already?
Segher
next prev parent reply other threads:[~2007-01-02 21:15 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
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 [this message]
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=c7212f93de62c2f7f50be71f257c8974@kernel.crashing.org \
--to=segher@kernel.crashing.org \
--cc=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=devel@laptop.org \
--cc=jengelh@linux01.gwdg.de \
--cc=jg@laptop.org \
--cc=linux-kernel@vger.kernel.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