From: Cyril Hrubis <chrubis@suse.cz>
To: Petr Vorel <pvorel@suse.cz>
Cc: Martin Doucha <martin.doucha@suse.com>,
ltp@lists.linux.it, Sebastian Chlad <sebastian.chlad@suse.com>
Subject: Re: [LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode
Date: Tue, 24 Feb 2026 11:44:43 +0100 [thread overview]
Message-ID: <aZ2BGwrdHKeaxXkD@yuki.lan> (raw)
In-Reply-To: <20260224093820.GA37927@pevik>
Hi!
> > And with that we would need some kind of "master file" that would
> > explain which script should be executed on which host etc. But I guess
> > that it would be tricky to desing this properly.
>
> I'm not sure if separated file is worth of adding. There is tst_rhost_run()
> function which should be used for checking, which works well on both netns and 2
> host based setup (that's why v2).
This is just me thinking if we can actually desing something more proper
in the future now that runltp is gone. I think that the whole
tst_rhost_run() infrastructure is a bit of a hack and that the
multimachine test can be desingned differently. I would say that more
proper solution would be to have the test split into one script per
worker and having some master script/description to drive the testing.
The testrunner would read the information about which script to run on
which worker and would also have to handle synchronization.
In the case of the NFS tests the master script would say to run a script
that sets up NFS server and signal the testrunner once it's done and
wait. The script that would be doing the actuall test would be executed
once the the NFS server script to signaled it's completion and then
start the actual test. Once it's finished testing it would exit, which
would tell the testrunner to wake up the NFS server script in order to
cleanup. If we decided to write multimachine tests this way we would
need to add a way how to pass parameters such as IP addresses from kirk
to tests and also add a way how to propagate events between tests via
kirk so that we can have some kind of locking.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-02-24 10:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-21 13:53 [LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode Sebastian Chlad
2026-02-22 20:34 ` Petr Vorel
2026-02-23 10:41 ` Sebastian Chlad
2026-02-23 10:55 ` [LTP] [PATCH v2] " Sebastian Chlad
2026-02-24 9:24 ` Petr Vorel
2026-02-23 12:01 ` [LTP] [PATCH] " Petr Vorel
2026-02-23 16:54 ` Cyril Hrubis
2026-02-23 17:01 ` Sebastian Chlad via ltp
2026-02-24 9:38 ` Petr Vorel
2026-02-24 10:44 ` Cyril Hrubis [this message]
2026-02-24 11:46 ` Petr Vorel
2026-02-24 12:20 ` Cyril Hrubis
2026-02-24 16:11 ` Petr Vorel
2026-02-25 9:24 ` Sebastian Chlad
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=aZ2BGwrdHKeaxXkD@yuki.lan \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
--cc=martin.doucha@suse.com \
--cc=pvorel@suse.cz \
--cc=sebastian.chlad@suse.com \
/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