eeh@netbsd.org writes:

> 	> 	These are logically two different sets of flags.  They should be
> 	> 	separated.
> 	> 
> 	> Well, they are being passed in in the same `flags' field in
> 	> dev_setprop() and dev_getprop() so it would be better if they
> 	> don't conflict with one another.
> 
> 	I believe the point is, different sets of flags should _not_ be
> 	#defined in the same set, _or_ passed together, _or_ stored together
> 	in e.g. structures.
> 
> 	Why would it ever make sense to reserve a bit for PROP_WAIT in a
> 	property structure, for instance?
> 
> PROP_WAIT does not make sense on a property structure.  So
> you want to pass 3-4 different `flag' parameters to these calls?

I've thus far only seen the need for 2 flags parameters:

	* one containing "lookup flags", e.g. wait (no inherit at all;
	  see other mail 8-)

	* one containing "property flags" for those calls that need
	  them.  property flags are things like, is a string, is
	  const, etc.  flags that are stored with the properties.

You don't see, e.g. the malloc type being thrown in the the malloc
flags...  That's analogous.


> 	> 	The goal here is to completely remove 'aux' right?  Well, if you do
> 	> 	that, why should we have to go through and edit large numbers of
> 	> 	drivers in the tree when it's time to do that?
> 	> 
> 	> The goal is to remove `aux' eventually, but if you don't
> 	> provide it to the dev_config*() routines, a parent bus
> 	> cannot have both old-style children and children that
> 	> have been converted.  Maybe we need three sets of functions:
> 	> old, transitional, and new.
> 
> 	Three sets of functions is basically what i've been suggesting pretty
> 	much all along, yes.
> 
> O.K.  This is going to make things more complicated....

Not really...  Internally, the old-only and new-only ones can wrap the
old+new...


> 	Go back and read the thing i've suggested you implement.
> 
> 	In short form, to answer your questions in order:
> 
> 	(1) new style drivers should _not_ be able to attach to busses which
> 	haven't at least been converted for old+new compatibility.
> 
> 	(2) no, you only need to convert the bus to old+new compatibility,
> 	then you can convert invididual drivers as need be.
> 
> 	(3) That's irrelevant, because if you do it right (or even the way i
> 	suggested 8-) you can get seamless compatibility with existing
> 	drivers.
> 
> Given that, and that more bus drivers tend to be MD than
> device drivers, if one port converts its bus drivers and
> starts on the MI device drivers for a type of bus, but 
> another port with the same bus does not, those MI drivers
> will cease to work on the second port.  Do you really think
> this behavior will be considered acceptable?

Huh?  I think this is incorrect.

If you want to have MI attachments for devices to a given bus, first
you must have an MI driver for the bus itself.  (I suppose you could
have a well-defined interface that the MD bus driver follows, but I
don't know of examples of that at this time.)

Do you have examples where we have an MD bus, and MI drivers that
attach to that bus?

Note that e.g. PCI, etc., are abstracted:

* you have an MD driver that attaches the MI pci bus, for instance,

* you have an MI pci bus

* you have MI pci device drivers (and also MD ones).


I don't see a problem there.



chris