Linux Test Project
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox