I had initially looked into this for the 3PAR drivers when we initially
were working on the target driver code. The problem I found was, it would
take a fair amount of time to refactor the code, with marginal benefit.
Yes, the design is better, but I couldn't justify the refactoring time,
effort
On Fri, Jun 2, 2017 at 3:51 PM, Jay Bryant
wrote:
> I had forgotten that we added this and am guessing that other cores did as
> well. As a result, it likely, was not enforced in driver reviews.
>
> I need to better understand the benefit. In don't think there is a
On Fri, Jun 2, 2017 at 3:11 PM, Eric Harney wrote:
> On 06/02/2017 03:47 PM, John Griffith wrote:
> > Hey Everyone,
> >
> > So quite a while back we introduced a new model for dealing with target
> > management in the drivers (ie initialize_connection, ensure_export etc).
> >
I had forgotten that we added this and am guessing that other cores did as
well. As a result, it likely, was not enforced in driver reviews.
I need to better understand the benefit. In don't think there is a hurry to
remove this right now. Can we put it on the agenda for Denver?
Jay
On Fri, Jun
On 06/02/2017 03:47 PM, John Griffith wrote:
> Hey Everyone,
>
> So quite a while back we introduced a new model for dealing with target
> management in the drivers (ie initialize_connection, ensure_export etc).
>
> Just to summarize a bit: The original model was that all of the target
>
On Fri, Jun 2, 2017 at 12:47 PM, John Griffith
wrote:
> Hey Everyone,
>
> So quite a while back we introduced a new model for dealing with target
> management in the drivers (ie initialize_connection, ensure_export etc).
>
> Just to summarize a bit: The original model
On Fri, Jun 2, 2017 at 12:47 PM, John Griffith
wrote:
>
>
> What I'm wondering is, even though I certainly think this is a FAR
> SUPERIOR design to what we had, I don't like having both code-paths and
> designs in the code base.
>
Might be useful to enumerate those?
I personally agree that the target classes route is a much cleaner and more
efficient way of doing it. Also, that it doesn't make sense to have all
the code duplication to support doing it both ways.
If other people agree with that- maybe we can start with not taking new
drivers that do it the