Re: [PATCH v3 04/20] kernel-shark: Introduce Data streams

["Yordan Karadzhov (VMware)" <y.karadz@gmail.com>]

On 13.11.20 г. 16:49 ч., Steven Rostedt wrote:
> On Fri, 13 Nov 2020 15:47:04 +0200
> "Yordan Karadzhov (VMware)" <y.karadz@gmail.com> wrote:
> 
>>> I wonder if this should be a string value that gets registered? Otherwise
>>> we will have to be the registry of every new stream format added.
>>>
>>> This is the approach that Tzvetomir took for protocol ids, because that way
>>> we don't need to keep track of them:
>>>
>>>    https://lore.kernel.org/r/20201029111816.247241-2-tz.stoyanov@gmail.com
>>>    
>>
>> I wonder how we can avoid name collisions, especially in the case when
>> some of the data readout plugins will be proprietary.
>> Also I don't think we can expect more than a dozen of distinct data
>> formats to be supported.
> 
> A plugin would need to register a name on load. If two plugins were to
> collide, the register would fail letting the plugin know why. Then the
> plugin could retry with a different name "SCHED_TRACE2". Kind of like when
> you try to add a user name in a website, and that name already exists.
> Perhaps we shouldn't even bother with a hard coded name or ID. Perhaps
> simply ask for an id, and save it into some global variable for that code,
> and have all the checks test to make sure it matches the id that it
> received.
> 
> In any case, seeing the VMware SchedTrace there makes that stick out as a
> big RED flag to me. I don't see why kernelshark needs to have anywhere in
> its code IDs for proprietary systems. That would be NAK'd in any other open
> source project.
> 

OK, this make sense. Checking the data type will become slower, so I 
just have to be very careful and remove the type checks that are not 
absolutely necessary (mostly in patch 8/20).

Thanks a lot!
Y.


> -- Steve
>