lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ