<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 18, 2020 at 2:09 PM Zorro Lang <<a href="mailto:zlang@redhat.com">zlang@redhat.com</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">On Fri, Feb 14, 2020 at 05:05:49PM +0530, Viresh Kumar wrote:<br>
> Hello,<br>
> <br>
> This series adds a bunch of LTP tests related to fsmount family of<br>
> syscalls.<br>
<br>
Hi Viresh,<br>
<br>
Thanks for all these cases, that's really helpful.<br>
<br>
Although you write cases for each new mount API, each xxxxx01.c case looks<br>
nearly do same things.<br></blockquote><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">Yes, I have the same feelings. Below are my 2 cents:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Probably because the APIs should be used to bind together, but it is best to reflect the focus of each test case. e.g. fsmount01.c as basic test needs to cover more parameters to verify that all the functionality is really working. fsmount02.c more like a test target for all error conditions.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">FYI madvise test:</div><div class="gmail_default" style="font-size:small">[1] <a href="https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise01.c">https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise01.c</a></div><div class="gmail_default" style="font-size:small">[2] <a href="https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise02.c">https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise02.c</a></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">
That's why I only wrote one case for new-mount currently, due to basic mount<br>
test already can through most of new APIs(except open_tree and fspick). I don't<br>
know if we should write nearly same things in different directories.<br>
Actually I prepared open_tree and fspick test cases(planned to name as newmount02<br>
and newmount03. but the newmount01 has been changed to fsmount01 :), but didn't<br>
sent out, due to I hope to the first case(which does basic changes) can be merged<br>
at first.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">It'd be great if those tests can be merged together with Viresh's patch. </div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
All of your xxxxx02.c cases are great! I planned to test more different<br>
parameters of fsconfig() later too. Your invalid parameters test are nice.<br>
As you've sent these cases, I think these should be reviewed at first, avoid<br>
we do same things:) I'll try to help to review V2 patchset too, if I can:-P<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Thank you in advance, Zorro!</div></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>