eeh@netbsd.org writes:
> Right.  See the accompanying patch.

People shouldn't have to even look at the patch to get a clear
understanding of how the idea works.

Unfortunately, I don't have time to spend reading anything other than
'final' patches.  I probably don't even have time for that.


> I struggled with this a bit and decided that using `struct device *' in
> some contexts and `struct devproplist *' in others broke orthogonality, 
> encapsulation, and consistency.  

I don't see why you'd use 'struct device' in any when dealing with the
properties, actually.

It would probably be nice to have a conveninence macro to give you the
properties for a given device, which could simply be a macro at this
point.


> The interfaces could all be changed to operate on device property lists,
> but that doesn't seem as clean an implementation to me.

It's certainly better than faking up a bogus 'struct device,' to my
mind.

> That would also
> preclude any possibility of implemnting as anything other than a linked
> list in future, such as database table.

Why would it do that?


I think if you do all of the above, you;

(1) end up with an interface that nicely encapsulates device
properties as separate objects,

(2) you don't end up with gross hacks like faking up a struct device,

(3) it doesn't actually hurt your ability to implement things in a
database at some point in the future,

(4) if you find that you _really need_ the properties container to be
a 'struct device' for some reason, you could in fact do that with
minimal work.


> 	I'm not sure I like the extra copying that get_devprop() requires,
> 	either, but I'm kinda ambivalent about that.
> 
> It simplifies memory management since you don't need to worry about
> having dangling references to data that's been freed.

Yeah -- I think it's reasonable.  There's probably no better solution.



> Anyway, if you plan to replace the aux information with properties, it is
> best to encode them as separate proerties rather than a fixed `aux'
> structure.

Yeah, that's fairly obvious.

The case i'm most worried about is where you're passing down e.g. a
'bus chipset' handle of some sort, and want to make sure it doesn't
accidentally get nuked while you're still using it...



cgd