eeh@netbsd.org writes:
> 	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.
> 
> Since the "property flags" are only used during creation,
> and PROP_NOWAIT is only used during creation, you would have
> to specify two sets of flags at once.

yup.


> 	> 	> 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?
> [ ... ]
> 	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-)
> 
> That's just avoiding the issue.

It's hardly avoiding the issue.

At issue is the statement you made above.

There are four goals at hand here:

(1) backward compatibility of drivers while converting to the new
interface.  I think that this is obvious; drivers won't need to be
converted all at once (but they will have to wait to have their busses
converted).

(2) seamless transition, i.e. busses and/or can be converted without
massive breakage, and without massive rototilling of the source tree.
This follows as well.  The only possibility is for the Sbus case
you've described, and it can be handled as well: Convert one MD bus
driver.  Later, convert the next.  Later, convert the next.  _Then_
start converting drivers.  If you're in a rush to convert drivers,
well, then it's on you to convert the busses in a way that works.  But
you can get a seamless transition.

(3) desire for the 'new interface' used by converted drivers to get
rid of aux entirely.  My way of doing conversion manages this, yours
does not.

(4) desire that when the interface is completely converted, more
rototilling of source code isn't necessary for the conversion to be
finished.  It may be possible to do this with your method, but it's
much harder to _verify_ than with mine.


So, regarding the statement you made above:

(1) The claim you make is false; the opposite is true, bus drivers
tend to be MI and device drivers tend to be MI and MD.  Sbus is an
exception.

(2) Despite that, with my suggested method for conversion, you can
meet all of the goals outlined above.  You just have to convert all of
the MD busses before you can start converting MI drivers.  That's not
a big deal.

(3) Given the points above, and the fact that my proposal for
conversion actually _satisfies_ all of things that I can think of as
reasonable goals for the conversion, yes, in fact, I do think my
method would be quite acceptable.



cgd