From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Date: Tue, 02 Jan 2007 15:05:59 +1100
> It has proved a good idea in general as I can easily get an exact > device-tree dump from users by asking for a tarball of /proc/device-tree > and in some case, the data in there -is- binary (For example, the EDID > properties for monitors left by video drivers, or things like that). Yes and with openpromfs I can get the EDID too :-) [EMAIL PROTECTED]:/proc/openprom/[EMAIL PROTECTED],700000/SUNW,[EMAIL PROTECTED] cat edid 00ffffff.ffffff00.4dd9d000.67175700.2d0d0103.0e321f78.eacea9a3.574c9926.19484cbd.ee80a940.81808140.01010101.01010101.0101734b.80a072b0.2a4080d0.1300ef35.1100001c.483f4030.62b03240.40c01300.ef351100.001e0000.00fd0037.411e5f14.000a2020.20202020.000000fc.0053444d.2d503233.32570a20.202000af [EMAIL PROTECTED]:/proc/openprom/[EMAIL PROTECTED],700000/SUNW,[EMAIL PROTECTED] I think there is high value in an OFW filesystem representation that gives you _EXACTLY_ what the OFW command line prompt does when you try to traverse the device tree from there, and that is what openpromfs tries to do. If you want raw access, use a character device or a similar auxilliary access to the data items. Another idea is to provide a seperate file operation (such as ioctl) on the OFW property files in order to fetch things raw and in binary. When I get some binary data out of a procfs or sysfs file I feel like strangling somebody. I'm grovelling around in a filesystem from the command line so that I can get some information as a user. If you don't give me text I can't tell what the heck it is. Simple system tools should not need to interpret binary data in order to provide access to simple structured data like this, that's just stupid. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
