public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: linux-kernel@vger.kernel.org, devel@laptop.org,
	David Miller <davem@davemloft.net>, David Kahn <dmk@flex.com>,
	Mitch Bradley <wmb@firmworks.com>,
	jg@laptop.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem
Date: Wed, 03 Jan 2007 07:12:15 +1100	[thread overview]
Message-ID: <1167768735.6165.68.camel@localhost.localdomain> (raw)
In-Reply-To: <24a109a8fa0f45011daf3e2b55172392@kernel.crashing.org>

On Tue, 2007-01-02 at 13:22 +0100, Segher Boessenkool wrote:
> > Except that none of the powerpc platforms can keep OF alive after the
> > kernel has booted, which is why we do an in-memory copy of the tree.
> 
> Adding that functionality hasn't gotten easier at all since
> we use the flattened tree for everything, heh.

Not for everything, only for the trampoline between the client interface
environment and the kernel. But yeah, we haven't tried hard to go in
that direction at all.

.../...

> Not single thread -- but a "global OF lock" yes.  Not that
> it matters too much, (almost) all property accesses are init
> time anyway (which is effectively single threaded).

Not that true anymore. A lot of driver probe is being threaded nowadays,
either bcs of the new multithread probing bits, or because they get
loaded by userland from some initramfs etc..

> > Finally, you can't have something as simple as powerpc's get_property()
> > (that just returns a pointer to the property content) with direct OF
> > access unless you use some magic static buffer or some crap around 
> > those
> > lines, or add passing of a buffer in, so from a driver pointer of view,
> > the interface provided by powerpc/sparc is nicer.
> 
> But since you have a _put() function anyway, for your reference
> counting, having magic (automatically allocated, not static of
> course) buffers works just fine.

You can maybe create an in-memory cache of all properties in a node from
whatever function that returns a node pointer and dispose of them on
_put(), that would allow to keep the get_property semantics as-is with a
"live" tree, but I still don't see the point

Ben.



  reply	other threads:[~2007-01-02 20:12 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 [this message]
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=1167768735.6165.68.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=devel@laptop.org \
    --cc=dmk@flex.com \
    --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