eeh@netbsd.org writes:
> You always need to worry about typing.  The easiet way to do that is
> to have the user program that tries to extract the properties and present
> them to the user know what the format is.  Creating self-descriptive
> data structures in the kernel is a recipe for extreme kernel bloat.

Then you need to encode in that user prorgram information about all
possible busses in the system.  Even the kernel doesn't need to know
that at any given time...


> 	Another issue here is, if you're going to do this, you need to have
> 	some real correspondence between locator names and names in the config
> 	file.  It's not clear to me that the way multi-value locators are
> 	currently done makes sense if you're really trying to use locators as
> 	names.  (It's a bit difficult to use in code, too, since you don't
> 	really have a loop bound you can use...)
> 
> Huh?

take a look at how multi-value locators are currently represented,
think about how you'd try to use them, etc.


> 	> My plan was to attach the properties to the cfdata the same
> 	> way locators are, only from different fields of the cfdata
> 	> structure so you can distinguish locators from other properites.  
> 	> Then they can be easily attached to the device node inside 
> 	> config_attach().  (Can't think of any reasonn the *match() 
> 	> routines would need access to properties.)
> 
> 	I can, but doing property attachment for match is pretty painful (how
> 	many times do you copy the bloody things?).
> 
> The number of copies depends on the number of probes.  The number
> of probes could be reduced if self-identifying buses would check
> the device they found with the devices supported by the driver rather
> than relying on locators and calling the device's match function.

the only way the self-identifying busses could do that would be in the
submatch functions.  They directly call the underlying match function,
so by the time parent submatch is called properties already have to be
set up.



> 	* debug spew.  It may be desirable to turn on extra buff debugging in
> 	  a driver via a property.  If there's some desire to allow that
> 	  debugging output/logging/whatever to be turned on during probe...
> 	  (I'm not sure that this is kosher, but i can imagine that it'd be
> 	  useful.)
> 
> We're only talking about the *match() routine.  Anyway, since
> changing a property requires re-running config, and recompiling
> large parts of the kernel, it is much better to use a patchable
> variable to control debugging.

uh...

changing a property could happen in many ways.  config is one of them.

supplying something e.g. to the firmware so that the MD getprop
routine will find it is another.

boot-time configuration is another.  Whatever is done here should be
amenable to that.



I want to mull this over for a few days.



cgd