linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: "Yordan Karadzhov (VMware)" <y.karadz@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Subject: Re: [PATCH v3 04/20] kernel-shark: Introduce Data streams
Date: Thu, 12 Nov 2020 15:50:51 -0500	[thread overview]
Message-ID: <20201112155051.18e226e9@gandalf.local.home> (raw)
In-Reply-To: <20201112142358.36821-5-y.karadz@gmail.com>

On Thu, 12 Nov 2020 16:23:42 +0200
"Yordan Karadzhov (VMware)" <y.karadz@gmail.com> wrote:

> With the help of Data stream, KernelShark will be able to load and
> merge multiple trace files (streams). Each stream can have different
> plugins or filters, registered for it, which means that the raw trace
> data of the streams can have different formats, and will allow for a
> great degree of customization of the provided data visualization. In
> this patch we only provide the basic definitions. The actual integration
> of the Data streams into the C API of KernelShark will happen in the
> following patches.
> 
> Signed-off-by: Yordan Karadzhov (VMware) <y.karadz@gmail.com>
> ---
>  src/libkshark.h | 216 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 216 insertions(+)
> 
> diff --git a/src/libkshark.h b/src/libkshark.h
> index cc20077f..c8fdd266 100644
> --- a/src/libkshark.h
> +++ b/src/libkshark.h
> @@ -121,6 +121,222 @@ void kshark_hash_id_free(struct kshark_hash_id *hash);
>  
>  int *kshark_hash_ids(struct kshark_hash_id *hash);
>  
> +struct kshark_data_stream;
> +
> +/** A function type to be used to initialize the interface of the data stream. */
> +typedef int (*interface_init_func) (struct kshark_data_stream *,
> +				    const char *);
> +
> +/** A function type to be used to initialize the interface of the data stream. */
> +typedef int (*interface_close_func) (struct kshark_data_stream *,
> +				     const char *);

These two typedefs should probably be introduced when a patch that uses them
is added. Otherwise they are basically meaningless for the reviewer.

Also, it the above looks like a cut-and-paste error as the close has the
same description as the init.

I don't even see the above used in later patches :-/


> +
> +/** A function type to be used by the method interface of the data stream. */
> +typedef char *(*stream_get_str_func) (struct kshark_data_stream *,
> +				      const struct kshark_entry *);
> +
> +/** A function type to be used by the method interface of the data stream. */
> +typedef const int (*stream_get_int_func) (struct kshark_data_stream *,
> +					  const struct kshark_entry *);
> +
> +/** A function type to be used by the method interface of the data stream. */
> +typedef int (*stream_find_id_func) (struct kshark_data_stream *,
> +				    const char *);
> +
> +/** A function type to be used by the method interface of the data stream. */
> +typedef int *(*stream_get_ids_func) (struct kshark_data_stream *);
> +
> +/** A function type to be used by the method interface of the data stream. */
> +typedef int (*stream_get_names_func) (struct kshark_data_stream *,
> +				      const struct kshark_entry *,
> +				      char ***);
> +
> +/** Event field format identifier. */
> +typedef enum kshark_event_field_format {
> +	/** A field of unknown type. */
> +	KS_INVALIDE_FIELD,

	KS_INVALID_FIELD ?

> +
> +	/** Integer number */
> +	KS_INTEGER_FIELD,
> +
> +	/** Floating-point number */
> +	KS_FLOAT_FIELD
> +} kshark_event_field_format;
> +
> +/** A function type to be used by the method interface of the data stream. */
> +typedef kshark_event_field_format
> +(*stream_event_field_type) (struct kshark_data_stream *,
> +			    const struct kshark_entry *,
> +			    const char *);
> +
> +/** A function type to be used by the method interface of the data stream. */
> +typedef const int (*stream_read_event_field) (struct kshark_data_stream *,
> +					      const struct kshark_entry *,
> +					      const char *,
> +					      int64_t *);
> +
> +/** A function type to be used by the method interface of the data stream. */
> +typedef const int (*stream_read_record_field) (struct kshark_data_stream *,
> +					       void *,
> +					       const char *,
> +					       int64_t *);
> +
> +struct kshark_context;
> +
> +/** A function type to be used by the method interface of the data stream. */
> +typedef ssize_t (*load_entries_func) (struct kshark_data_stream *,
> +				      struct kshark_context *,
> +				      struct kshark_entry ***);
> +
> +/** A function type to be used by the method interface of the data stream. */
> +typedef ssize_t (*load_matrix_func) (struct kshark_data_stream *,
> +				     struct kshark_context *,
> +				     int16_t **event_array,
> +				     int16_t **cpu_array,
> +				     int32_t **pid_array,
> +				     int64_t **offset_array,
> +				     int64_t **ts_array);
> +
> +/** Data format identifier. */
> +typedef enum kshark_data_format {
> +	/** A data of unknown type. */
> +	KS_INVALIDE_DATA,

	KS_INVALID_DATA ?

> +
> +	/** Ftrace data. */
> +	KS_TEP_DATA,
> +
> +	/** VMware SchedTrace data. */
> +	KS_VMW_ST_DATA,
> +} kshark_data_format;

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

-- Steve

> +
> +/** Data interface identifier. */
> +typedef enum kshark_data_interface_id {
> +	/** An interface with unknown type. */
> +	KS_INVALIDE_INTERFACE,
> +
> +	/** Generic interface suitable for Ftrace data. */
> +	KS_GENERIC_DATA_INTERFACE,
> +} kshark_data_interface_id;
> +

  reply	other threads:[~2020-11-12 20:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-12 14:23 [PATCH v3 00/20] Start KernelShark v2 transformation Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 01/20] kernel-shark: Use only signed types in kshark_entry Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 02/20] kernel-shark: Add stream_id to kshark_entry Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 03/20] kernel-shark: Introduce libkshark-hash Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 04/20] kernel-shark: Introduce Data streams Yordan Karadzhov (VMware)
2020-11-12 20:50   ` Steven Rostedt [this message]
2020-11-13 13:47     ` Yordan Karadzhov (VMware)
2020-11-13 14:42       ` Steven Rostedt
2020-11-13 14:49       ` Steven Rostedt
2020-11-13 15:08         ` Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 05/20] kernel-shark: Rename static methods in libkshark Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 06/20] kernel-shark: Add basic methods for Data streams Yordan Karadzhov (VMware)
2020-11-12 21:17   ` Steven Rostedt
2020-11-13 13:55     ` Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 07/20] kernel-shark: Housekeeping before implementing stream interface Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 08/20] kernel-shark: Add stream interface for trace-cmd data Yordan Karadzhov (VMware)
2020-11-12 22:10   ` Steven Rostedt
2020-11-13 13:58     ` Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 09/20] kernel-shark: Start introducing KernelShark 2.0 Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 10/20] kernel-shark: Start using data streams Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 11/20] kernel-shark: Remove dead code Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 12/20] kernel-shark: Redesign the plugin interface Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 13/20] kernel-shark: Complete the stream integration Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 14/20] kernel-shark: Provide merging of multiple data streams Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 15/20] kernel-shark: Integrate the stream definitions with data model Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 16/20] kernel-shark: Use only signed types for model defs Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 17/20] kernel-shark: Add ksmodel_get_bin() Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 18/20] kernel-shark: Protect ksmodel_set_in_range_bining() Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 19/20] kernel-shark: Add methods for time calibration Yordan Karadzhov (VMware)
2020-11-12 14:23 ` [PATCH v3 20/20] kernel-shark: Integrate streams with libkshark-configio Yordan Karadzhov (VMware)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201112155051.18e226e9@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=y.karadz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).