From: Andrea Cervesato via ltp <ltp@lists.linux.it>
To: "Cyril Hrubis" <chrubis@suse.cz>
Cc: Linux Test Project <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH 1/2] metadata: add tests grouping support
Date: Thu, 18 Jun 2026 13:23:28 +0000 [thread overview]
Message-ID: <6a33f151.34ecd23a.148835.82ec@mx.google.com> (raw)
In-Reply-To: <ajKzKA_ROAlfBDys@rei.lan>
Hi Cyril,
> Hi!
> > 1. Source file path - the two nearest parent directories (immediate
> > parent first), skipping 'kernel' as too generic. For example:
> > - testcases/kernel/syscalls/clone/clone01.c -> clone, syscalls
> > - testcases/kernel/kvm/kvm_pagefault01.c -> kvm
> > - testcases/cve/cve-2017-16939.c -> cve
> >
> > 2. @group tags in the doc comment block, e.g.:
> > /* * Test description.
> > *
> > * @group stress
>
> Maybe call it groups and allow white-space separated list?
>
> I'm not really sure about the syntax, but I guess that @groups foo bar
> will do.
I was thinking that having `@group foo` is cleaner. When we start to have
multiple groups it can be really to handle multiple groups: for instance,
we might end up having one line over 80 chars in the description.
@groups foo1 bar1 foo2 bar2 foo3 bar3 ..
Instead, we might have
@group foo1
@group bar1
@group foo2
@group bar2
@group foo3
@group bar3
These strings are short, but if we have long names it can be weird
to read having all of them on a single line.
>
> > */
> >
> > Add test case for @group tag parsing.
> >
> > Signed-off-by: Andrea Cervesato <andrea.cervesato@suse.com>
> > ---
> > metadata/metaparse.c | 88 ++++++++++++++++++++++++++++++++++++++++++++
> > metadata/tests/groups.c | 11 ++++++
> > metadata/tests/groups.c.json | 13 +++++++
> > 3 files changed, 112 insertions(+)
> >
> > diff --git a/metadata/metaparse.c b/metadata/metaparse.c
> > index 561cbb9d2d54689988c9aa49d591628696bcf847..6bc4b7af60c7449d4b60a1252fa58fed77e03066 100644
> > --- a/metadata/metaparse.c
> > +++ b/metadata/metaparse.c
> > @@ -1168,6 +1168,92 @@ static void print_help(const char *prgname)
> > exit(0);
> > }
> >
> > +/*
> > + * Add groups derived from the source file path.
> > + *
> > + * Groups are the two nearest parent directories (immediate parent
> > + * first), skipping 'kernel' as it's too generic:
> > + *
> > + * testcases/kernel/syscalls/clone/clone01.c -> clone, syscalls
> > + * testcases/kernel/kvm/kvm_pagefault01.c -> kvm
> > + * testcases/cve/cve-2017-16939.c -> cve
> > + */
> > +static void add_path_groups(struct data_node *groups, const char *fname)
> > +{
> > + char buf[256];
> > + int offsets[8];
> > + int ndirs = 0;
> > + int ngroups = 0;
> > + char *p;
> > +
> > + if (strncmp(fname, "testcases/", 10))
> > + return;
> > +
> > + snprintf(buf, sizeof(buf), "%s", fname + 10);
>
> Maybe avoid static buffers here with:
>
> buf = strdup(fname + 10);
>
we can eventually just loop on file name and using offsets, but a
small static buffer makes things clear. I will try to handle it
differently.
> > + p = strtok(buf, "/");
> > + while (p && ndirs < 8) {
> > + offsets[ndirs++] = p - buf;
>
> Why do we store offset rather than the pointer to the string?
>
> dirs[ndirs++] = p;
Leftover of experiments I guess..
>
> > + p = strtok(NULL, "/");
> > + }
> > +
> > + /* Last element is the filename, skip it */
> > + ndirs--;
> > +
> > + for (int j = ndirs - 1; j >= 0 && ngroups < 2; j--) {
> > + if (!strcmp(buf + offsets[j], "kernel"))
> > + continue;
> > +
> > + data_node_array_add(groups, data_node_string(buf + offsets[j]));
> > + ngroups++;
> > + }
>
> We can avoid the complex loop by adding a function to add the group with
> the "kernel" filter and just calling it twice here:
>
> add_group(groups, dirs[ndirs-1]);
> add_group(groups, dirs[ndirs-2]);
This makes sense yes, we are not gonna add any folder after kernel anyway.
>
> > +}
> > +
> > +/*
> > + * Add groups from @group tags in the doc comment block.
> > + */
> > +static void add_doc_groups(struct data_node *groups, struct data_node *doc)
> > +{
> > + if (!doc || doc->type != DATA_ARRAY)
> > + return;
> > +
> > + for (unsigned int i = 0; i < data_node_array_len(doc); i++) {
> > + struct data_node *line = doc->array.array[i];
> > + const char *s;
> > +
> > + if (line->type != DATA_STRING)
> > + continue;
> > +
> > + s = line->string.val;
> > +
> > + while (*s && (*s == ' ' || *s == '\t'))
> > + s++;
> > +
> > + if (strncmp(s, "@group ", 7))
> > + continue;
> > +
> > + s += 7;
> > + while (*s && (*s == ' ' || *s == '\t'))
> > + s++;
> > +
> > + if (*s)
> > + data_node_array_add(groups, data_node_string(s));
> > + }
>
> If we hook up into the multiline_comment() function we can consume the
> line as well so that it does not appear in the parsed doc string. We
> would have to pass the groups node from the main all the way to
> multiline_comment() something as (uncomplete):
Will take a look into it.
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-06-18 13:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-12 13:54 [LTP] [PATCH 0/2] Support metadata groups Andrea Cervesato
2026-06-12 13:54 ` [LTP] [PATCH 1/2] metadata: add tests grouping support Andrea Cervesato
2026-06-12 19:10 ` [LTP] " linuxtestproject.agent
2026-06-17 14:46 ` [LTP] [PATCH 1/2] " Cyril Hrubis
2026-06-18 13:23 ` Andrea Cervesato via ltp [this message]
2026-06-18 13:43 ` Cyril Hrubis
2026-06-18 13:44 ` Andrea Cervesato via ltp
2026-06-12 13:54 ` [LTP] [PATCH 2/2] doc: conf.py: Show groups in test catalog Andrea Cervesato
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=6a33f151.34ecd23a.148835.82ec@mx.google.com \
--to=ltp@lists.linux.it \
--cc=andrea.cervesato@suse.com \
--cc=chrubis@suse.cz \
/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.