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

Powered by blists - more mailing lists