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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4599B809.1000300@flex.com>
Date:	Mon, 01 Jan 2007 17:40:25 -0800
From:	David Kahn <dmk@...x.com>
To:	David Miller <davem@...emloft.net>
CC:	segher@...nel.crashing.org, linux-kernel@...r.kernel.org,
	devel@...top.org, wmb@...mworks.com, hch@...radead.org,
	jg@...top.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem

David Miller wrote:

> We have some extensive code in fs/openpromfs/inode.c that
> determines whether a property is text or not.  I can't
> guarentee it works %100, but it's very context dependant
> (only the driver "knows") but it works for all the cases
> I've tried.

The problem with guessing, as you've noted, is that you
can't be 100% correct for device specific stuff.

Sure, you can guess that standard properties defined
by the core spec like "ranges" and "reg" consist of
integer data, but you can't make any guess about
device-specific stuff. (The heuristics you mentioned
just look at the data to see if it consists of printable
characters as far as I can tell, and that too isn't
foolproof, as you noted.)

Properties that consist of simple string data will just
show up as printable string data, but it's usually best to
leave the interpretation of binary properties up to the
entity that's consuming them, since they have to
know how to interpret them.

Also, the sparc port doesn't have to deal with
endian issues, since prop-encoding is big-endian.
There's really no way to "guess" properly.

A userland library or program can do whatever
it wants to as a helper. The interpretation of
the data should be done by the entity that consumes
it.

If that doesn't fit the model of /sys or /proc,
I suppose it could be done in a separate file
system, but that's overkill, isn't it?

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