[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1167768735.6165.68.camel@localhost.localdomain>
Date: Wed, 03 Jan 2007 07:12:15 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Segher Boessenkool <segher@...nel.crashing.org>
Cc: linux-kernel@...r.kernel.org, devel@...top.org,
David Miller <davem@...emloft.net>, David Kahn <dmk@...x.com>,
Mitch Bradley <wmb@...mworks.com>, jg@...top.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists