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]

Date:	Mon, 1 Jan 2007 04:33:13 +0100
From:	Segher Boessenkool <segher@...nel.crashing.org>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	linux-kernel@...r.kernel.org, devel@...top.org,
	David Miller <davem@...emloft.net>, dmk@...x.com,
	wmb@...mworks.com, jg@...top.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem

>>> All we've done is created a trivial implementation for exporting
>>> the device tree to userland that isn't burdened by the powerpc
>>> and sparc legacy code that's in there now.
>>
>> So now we'll have _3_ different implementations of exporting
>> the OFW device tree via procfs.  Your's, the proc_devtree
>> of powerpc, and sparc's /proc/openprom
>>
>> That doesn't make any sense to me, having 3 ways of doing the same
>> exact thing and making no attempt to share code at all.

Not the same exact thing -- using a text representation for
the property contents is a very different thing (and completely
braindead).

>> If you want to do something new that consolidates everything, with the
>> goal of deprecating the existing stuff, that's great!  But with they
>> way you're doing this, all the sparc and powerpc implementations
>> really can't take advantage of it.

The problem is that it is almost impossible to consolidate the
current OF code.  It would be possible to consolidate the
filesystem code only though (and that's a good plan of course).

>> Am I the only person who sees something very wrong with this?
>
> No, I completely agree with you on this.
>
> If firmworks really wants to have a spearate filesystem that's fine.
> But please start with the ppc or sparc code and massage it into a
> a separate filesystem before adding support for a new platform.

It's so much easier to start from scratch in this case ;-)

> In case anyone wants to start this based on ppc I'd gladfully help
> to test this on pmac (32 and 64bit) and cell (64 bit).

Let's not base it on the PowerPC code, we don't want /proc.

How about this as a high-level design, it would be simple for
the OLPC guys to implement, and very easy for the other archs
to hook up to:

Every architecture that supports the device tree filesystem,
initialises a "struct device_tree_ops" with a bunch of
pointers to functions that allow you to traverse the device
tree and read its properties (and maybe write properties, or
even delete and create new nodes.  The devtree filesystem code
simply calls into these functions to do the actual operations
on the device tree (access an in-kernel data structure, call
the OF, or both -- or something entirely different, who knows).

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/