From: Zhao Liu <zhao1.liu@intel.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: "Mads Ynddal" <mads@ynddal.dk>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daud�" <philmd@linaro.org>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Alex Benn�e" <alex.bennee@linaro.org>,
"Daniel P . Berrang�" <berrange@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [RFC 2/6] scripts/simpletrace-rust: Support Event & Arguments in trace module
Date: Tue, 28 May 2024 16:32:30 +0800 [thread overview]
Message-ID: <ZlWWnrwkipaq8x7n@intel.com> (raw)
In-Reply-To: <20240527203312.GC913874@fedora.redhat.com>
> > +/*
> > + * Refer to the description of ALLOWED_TYPES in
> > + * scripts/tracetool/__init__.py.
>
> Please don't reference the Python implementation because this will not
> age well. It may bitrot if the Python code changes or if the Python
> implementation is deprecated then the source file will go away
> altogether. Make the Rust implementation self-contained. If there are
> common file format concerns shared by implementations, then move that
> information to a separate document in docs/interop/ (i.e. a simpletrace
> file format specification).
Thanks for your guidance, will do.
> > + */
> > +const ALLOWED_TYPES: [&str; 20] = [
> > + "int",
> > + "long",
> > + "short",
> > + "char",
> > + "bool",
> > + "unsigned",
> > + "signed",
> > + "int8_t",
> > + "uint8_t",
> > + "int16_t",
> > + "uint16_t",
> > + "int32_t",
> > + "uint32_t",
> > + "int64_t",
> > + "uint64_t",
> > + "void",
> > + "size_t",
> > + "ssize_t",
> > + "uintptr_t",
> > + "ptrdiff_t",
> > +];
> > +
> > +const STRING_TYPES: [&str; 4] =
> > + ["const char*", "char*", "const char *", "char *"];
> > +
> > +/* TODO: Support 'vcpu' property. */
>
> The vcpu property was removed in commit d9a6bad542cd ("docs: remove
> references to TCG tracing"). Is this comment outdated or are you
> planning to bring it back?
Thanks! I have no plan for this, I just follow _VALID_PROPS[] in
scripts/tracetool/__init__.py. As you commented above, I think I should
just ignore it. ;-)
> > +const VALID_PROPS: [&str; 1] = ["disable"];
[snip]
> > + pub fn build(arg_str: &str) -> Result<Arguments>
> > + {
> > + let mut args = Arguments::new();
> > + for arg in arg_str.split(',').map(|s| s.trim()) {
> > + if arg.is_empty() {
> > + return Err(Error::EmptyArg);
> > + }
> > +
> > + if arg == "void" {
> > + continue;
> > + }
> > +
> > + let (arg_type, identifier) = if arg.contains('*') {
> > + /* FIXME: Implement rsplit_inclusive(). */
> > + let p = arg.rfind('*').unwrap();
> > + (
> > + /* Safe because arg contains "*" and p exists. */
> > + unsafe { arg.get_unchecked(..p + 1) },
> > + /* Safe because arg contains "*" and p exists. */
> > + unsafe { arg.get_unchecked(p + 1..) },
> > + )
> > + } else {
> > + arg.rsplit_once(' ').unwrap()
> > + };
>
> Can you write this without unsafe? Maybe rsplit_once(' ') followed by a
> check for (_, '*identifier'). If the identifier starts with '*', then
> arg_type += ' *' and identifier = identifier[1:].
Clever idea! It should work, will try this way.
> > +
> > + validate_c_type(arg_type)?;
> > + args.props.push(ArgProperty::new(arg_type, identifier));
> > + }
> > + Ok(args)
> > + }
> > +}
> > +
[snip]
> > + pub fn build(line_str: &str, lineno: u32, filename: &str) -> Result<Event>
> > + {
> > + static RE: Lazy<Regex> = Lazy::new(|| {
> > + Regex::new(
> > + r#"(?x)
> > + ((?P<props>[\w\s]+)\s+)?
> > + (?P<name>\w+)
> > + \((?P<args>[^)]*)\)
> > + \s*
> > + (?:(?:(?P<fmt_trans>".+),)?\s*(?P<fmt>".+))?
>
> What is the purpose of fmt_trans?
>
> > + \s*"#,
> > + )
> > + .unwrap()
>
> I wonder if regular expressions help here. It's not easy to read this
> regex and there is a bunch of logic that takes apart the matches
> afterwards. It might even be clearer to use string methods to split
> fields.
Yes, regular matching is a burden here (it's a "lazy simplification" on
my part), and I'll think if it's possible to avoid regular matching with
string methods.
> Please add a comment showing the format that's being parsed:
>
> // [disable] <name>(<type1> <arg1>[, <type2> <arg2>] ...) "<format-string>"
>
OK.
> > + });
> > +
> > + let caps_res = RE.captures(line_str);
> > + if caps_res.is_none() {
> > + return Err(Error::UnknownEvent(line_str.to_owned()));
> > + }
> > + let caps = caps_res.unwrap();
> > + let name = caps.name("name").map_or("", |m| m.as_str());
> > + let props: Vec<String> = if caps.name("props").is_some() {
> > + caps.name("props")
> > + .unwrap()
> > + .as_str()
> > + .split_whitespace()
> > + .map(|s| s.to_string())
> > + .collect()
> > + } else {
> > + Vec::new()
> > + };
> > + let fmt: String =
> > + caps.name("fmt").map_or("", |m| m.as_str()).to_string();
> > + let fmt_trans: String = caps
> > + .name("fmt_trans")
> > + .map_or("", |m| m.as_str())
> > + .to_string();
> > +
> > + if fmt.contains("%m") || fmt_trans.contains("%m") {
> > + return Err(Error::InvalidFormat(
> > + "Event format '%m' is forbidden, pass the error
> > + as an explicit trace argument"
> > + .to_string(),
> > + ));
> > + }
>
> I'm not sure simpletrace needs to check this. That's a job for tracetool
> the build-time tool that generates code from trace-events files.
Thanks for the clarification, this item has bothered me before, I also
noticed that simpletrace doesn't use it, but don't feel confident about
deleting it completely, I'll clean it up!
> > + if fmt.ends_with(r"\n") {
> > + return Err(Error::InvalidFormat(
> > + "Event format must not end with a newline
> > + character"
> > + .to_string(),
> > + ));
> > + }
Thanks,
Zhao
next prev parent reply other threads:[~2024-05-28 8:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-27 8:14 [RFC 0/6] scripts: Rewrite simpletrace printer in Rust Zhao Liu
2024-05-27 8:14 ` [RFC 1/6] scripts/simpletrace-rust: Add the basic cargo framework Zhao Liu
2024-05-27 20:05 ` Stefan Hajnoczi
2024-05-28 7:53 ` Zhao Liu
2024-05-28 14:14 ` Stefan Hajnoczi
2024-05-29 14:30 ` Zhao Liu
2024-05-29 18:41 ` Stefan Hajnoczi
2024-05-31 12:22 ` Daniel P. Berrangé
2024-05-27 8:14 ` [RFC 2/6] scripts/simpletrace-rust: Support Event & Arguments in trace module Zhao Liu
2024-05-27 20:33 ` Stefan Hajnoczi
2024-05-28 8:32 ` Zhao Liu [this message]
2024-05-27 8:14 ` [RFC 3/6] scripts/simpletrace-rust: Add helpers to parse trace file Zhao Liu
2024-05-27 20:39 ` Stefan Hajnoczi
2024-05-28 8:37 ` Zhao Liu
2024-05-27 8:14 ` [RFC 4/6] scripts/simpletrace-rust: Parse and check trace recode file Zhao Liu
2024-05-27 20:44 ` Stefan Hajnoczi
2024-05-28 9:30 ` Zhao Liu
2024-05-27 8:14 ` [RFC 5/6] scripts/simpletrace-rust: Format simple trace output Zhao Liu
2024-05-27 8:14 ` [RFC 6/6] docs/tracing: Add simpletrace-rust section Zhao Liu
2024-05-27 10:29 ` [RFC 0/6] scripts: Rewrite simpletrace printer in Rust Philippe Mathieu-Daudé
2024-05-27 10:49 ` Mads Ynddal
2024-05-28 6:15 ` Zhao Liu
2024-05-27 19:59 ` Stefan Hajnoczi
2024-05-28 6:48 ` Zhao Liu
2024-05-28 13:05 ` Stefan Hajnoczi
2024-05-29 9:33 ` Mads Ynddal
2024-05-29 14:10 ` Zhao Liu
2024-05-29 18:44 ` Stefan Hajnoczi
2024-05-31 12:27 ` Daniel P. Berrangé
2024-05-31 14:55 ` Alex Bennée
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=ZlWWnrwkipaq8x7n@intel.com \
--to=zhao1.liu@intel.com \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=mads@ynddal.dk \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.