Subject: Re: More Device Properties
To: None <eeh@netbsd.org>
From: Chris G. Demetriou <cgd@sibyte.com>
List: tech-kern
Date: 02/22/2001 12:53:10
eeh@netbsd.org writes:
> 	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.
> [ ... ]
> No, your proposal calls for a transitional interface
> for bus drivers, which means that they will require
> conversion twice: once to the transitional interface
> that provides both `aux' and properties and then another
> conversion to remove `aux' and migrate to the final
> interface.

Ooops, yes, that's a slight defect in the ability of my proposal to
satisfy (4).  I don't think it's that bad, because (number of busses
<<< number of drivers), so the amount of change afterward is much less.
I.e. the number of things you have to modify is small, and all you'll
be doing is pretty much deleting now-unnecessary lines of code.

In fact, if you conditionalized them on an #ifdef, you could even
#unifdef them.  It's probably desirable to "require" use of an #ifdef
for updated busses, so that (1) indeed we can unifdef the
unneeded-bits later, and (2) ports which don't need the old-style any
longer can switch to the new style in the way that other interfaces
have been converted in the past.

Also note that when thinking about third-party drivers (for non-bus
drivers) it's exactly one transition in API.  (ABI you still get two,
but recompiling is trivial compared with anything that involves
editing a .c or .h file.  8-)


> My proposal only required a single transition, although
> it did leave some unused remnants of the original interface
> visible.

Right, and the pain to remove those remnants involves cutting a swath
across the source tree and e.g. third party drivers.


> I do not beleive this can be done as a one-step process
> that does not leave some remnants of `aux' around without
> causing major disruptions.  However, the level of acceptable
> breakage during this transition is a policy rather than
> an engineering issue.

I strongly believe that when we're doing with this, 'aux' should be
dead.

When we as a project transition to a new interface (after having had a
period of time when the old interface was supported for
compatibility), the old interface should end up being removed
entirely.

Where we can avoid it, we don't want our source tree to be like a
whale showing off hints about what it was before it evolved into what
it is now.  When we adopt something, it should be for a reason, and a
good one, and we should do what we can to convert completely.

The easier that conversion, the better.


chris