<div dir="ltr"><div>Hi Richard and Li,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 6, 2021 at 1:24 AM Richard Palethorpe <<a href="mailto:rpalethorpe@suse.de" target="_blank">rpalethorpe@suse.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I suppose we also need to remember if the current test created the ltp<br>
subdirectory or mounted any controllers.<br>  <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We could do this by just printing the required command line options to<br>
stdout when the utility exits. Then save this to a variable for the next<br>
use.<br>
<br></blockquote><div><br></div><div> </div><div>Yes, we would have to remember what we mounted. I think the part I am most curious about is how we would generate that state i.e what we mounted, because the Cgroup library does not expose any of this as far as I'm aware.<br></div><div><br></div><div> If we want to use the 
tst_cgroup C lib to cleanup as well we would have to find a way to 
reintroduce test state to the lib that we are losing between calls of 
the utility, which the only way I could think of is 
introducing a way to export and import test state within the lib. e.g. 
tst_cgroup_print_test_state() tst_cgroup_load_test_state(), which 
doesn't feel good as it exposes some of the nice API you have going on. This is the easiest way to tell if we are mounting things because we can just print what we mounted, what the test dir of the test is, and reload that state. This could have further applications to not just this scenario but also to scenarios where if a test dies its state can be reloaded, etc, almost in a checkpoint way. Not saying its common but adds some flexibility to the API and I could see it having applications outside of this utility. <br></div><div><br></div><div>Alternatively we could inspect what we created and generate state that way, i.e. make a call to tst_cgroup_require() and see if new things were mounted. Then we would have to manually be freeing things. I don't like this approach because it goes against the whole point of this which was code reuse. But the cleanup of things isnt the most difficult part so it wouldn't be the biggest deal to redo the logic.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Yes, sounds good.<br>
<br></blockquote><div> </div><div>Let me know what you think. I wouldn't want to add anything huge to the API without your blessing :) <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
Thank you,<br>
Richard.<br></blockquote><div><br></div><div>Thanks, <br></div><div>- Luke<br></div></div></div>