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.

Actually, there are at least 3 different sets of flags:

	* lookup flags (PROP_INHERIT).

	* "property flags" that define how a proper
	  should be structured (PROP_CONST and PROP_STRING).

	* and creation flags (PROP_NOWAIT).



	> 	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.

This may be true for PCI, but it is not true for SBus.

Each port, sun3*, sparc, and sparc64, has its own SBus bus 
driver, but share a common set of SBus devices.  If we do
this the way you suggest things will break.

Eduardo