From: Tom Zanussi <zanussi@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Daniel Wagner <wagi@monom.org>
Subject: Re: [FEATURE REQUEST] tracing: Have event filters handle dynamic arrays
Date: Wed, 25 Nov 2020 09:16:52 -0600 [thread overview]
Message-ID: <a85c494dafad10ad03da0c8db41cb320491d71d5.camel@kernel.org> (raw)
In-Reply-To: <20201124113734.34d86db1@gandalf.local.home>
Hi Steve, Daniel,
On Tue, 2020-11-24 at 11:37 -0500, Steven Rostedt wrote:
> Hi Tom,
>
> Daniel asked about filtering bitmasks, something like:
>
> cpumask != 0xff
>
> Looking into the code, I realized that bitmasks are dynamic arrays,
> and
> there's no logic in the filter code to handle dynamic arrays of
> anything
> other than 'char' type (which are dynamic strings).
>
> If you have any cycles to spare, do you think you can add code to
> process
> dynamic arrays other than char?
>
> The compare logic may be complex though. I think the above example
> should
> work, but we would need to define how that happens.
>
> I guess we should follow the cpumask logic, and break all non string
> dynamic arrays up into 32 bit words. Even if something is defined as
> u8, it
> will be converted to the local endian of the machine. Basically, we
> should
> follow the function bitmap_string() defined in lib/vsnprintf.c
>
> If we have a u8 dynamic array of:
>
> 0x12 0x34 0x56 0x78 0x9a 0xbc 0xde 0xf0
>
> On a little endian machine it would match:
>
> 0xf0debca9,0x78563412
>
> This way, if we have a machine with 64 CPUS, and we want to match
> cpus 0-7,
> then we only need to do:
>
> cpumask & 0xff
>
> The above would be equivalent to:
>
> cpumask & 0,0xff
>
> in such a case.
>
> That's because, if I'm reading the code correctly, a cpumask for CPUs
> 0-7
> bits set for 64 CPU machine in raw format would be:
>
> 0x00 0x00 0x00 0xff 0x00 0x00 0x00 0x00
>
> The dynamic arrays will allow comma separated 4 byte words to match.
>
> Daniel brought this up, and he said he'd be willing to help out
> making a
> patch if he has spare cycles to spare. Perhaps, between the two of
> you, you
> could come up with the cycles to produce such a patch :-)
>
Sure, I can take a look - luckily holidays are coming up so should be
able to find some time for this.
Tom
> Cheers,
>
> -- Steve
prev parent reply other threads:[~2020-11-25 15:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-24 16:37 [FEATURE REQUEST] tracing: Have event filters handle dynamic arrays Steven Rostedt
2020-11-25 15:16 ` Tom Zanussi [this message]
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=a85c494dafad10ad03da0c8db41cb320491d71d5.camel@kernel.org \
--to=zanussi@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=wagi@monom.org \
/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