eeh@netbsd.org writes:
> 	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).

Right, so, i'd split those into 2 sets:

	* operation flags (PROP_INHERIT, PROP_NOWAIT), and

	* property flags (PROP_CONST, PROP_STRING).

or, you could alternately do 3 -- it wouldn't matter in terms of the
number of args that a fn would need, compared to doing 2 sets, since
you'd never need to specify both "lookup" and "creation" flags at
once.

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

Then in that case, yes, you need to convert each of the bus
implementations before you can convert any of the devices.

The scope here is limited, it's not that much work to convert all of
the busses up front.  I don't consider it a problem, especially not of
the scop of "more bus drivers tend to be MD than device drivers."
It's the opposite of that, and sbus is a small special case that'll
have to be handled.

To be honest, I think the short reply to this issue is, "well, then
the people who did sbus should have structured the MD/MI bus split
better, like most other busses did."  8-)


chris