From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v2 1/4] lib: add new cgroup test API
Date: Wed, 3 Jun 2020 12:43:15 +0200 [thread overview]
Message-ID: <20200603104314.GA12583@janakin.usersys.redhat.com> (raw)
In-Reply-To: <CAEemH2d7OzG6jBZ15bYGRHm7ry-gVjzuwJYhbHp3yitB3_928w@mail.gmail.com>
>> >And the worth to say, the random directory name for same cgroup
>> >mounting is also on purpose, though we mount same(i.e memory)
>> >cgroup in two places it still belongs to the one hierarchy, and create
>> >the same name of the new directory will be hit an error in EEXIST.
>> >
>> >static void tst_cgroup_set_path(const char *cgroup_dir)
>> >{
>> > ...
>> > sprintf(tst_cgroup_mnt_path, "%s", cgroup_dir);
>> > sprintf(tst_cgroup_new_path, "%s/ltp_%d", cgroup_dir, rand());
>>
>> I see why you are tracking this in list, but this exchange of state through
>> global variables does seem bit unclear.
>>
>
>Yes, that's a compromise to support more usage of the APIs.
I don't get why global variables are necessary.
tst_cgroup_mnt_path is always same as cgroup_dir parameter passed to all functions.
tst_cgroup_get_path() could return pointer to tst_cgroup_pathes->new_path,
(you just need you call umount before del_path)
tst_cgroup_ctl_knob is set before each use, so it could be local variable too.
>I have no strong preference to shift from v2 to this method, or maybe we
>can try
>to combine together and do more optimize work in the lib side.
Sounds like we could use 3rd opinion.
next prev parent reply other threads:[~2020-06-03 10:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-01 10:04 [LTP] [PATCH v2 1/4] lib: add new cgroup test API Li Wang
2020-06-01 10:04 ` [LTP] [PATCH v2 2/4] mem: take use of new cgroup API Li Wang
2020-06-01 10:04 ` [LTP] [PATCH v2 3/4] mem: remove the old " Li Wang
2020-06-01 10:04 ` [LTP] [PATCH v2 4/4] mm: add cpuset01 to runtest file Li Wang
2020-06-01 10:58 ` [LTP] [PATCH v2 1/4] lib: add new cgroup test API Li Wang
2020-06-01 13:57 ` Jan Stancek
2020-06-02 4:42 ` Li Wang
2020-06-02 12:12 ` Jan Stancek
2020-06-03 1:38 ` Li Wang
2020-06-03 10:43 ` Jan Stancek [this message]
2020-06-03 12:51 ` Li Wang
2020-06-05 10:14 ` Jan Stancek
2020-06-08 8:53 ` Li Wang
2020-06-08 9:48 ` Jan Stancek
2020-06-08 10:18 ` Li Wang
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=20200603104314.GA12583@janakin.usersys.redhat.com \
--to=jstancek@redhat.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.