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:	Sun, 31 Dec 2006 12:45:31 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	jengelh@...ux01.gwdg.de
Cc:	wmb@...mworks.com, devel@...top.org, linux-kernel@...r.kernel.org,
	jg@...top.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem

From: Jan Engelhardt <jengelh@...ux01.gwdg.de>
Date: Sun, 31 Dec 2006 15:12:26 +0100 (MET)

> BUT, the eeprom utility may be used to modify values, and if used, I
> would like to see ofwfs show the updated value. openpromfs does it
> today:
> 
> 15:09 ares:/proc/openprom/options # cat oem-banner?
> false
> 15:09 ares:/proc/openprom/options # eeprom 'oem-banner?=true'
> 15:09 ares:/proc/openprom/options # cat oem-banner?
> true
> 
> (BTW, why does not openpromfs have it rw?)

It used to be able to :-)

When I changed sparc/sparc64 over to an in-memory copy of the
OFW tree, I wasn't able to retain writable property support
in openpromfs.  It just needs to be implemented and I never
found the desire nor time.

Happily, everyone uses 'eeprom' or some other program accessing
the tree via /dev/openprom to change values.

I'm incredibly surprised how much resistence there is from the
i386 OFW folks to do this right.  It would be like 80 lines of
code to suck the device tree into kernel memory, or if they don't
want to do that they can use inline function wrappers to provide
the clean C-language interface to all of this and the cost to
i386-OFW would be zero with the benefit that other platforms could
use the code potentially.

Doing the same thing 3 different ways, knowingly, is just very bad
engineering.  That is how you end up with a big fat pile of
unmaintainable poo instead of a clean maintainable source tree.  If we
fix a bug in one of these things, the other 2 are so different that if
the bug is in the others we'll never know and it's not easy to check
so people won't do it.

So please do this crap right.

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