Jason R Thorpe <thorpej@zembu.com> writes:
	>  > i can see the "need" for two types, then: string & binary data.
	> 
	> What byte order is the binary data in?

What byte order is sysctl() data in?

	Is there any sane answer _other_ than 'native'?

	(I suppose for large not-obvious-in-nature properties extracted from
	firmware via md_getprop(), there might be a question...  but it's not
	clear to me what you could do that about that...)

In this case either md_getprop() needs to do the conversion,
or the device doing the request nees to know the value is
in the wrong format and do the conversion.  The former makes
more sense since the value would have to come from some really
weird location to be in the wrong format.

	Anyway, that kind of thing is what made me think that we should try to
	stick to well-defined native types, with 'unknown' being used only as
	a safety valve to allow compatible expansion.

Properties should have standardized formats, and if you
don't know the layout of a property you should not request
it.  Types should only be required by userland property
grovellers which can be made smart enough to handle this
themselves w/o bloating the kernel.  If it can distinguish
between ASCII and binary so it can dump some as strings and
others as hex, that's good enough for humans to decypher 
the properties.

Eduardo.