On 13-07-15 03:19 PM, Francis Giraldeau wrote:
> 2013/7/12 Geneviève Bastien <gbast...@versatic.net>:
>> Each new analysis can then be implemented in its own standalone plugin, with
>> core and ui, which would require only the tmf.core|ui (and the plugins
>> containing other analysis it requires of course). The main plugins would not
>> require any analysis modules.
>>
>> I'd like some feedback on the proposed approach. I know Francis Giraldeau
>> has been thinking on this problem as well, mostly on the dependencies
>> between analysis. I think this approach is complementary.
> The idea is to build more complex analysis based on simpler ones. Here
> is the event processing design I would suggest.
>
> First, we should be able to query an analysis module to get the list
> of events it requires. This way, only required event could be enabled
> for a specific analysis, thus reducing the runtime overhead compared
> to blindly enable all events. This is not possible currently with
> switch cases in handleData(), and listing then by hand would break DRY
> principle. Instead, we could implement handlers with inner anonymous
> classes per-event, something very close to GUI event listeners:
>
> processingManager.addListener("event_foo", new ITmfProcessingUnit() {
> @Override
> public void handleEvent(ITmfEvent event) {
> // process event_foo ...
> }
> }
This may be redundant, but I think the registration of the class as a
signal handler would be the best place to do this.
when you register in TmfSignalManager, let's say you add
* register(this);
* register(this, int priority);
* register(this, TmfSignalManger.PRIORITY_HIGH);
* register(this, TmfSignalManger.PRIORITY_LOW);
* register(this, TmfSignalManager.Before(TmfComponent) );
* register(this, TmfSignalManager.After(TmfComponent) );
This would tell the handler to call the events in the proper order.
The dependencies would also be implicitly solved, unless you have
something like a circular dependency where we will have the limit going
up/down progressively.
This may also be overengineered. We may only deal with 4-5 requests for
all that I know. :)
>
> We also need multi-phases analysis. For instance, for kernel traces,
> we need to read the statedump, then rewind the trace and start again,
> because statedump and the actual tracing is interleaved.
>
> Finally, we need dependencies between analysis modules. I would
> suggest to add annotation with required classes. Here is a quick
> prototype, with few analysis module classes Cx:
>
> public class TmfProcessingDependencyTest {
>
> public static class C1 {}
>
> @TmfProcessingRequires(C1.class)
> public static class C2 {}
>
> @TmfProcessingRequires(C2.class)
> public static class C3 {}
>
> @TmfProcessingRequires(C1.class)
> public static class C4 {}
>
> @Before
> public void setup() {
> TmfProcessingRegistry man = TmfProcessingRegistry.getInstance();
> man.register(C1.class);
> man.register(C2.class);
> man.register(C3.class);
> man.register(C4.class);
> }
>
> @Test
> public void testModuleDependencyGraph() {
> List<Class<?>> deps =
> TmfProcessingRegistry.getInstance().getDependencies(C3.class);
> assertTrue(deps.contains(C1.class));
> assertTrue(deps.contains(C2.class));
> assertTrue(deps.contains(C3.class));
> assertFalse(deps.contains(C4.class));
> assertTrue(isBefore(deps, C1.class, C2.class));
> assertTrue(isBefore(deps, C2.class, C3.class));
> }
>
> private static boolean isBefore(List<Class<?>> deps, Class<?>
> before, Class<?> after) {
> return deps.indexOf(before) < deps.indexOf(after);
> }
>
> Topological sort could be used to compute the dependencies, and then
> classes could be instantiated dynamically. In this example, the module
> C1 would receive the event before C2, and C3 would get it last, then
> the next event would be processed.
>
> The analysis extension point would make a reference to a top-level
> analysis class. I don't know if this is state-of-the-art, or if the is
> already some mechanism to handle this kind of class dependencies, so
> comments are very welcome!
>
> Thanks,
>
> Francis Giraldeau
> _______________________________________________
> linuxtools-dev mailing list
> linuxtools-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
