eeh@netbsd.org writes:
> 	PROP_CONST must also be stored, and also completely munges the
> 	underlying storage mechanism...
> 
> As I said, neither PROP_STRING nor PROP_CONST are stored in the
> property.  And it is not possible to determine whether a property
> was created with PROP_CONST or not after it has been created.

OK, i looked at your implementation.  PROP_CONST is not stored.  (does
this mean that duplication loses PROP_CONST-ness? seems losing)

PROP_STRING is stored, albeit very strangely: it inverts the length.

Doing flags via negative numbers is ... Special.


> 	However, until it's attached, it should _not_ be linked into the tree
> 	of devices.  It's not a device.
> 
> It is a device.

It's not an actual device until it's done being attached.


> There are no property containers.  Properties cannot be accessed
> without a device.  If properties can disassociate themselves with
> a particular device you have chaos.  You end up with a flat 
> namespace and cannot distinguish between instances of the same
> property associated with different devices.

I'm sure you _could_ do that...


> 	config_found() is _never_ used for indirect config devices.
> 	submatch is used to do a check of the config-supplied locators against
> 	the ones actually supplied by the bus.  You can think of submatch
> 	functions for direct config as code which would otherwise have to be
> 	in every single driver attached to a given direct config bus.
> 
> 	It just doesn't make sense to try to use config_found() for indirect
> 	config.  direct config / config_found says "I have found this device,
> 	find me a driver which matches it."
> 
> Er, no, the current implementation is more like "I have found 
> this slot, scan over the list of all devices specified in the 
> config file as children of this bus, checking to see if they're 
> there."  If what you said above is really supposed to happen then 
> the code to scan for a particular driver before calling the match
> routine seems to be missing.

I think you're splitting words here.

For the purpose of direct config, "a device that you have found" is
defined to be, basically, "the set of stuff you know about a device in
a particular location."

That _doesn't_ include anything to scan for a particular driver.
scanning for a driver that matchis is the point of config_found().
Trying to put it in the bus would mean that you put code in the bus
for every device.

The difference between direct config and indirect config tends to be:
direct config has well-defined locations known in advance where one
can look for devices, and well-defined ways to identify the devices in
those locations, and the code that does direct config only
config_found()s a device if there's something in the slot that looks
not-insane.  It's not a 100% well defined line.  But in general, using
config_found() means "I know something is there, but not necessarily
what it is."


> Could you be a bit more specific about what the difference between
> direct and indirect config?  Looking at the code, it would seem
> that isa could be implemented easily using direct config.  Or
> does it have something to do with indirect config buses not knowing
> how many slots they have?

Or, not having anything well defined in terms of addressable slots at
all.

ISA may have physical slots, but it's free-form in terms of
addressing.

> 	If all you get are a void * and a parent name pointer, how do you know
> 	what that void * is (if it could be a 'struct device *' or an aux
> 	ptr)?
> 
> It's obviously whatever you are supposed to be called with.
> If you're using config_found() then config_found() will determine
> if you belong to a new device or old device and use the appropriate
> parameter.

*sigh*  the and how does the print routine know which it got, if all
it has is a pnp and a void *?

if all you have are those two things, you can't figure out what the
void * actually is unless you do something really bogus.


> 	However, match also (arguably) has the responsibility to check for
> 	resource availability, etc.  A non-device-specific match routine can't
> 	really satisfy that.
> 
> I don't think that can be done in the match routine.  In many cases
> only way you can be sure that you have all the resources you need 
> is to claim them.  And if you do that in the match routine you may 
> allocate resources that will never be used because a better match
> is found later and that particular instance never attaches.  If you
> are concerned about resource availability, that should be handled
> in the attach routine, not the match routine.

you can be sure you'll have them:

match routines aren't allowed to hold resources after the exit.

That means that you can check for resource allocation in match, free
it all, run other match rtns, etc., and then whoever wins can allocate
their resources.

There are two things that would keep this from being possible:

* allowing multiple entries into the configuration code at once, and

* changes in allocated memory.

The former is a fairly obvious thing to disallow, and not harmful.
The latter is solved by using wait-capable calls for allocation.



cgd