eeh@netbsd.org writes:
> I don't think that this buys you much.  Most of the time the 
> name of the property will imply its type.

To 'direct' users of the property, yes.  Not to 'third parties' who
happen to be traversing the property list.

For direct users, it helps less, I'll grant you that.


> The width of the types
> is recorded in the property and can be queried 
> (dev_getprop(dev, "name", NULL, 0 /*len*/, 0) will return it.

Yes.


> Typing properties is only useful when they are not single integral
> values of variable width, but aggregates of multiple values.
> Specifying that sort of thing results in having to marshall and
> unmarshall properties.  I think that sort of thing really is too
> much kernel growth.

I don't think you need to worry about marshalling & umarshalling so
much, unless you really want to go into the whole external data
representation thing.  And I don't think we do.

What i'm thinking about is the case where one of the properties you
might want to pass is either a constructed integer, or a 'small'
structure (e.g. 2 4 byte values that otherwise would have been passed
by value).

And example of a constructed integer is pcitag_t.  (you could also
imagine that it could be implemented as a small pass-by-value struct
on some systems, actually.)

What do you print when you see a pcitag_t property?  0x01234567?  or
something more meaningful?  hopefully the latter, since the actual
meaning of the type has machine-dependent interpretation.


> The only distinction I see as useful would be to differentiate
> string properties from binary ones, so you could print out
> a device tree and know that the property "powered-up" was "yes"
> rather than 0x79657300.

yes, at minimum, that's pretty much necessary in my opinion.


> And if you really want to provide some readable way to describe
> and aggregate type, you could always provide a string property
> "foo-type" which describes the individual fields in property "foo".

I don't want to provide some way to describe aggregates.  I just want
them to be known as aggregates with some machine-dependent
interpretation.  MD code can then do the unpacking for display and
printing as far as I care (and maybe size sanity checking).
Everything else could use them as bytes.



cgd