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: <c7212f93de62c2f7f50be71f257c8974@kernel.crashing.org>
Date:	Tue, 2 Jan 2007 22:15:50 +0100
From:	Segher Boessenkool <segher@...nel.crashing.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	linux-kernel@...r.kernel.org, devel@...top.org,
	jengelh@...ux01.gwdg.de, David Miller <davem@...emloft.net>,
	wmb@...mworks.com, jg@...top.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem

>> 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

-
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