From: Petr Mladek <pmladek@suse.com>
To: Jim Cromie <jim.cromie@gmail.com>
Cc: jbaron@akamai.com, linux-kernel@vger.kernel.org,
akpm@linuxfoundation.org, gregkh@linuxfoundation.org,
linux@rasmusvillemoes.dk, Jonathan Corbet <corbet@lwn.net>,
Andrew Morton <akpm@linux-foundation.org>,
Will Deacon <will@kernel.org>, Orson Zhai <orson.zhai@unisoc.com>,
linux-doc@vger.kernel.org
Subject: Re: [PATCH v2 17/24] dyndbg: add user-flag, negating-flags, and filtering on flags
Date: Tue, 16 Jun 2020 13:41:56 +0200 [thread overview]
Message-ID: <20200616114156.GL31238@alley> (raw)
In-Reply-To: <20200613155738.2249399-18-jim.cromie@gmail.com>
On Sat 2020-06-13 09:57:31, Jim Cromie wrote:
> 1. Add a user-flag [u] which works like the [pfmlt] flags, but has no
> effect on callsite behavior; it allows incremental marking of
> arbitrary sets of callsites.
>
> 2. Add [PFMLTU] flags, which negate their counterparts; P===!p etc.
> And in ddebug_read_flags():
> current code does: [pfmltu_] -> flags
> copy it to: [PFMLTU_] -> mask
>
> also disallow both of a pair: ie no 'pP', no true & false.
>
> 3. Add filtering ops into ddebug_change(), right after all the
> callsite-property selections are complete. These filter on the
> callsite's current flagstate before applying modflags.
>
> Why ?
>
> The 'u' flag lets the user assemble an arbitary set of callsites.
> Then using filter flags, user can activate the 'u' set.
>
> #> echo 'file foo.c +u; file bar.c +u' > control # and repeat
> #> echo 'u+p' > control
What was the motivation for this please?
Is it common to manipulate the same set of callsites again and again?
Do you have any usecase, please?
Best Regards,
Petr
next prev parent reply other threads:[~2020-06-16 11:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200613155738.2249399-1-jim.cromie@gmail.com>
2020-06-13 15:57 ` [PATCH v2 01/24] dyndbg-docs: eschew file /full/path query in docs Jim Cromie
2020-06-14 6:04 ` Greg KH
2020-06-14 14:24 ` jim.cromie
2020-06-13 15:57 ` [PATCH v2 02/24] dyndbg-docs: initialization is done early, not arch Jim Cromie
2020-06-13 15:57 ` [PATCH v2 11/24] dyndbg: accept 'file foo.c:func1' and 'file foo.c:10-100' Jim Cromie
2020-06-15 14:46 ` Petr Mladek
2020-06-13 15:57 ` [PATCH v2 15/24] dyndbg: extend ddebug_parse_flags to accept optional leading filter-flags Jim Cromie
2020-06-15 15:37 ` Petr Mladek
2020-06-13 15:57 ` [PATCH v2 17/24] dyndbg: add user-flag, negating-flags, and filtering on flags Jim Cromie
2020-06-16 11:41 ` Petr Mladek [this message]
2020-06-13 15:57 ` [PATCH v2 18/24] dyndbg: allow negating flag-chars in modflags Jim Cromie
2020-06-16 11:47 ` Petr Mladek
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=20200616114156.GL31238@alley \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=akpm@linuxfoundation.org \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=jbaron@akamai.com \
--cc=jim.cromie@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=orson.zhai@unisoc.com \
--cc=will@kernel.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