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: <4597A4A2.9060304@flex.com>
Date:	Sun, 31 Dec 2006 03:53:06 -0800
From:	David Kahn <dmk@...x.com>
To:	David Miller <davem@...emloft.net>
CC:	wmb@...mworks.com, devel@...top.org, linux-kernel@...r.kernel.org,
	jg@...top.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem



David Miller wrote:
> From: David Kahn <dmk@...x.com>
> Date: Sun, 31 Dec 2006 02:11:53 -0800
> 
>> 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

I would not exactly call what we have for powerpc
"exporting the OFW device tree". I don't quite know
what it is, but it isn't as simple as exporting the
OFW device tree. I don't think we really wanted to
get into any of that here.

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

Sure they can take advantage of it, if what they need
to export is a read-only copy of the actual device tree
without any legacy burden or having a writable/changeable
copy of it with a trivial implementation. But that's not
up to us, and that's not what's been done for powerpc and
sparc.

This is a trivial implementation that suits it's purpose.
It's simple. I'm not sure what more is needed for this
project when it's pretty clear that i386 will never need
any additional support for open firmware.

-David


-
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