oontvoo wrote: > > The (baroque) way that the other plugins work serves two purposes: > > > > 1. controlling the type (class) of the plugin being created based on some > > runtime property > > 2. creating an arbitrary number of plugin instances > > > > For telemetry "plugins", I don't think we want/need (1) because the type of > > the plugin is determined by the vendor -- at build time. A user can't > > change that at runtime. They may be able to disable collection, but they > > can't say "well, today I feel like reporting my telemetry to company `<X>`" > > and change a setting or something to make that happen. I mean, it's > > probably doable, but I don't think anyone has that as a requirement (if you > > do, let us know). > > I don't think anyone has that requirement but I could see a few situations > where that could be useful. For example we could have a "textual telemetry" > fallback plugin that we use for testing and users could turn on the audit > what's being reported.
This sounds like it could be done via configuration on the `Destination` (ie., where the collected data ended up), rather than the TelemetryManager (plugin) itself. > We don't need to inherit from `PluginInterface` as it really doesn't give you > anything. >From my understanding, the benefit of inheriting from the interface is you >can re-use the existing cmake and C++ macros magic for defining vendor impl - >that is, you just put `LLDB_PLUGIN_DEFINE(MyPlugin)` in the vendor code, along >with the cmake declaration and you're done! The framework takes care of >ensuring the `::Initialize()` is called to set the instance. > How does that sound to you @oontvoo & @labath? SG, either way - the simpler the better :) https://github.com/llvm/llvm-project/pull/126588 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
