Re: [PATCH 0/4] baby step toward multi-target

[Doug Evans <xdje42@gmail.com>]

Tom Tromey <tromey@redhat.com> writes:
> My multi-target branch is basically dead, I think, mostly due to heavy
> conflicts with all the other target changes that have happened in the
> meantime.

This is an important bit of functionality that needs to be done.
Since we just released 7.8, and in order to prevent such things
happening again, I think it would be reasonable to put more
resources into getting this done, and delay other things for awhile.
[Assuming various factors like it won't take an inordinate amount
of time, and the end result is the more preferred one, and probably
a few others :-).]

$0.02

> However recently I realized that there is a less invasive
> way to achieve many of the same effects, and a way to salvage some of
> the smaller cleanups done there.
>
> In particular on the branch I attempted to split target_ops into a
> vtable-like object and a target state object.  As you might imagine
> this patch touches a large amount of code and is hard both to keep up
> to date, and to test.

That was my understanding of where we were headed.

> This little series, on the other hand, takes a less invasive approach.
> The idea here is that rather than doing a huge target_ops split,
> instead just sometimes make copies of the target_ops when pushing.
> This lets the copies keep their own state; copies are needed in the
> long run because multiple target stacks will be active and a given
> target_ops only has one "beneath" pointer.

Which version of the long run?
Wouldn't dynamic properties of the object be kept in the object
and not the vtable?

Or is some custom dynamic interitance being done here?
I can imagine that being useful to facilitate inserting
debug targets into the mix.

By way of analogy, I'd be curious how this would be done in c++.

[Just trying to understand the situation better.]

> Here corelow is used as the example of how to do a conversion.
> There's a bit of cleanup and infrastructure initially, and then the
> final patch moves the corelow global state into a new subclass of
> target_ops, which is instantiated and pushed.
>
> If this approach seems reasonable then it's not too hard to pull over
> some of the other target conversions from the branch.
>
> This series also shows the spots to change if you want to make the
> debug target wrap each stratum in the target stack -- each wrapping
> debug target would be to_xclose-ish, and spots like target_is_pushed
> would be taught to unwrap.
>
> Built and regtested on x86-64 Fedora 20.