From: Petr Vorel <pvorel@suse.cz>
To: Andrea Cervesato <andrea.cervesato@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v3] doc: update syscalls statistics
Date: Fri, 26 Apr 2024 20:17:13 +0200 [thread overview]
Message-ID: <20240426181713.GB6871@pevik> (raw)
In-Reply-To: <6b2dd151-c7cf-48b5-87f5-3c3efb425811@suse.com>
> Hi!
> On 4/25/24 23:37, Petr Vorel wrote:
> > Hi Andrea,
> > > This patch black-list a few syscalls which are not implemented in the
> > > kernel, untestable or either really old (=< 2.6 kernel version), as well
> > > as defining already tested syscalls.
> > > Also fixed an index issue with table generation.
> > Thanks a lot, obvious fix, therefore merged.
> > I would still consider:
> > 1) Listing also mq_getsetattr().
> From manual:
> DESCRIPTION
> Do not use this system call.
> This is the low-level system call used to implement mq_getattr(3)
> and mq_setattr(3). For an explanation of how this system call operates, see
> the description
> of mq_setattr(3).
And it continue " Never call it unless you are writing a C library!"
IMHO this is mean to the normal users, because very few people wrote libc.
But we test kernel interface, which include this.
> > 2) Trying to links syscalls names to the syscalls directory
> > (e.g. read => read directory in LTP tree[1]) that should not be that hard.
> It's already like this: we check for syscalls subfolders and compare them
> with syscalls file. If subfolder exists, we suppose to have tests for the
> specific syscall (of course, this doesn't include coverage).
I wrote before, just bool test x not test is IMHO not much helpful. But maybe
others see it differently. That's why I would like at least to add a link so
that reader itself has it easy verify it itself. Ideally all tests would be
listed. I understand if you don't have time to implement it, but IMHO it would
be helpful.
> > 3) Write explanation, that these syscalls are to "some extend tested".
> > Ideally, I would wish we would transform metadata output generation [2]
> > to the docs here and enable also LTP latest stable version docs.
> Possible, but it might be a bit challenging
Yes, but it does not make much sense to keep 2 formats. Again, one question
is whether we agree on it and the other is whether anybody finds time to
implement it.
Kind regards,
Petr
> > Kind regards,
> > Petr
> > [1] https://github.com/linux-test-project/ltp/tree/master/testcases/kernel/syscalls/read
> > [2] https://github.com/linux-test-project/ltp/releases/download/20230516/metadata.20230516.html
> Andrea
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2024-04-26 18:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-23 8:21 [LTP] [PATCH v3] doc: update syscalls statistics Andrea Cervesato
2024-04-25 21:37 ` Petr Vorel
2024-04-26 10:29 ` Andrea Cervesato via ltp
2024-04-26 10:32 ` Andrea Cervesato via ltp
2024-04-26 18:22 ` Petr Vorel
2024-04-26 18:17 ` Petr Vorel [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=20240426181713.GB6871@pevik \
--to=pvorel@suse.cz \
--cc=andrea.cervesato@suse.com \
--cc=ltp@lists.linux.it \
/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.