linux-kernel - Re: [PATCH] Open Firmware device tree virtual filesystem

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

> I do object basically to having something that doesn't also provide
> in-kernel interfaces to access the device nodes & properties.

That's the wrong way around.  Work is underway to instead
have the devicetreefs *use* the in-kernel interfaces.  Would
that be acceptable?

> I don't
> agree with the reasoning that x86 will never need it.

Neither do I :-)

> Now, we have
> currently two slightly different interfaces, on powerpc and sparc, to
> access them, and that's I think we should try to converge and use the
> same interface for x86.

All should converge on the same interface.  That does not
ab initio mean we should converge on what you currently
have (although that might eventually be that case).

> In addition, as sparc64 also moved to an in-memory copy of the tree, I
> tend to be fairly convinced that we should also move toward the same
> -implementation- also based on an in-memory copy of the tree which is
> more efficient (and doesn't use a significant amount of RAM).

Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...


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/